Am I the only one who has experienced this…usually after a board meeting or a vendor briefing, where someone announces that the company is going to implement zero trust. The room nods, a working group gets formed, budget line appears and within a few weeks, the initiative is underway… with everyone quietly assuming that what they are building is a technology project.

It is not. And that misunderstanding is the single biggest reason why most zero trust programs produce dashboards instead of security (oh no I went after the dashboards).

I want to be clear about something before going further: zero trust is a genuinely sound security model. The core principles are there, verify explicitly, use least-privilege access, assume breach, are not complicated ideas, and the security rationale behind them is solid and well-established. I want this to be clear this is not a critique of the concept. It is a critique of how organizations approach it, and more specifically, of what they tend to skip over in the rush to implement it (most places).

Zero trust (at its foundation) is a decision about assumptions. Specifically, it is the decision to stop assuming that anything inside your environment is automatically trustworthy. Not your network segments, devices, service accounts and even your users (especially the users). The model says: prove it, every time, in context, with the minimum access necessary to do the job. That is a reasonable thing to want from a mature security program. What it demands in practice is something most organizations have not fully come to terms with.

The first thing zero trust demands is an honest, complete inventory of every identity in your environment. It’s not just your employees. Its identity at every level and it includes contractors, vendors, automated processes, service accounts, APIs authenticating to other APIs, legacy applications running on credentials that were created years ago by someone who no longer works there. I have been in environments where this inventory work alone took months, and not because the tools were inadequate, but because the organization had never asked the question seriously before. You cannot continuously verify access if you do not know who and what is asking for it and most organizations, if they are honest with themselves, have significant gaps in that picture.

The second thing it demands is a working understanding of what you are trying to protect. Zero trust requires that you apply appropriate controls based on the sensitivity of what is being accessed. That means your data classification framework cannot just be a policy document that lives in a shared drive and gets dusted off for audits. It must be operationalized into the actual decisions people make when they build systems, grant access, and respond to alerts. I have seen data classification workshops produce thoughtful, detailed frameworks that were then completely ignored the moment the team went back to their regular work. Zero trust surfaces that gap immediately, because if you cannot define what sensitive looks like, you cannot decide what access to it should look like either.

The third thing, and this is the one that tends to make rooms go quiet, is that zero trust requires your organization to make a genuine cultural commitment to removing implicit trust, including from the people and processes that are most accustomed to having it (the executives who need access to everything). Executives, who find multi-factor authentication inconvenient, so it’s turned off for them. Developers who have had broad production access for years and have never misused it. Business-critical processes that are technically over-privileged but operationally are fragile to change (you sneeze wrong and critical applications break). If you are honest, you’ll realize (or discover during the process) these are not edge cases they are baked into your environment. They are the norm in most mature environments, and they are precisely where zero trust initiatives get quietly neutered.

I have watched zero trust pilots succeed in controlled environments and then stall the moment they start to expand. It’s not because the architecture was wrong, but because expansion required organizational decisions that nobody had made or seriously discussed. Like decisions about who has authority to enforce access controls on privileged users. Decisions about how much friction is acceptable in the name of security. Decisions about what happens when a critical business process conflicts with security controls. Those are governance and culture questions, and no technology deployment answers them.

There is also a sequencing problem worth calling out here. Zero trust is often presented as a destination, but if you understand it, it is more accurately a direction. You do not arrive at zero trust, you move toward it, and how far you can move is constrained by how solid your foundation is. If your identity governance is inconsistent, your microsegmentation project will run into edge cases that stall it. If your logging and monitoring cannot distinguish normal access patterns from suspicious ones, your continuous verification controls will generate noise that engineers eventually learn to ignore (dangerous). Each layer of a zero trust architecture depends on the layer beneath it being reliable. Skipping the foundational work to get to the interesting architectural pieces is a reliable way to end up with a program that looks mature but does not function as one.

None of this means zero trust is the wrong goal (I think we should all be working there). It is the right one, but the path to it runs through some conversations that are less comfortable than a vendor demo (or root canals).

The practical starting point is not an architecture diagram; it is a set of honest (and uncomfortable) questions. What do we actually know about every identity in our environment right now, and where are the gaps? Is our data classification framework real, meaning is it actually reflected in how we build and operate systems, or is it aspirational? Does our leadership team understand and accept the friction that genuine least-privilege enforcement will introduce, or are they expecting a technology purchase to solve the problem invisibly? Who in this organization has both the authority and the organizational support to enforce controls on privileged users when it matters?

Those questions do not have clean answers in most organizations. But asking them honestly, before committing to a zero trust roadmap, is what separates programs that reduce actual risk from programs that produce the appearance of it. The technology to support zero trust has never been better….the tooling is mature, the frameworks are well-documented, and the field has produced real, workable guidance on how to implement it. What the tooling cannot do for you is make your organization ready to have the harder conversation underneath the architecture. That part requires leadership, clarity about what you are protecting and why, and a genuine willingness to apply controls consistently even when it is inconvenient. If you are willing to do that work, zero trust is a meaningful step forward. If you are not, it is a very expensive way to feel like you are.