Zero Trust Is Everywhere and Almost Nowhere at the Same Time

A 2024 Gartner survey found that 63 percent of organizations globally have fully or partially implemented a zero-trust strategy. That number gets cited in vendor presentations and security conference keynotes as evidence that the industry has turned a corner. I want to look at the other half of what Gartner found, because the full picture is a lot more uncomfortable. Most zero-trust strategies address only half or less of an organization's environment. Most implementations mitigate only one-quarter or less of overall enterprise risk. Gartner also predicts that only 10 percent of large enterprises will have a mature, measurable zero-trust program by 2026. Sixty-three percent say they started. Ten percent will finish anything worth calling a program. That gap deserves more attention than it gets.

The gap is not a mystery once you understand what zero trust actually is and how the vendor market has reframed it. Zero trust is an architectural philosophy, not a product. NIST Special Publication 800-207, which is the closest thing to an authoritative definition the field has, describes it as a set of principles where no user or device is trusted by default, regardless of network location, and access decisions are made dynamically based on continuous verification of identity, device health, and context. That description implies a multi-year architectural transformation covering identity management, device management, network segmentation, application access controls, and monitoring across every part of the environment. It requires those systems to talk to each other in real time. It means dismantling assumptions that have been baked into corporate network design since the 1990s.

What the vendor market sells as "zero trust" is considerably simpler. A multi-factor authentication product is marketed as zero trust. A software-defined perimeter appliance is zero trust. A cloud access security broker is zero trust. An endpoint detection and response platform is zero trust. Each of these tools genuinely supports zero-trust principles in a narrow domain. None of them, individually or even in combination, constitutes the architectural transformation NIST describes. When organizations check the zero-trust box after purchasing one of these tools, they are not being dishonest exactly. They are using a label that the market has stretched to cover almost anything. The Gartner finding that most implementations address only half the environment and mitigate a quarter of the risk is the quantified cost of that semantic drift.

The federal government example is the sharpest version of this problem I know. The Biden administration's 2021 executive order and the subsequent Office of Management and Budget memorandum required federal agencies to implement zero-trust architectures by specific deadlines. Zero trust became a compliance requirement, not just a strategic choice. Gartner subsequently predicted that 75 percent of US federal agencies will fail to implement zero-trust security policies through 2026. Think about what that means. The federal government mandated zero trust with specific timelines and resources. Three quarters of agencies will not get there. If the entity with explicit executive mandates, federal funding, and regulatory enforcement pressure cannot implement zero trust at scale, the gap between what organizations say about zero trust and what they actually achieve starts to look less like a capability problem and more like a structural one.

The structural problem is that zero trust requires organizational coordination across domains that rarely coordinate. Identity, device management, network, application security, and data governance are typically owned by different teams with different budgets, different reporting lines, and different priorities. A zero-trust architecture where all of those systems share context and make joint decisions in real time requires those teams to operate as a system, not as separate functions. I have seen organizations where the identity team and the network team have not had a meaningful joint project in years. Getting them to co-design an access control model that dynamically evaluates device health against identity signals against application sensitivity requires political capital that most security leaders do not have.

This is where I think IS research on organizational structure and IT governance has something useful to say. I wrote about how the CrowdStrike outage exposed structural governance failures in security, and the zero-trust maturity problem is in some ways the same issue at a larger scale. The architecture you need for zero trust requires governance decisions about who controls what and who coordinates with whom. Those decisions are organizational before they are technical. Organizations that fail to implement zero trust usually fail not because the technology is unavailable but because the organizational design does not support the coordination the technology requires.

The 79 percent of zero-trust implementers who, according to Gartner, have strategic metrics to measure progress suggests that measurement is happening even when maturity is not. I am not sure whether to find that encouraging or ironic. Measuring progress toward zero trust while implementing only a quarter of what the term implies is not the same as getting closer to the goal. It might be getting more comfortable with the gap. The metrics are real. The program may not be. There is an isomorphic quality to it: organizations adopt the visible trappings of zero trust because their peers are doing it, because auditors are asking about it, and because vendors are selling it, while the underlying architectural work stays difficult and unglamorous and underfunded.

Gartner's 10 percent prediction for 2026 does not surprise me. What I think it takes to be in that 10 percent is an organization where the security leadership has both the technical understanding and the organizational authority to drive cross-functional architectural change over multiple years. That person needs to be able to influence identity, network, and application teams without owning all of them. They need a budget that is protected across budget cycles. They need executive sponsorship that survives leadership turnover. Most organizations have none of those things reliably. The ones that do are the 10 percent. The other 90 percent are implementing products, not architectures, and measuring progress on a journey they have not yet mapped.