In February 2023, Gartner predicted that by 2026, 10% of large enterprises would have a mature and measurable zero-trust program in place, up from less than 1% at the time. The same analysis expected more than 60% of organizations to adopt zero trust as a starting point for security by 2025, and more than half of those to fail to realize the benefits.
It is now 2026, and that forecast reads less like a prediction than a description. Almost every security vendor sells something branded zero trust. Few organizations can point to a policy engine, a defined set of protected resources and a measurable reduction in what a compromised laptop can reach.
The gap is not because the idea is wrong. It is because zero trust is an architecture, not a product, and architectures are bought slowly and painfully rather than installed. What follows is what the underlying standard actually says, what the components do, which parts genuinely reduce risk, and what it realistically costs an organization that does not have a dedicated identity team.
What the standard actually says
The reference document is NIST Special Publication 800-207, published in August 2020. It is short, vendor-neutral and worth reading directly.
NIST defines zero trust as a set of concepts designed to minimize uncertainty in enforcing accurate, least-privilege, per-request access decisions in systems and services, on the assumption that the network is already compromised. That last clause is the whole idea. Not “the network might be hostile” as a precaution, but “assume it already is” as a design input.
The publication sets out seven tenets:
- All data sources and computing services are treated as resources that need protection.
- All communication is secured regardless of network location, so being inside the office grants nothing.
- Access to individual resources is granted per session, after a trust evaluation.
- Access is determined by dynamic policy considering identity, the application or service, and the requesting asset’s state.
- The organization continuously monitors and measures the integrity and security posture of the assets it owns and those it works with.
- Authentication and authorization are dynamic and strictly enforced before access is allowed, every time.
- The organization collects data about asset and network state and uses it to improve its policy.
Nothing there mentions a product category. The tenets describe properties an architecture should have, which is why almost any tool can be marketed as contributing to them, and why almost no single tool delivers them.
The three components that make it real
NIST reduces the architecture to three logical components, and understanding them is the fastest way to cut through vendor claims.
The policy engine makes the decision. It takes a request, evaluates it against policy using inputs such as identity, device state, threat intelligence and behavioural signals, and produces a grant or deny.
The policy administrator carries out that decision by establishing or tearing down the communication path, issuing session credentials or tokens as needed.
The policy enforcement point sits in the traffic path and actually enables, monitors and terminates the connection between the user and the resource.
Engine and administrator together form the control plane. The enforcement point sits in the data plane. When you evaluate a “zero trust platform”, the useful question is which of those three roles it plays, what signals it can consume, and whether it can enforce for the resources you actually have, including the ones that are not modern web applications.
SP 800-207 also describes several deployment patterns: agent-and-gateway models, enclave gateways protecting a group of resources, and portal-based models where one gateway fronts access without client software. Real deployments mix them, because legacy systems rarely accommodate agents.
Identity became the perimeter, and attackers noticed first
The strongest empirical case for zero trust is not architectural theory. It is where breaches now start.
Sophos, surveying 2,158 IT and security leaders in early 2026, found that 79% of ransomware attacks began with an identity-based approach, and that multi-factor authentication was missing from critical systems in 59% of its incident response cases. Mandiant’s M-Trends 2026 found that prior compromise, meaning access obtained earlier and traded on, was the leading route into ransomware incidents at 30%.
If the credential is the attack surface, then the authentication event is where enforcement has to happen, and it has to happen more than once. Three things follow.
First, phishing-resistant authentication is table stakes rather than an upgrade. CISA’s guidance names FIDO/WebAuthn as the only widely available phishing-resistant method, and the US federal zero trust strategy makes it mandatory rather than recommended.
Second, authorization has to be conditional. A valid credential should not be sufficient on its own. The decision should also weigh the device, the resource being requested and the sensitivity of the action.
Third, sessions need re-evaluation. A token issued at nine in the morning to a healthy laptop should not still grant access at four in the afternoon after that laptop has failed a posture check. Continuous evaluation is the tenet organizations most often skip, because it is the one that generates user friction.
Device posture: useful, and the first place rollouts stall
Device posture means the policy engine knows something verifiable about the machine making the request: whether disk encryption is on, whether the endpoint agent is reporting, whether the operating system is patched, whether the device is managed at all.
It works well for corporate-issued laptops. It gets awkward fast for contractors, personal phones and partner organizations. Teams respond with exceptions, and exceptions accumulate into a parallel access path that quietly undoes the control.
The realistic approach is tiered rather than binary. Full access from managed, healthy devices. Restricted, browser-only access to specific applications from unmanaged ones. No access to sensitive systems from anything unverified. That is more work to design than a simple allow-or-block rule, but it survives contact with how people actually work.
Microsegmentation, and why it fails more often than it succeeds
Microsegmentation means restricting east-west traffic inside the network so that a compromised workstation cannot reach a database server just because both are plugged into the same corporate network.
The security value is genuine and directly addresses the lateral movement stage of a ransomware intrusion. The failure rate is high for reasons that have little to do with the technology.
The first problem is inventory. You cannot write a rule allowing an application server to talk to its database if nobody has documented which servers talk to which. Most microsegmentation projects spend months in discovery, and some never leave it.
The second is that policy is written by people who understand the network, while breakage lands on people who understand the business. A rule that blocks a quarterly batch job discovered in month nine erodes trust in the whole programme.
The third is scope creep. Segmenting everything is a multi-year effort. Segmenting the management plane, backup infrastructure, domain controllers and the systems holding regulated data delivers most of the benefit and can be finished. Mandiant’s 2026 report identifies backup infrastructure, identity services and virtualization management planes as active attacker targets, which is a fairly direct list of what to isolate first.
ZTNA versus VPN, without the sales pitch
Zero trust network access is the component most people encounter first, because it replaces something visible.
| Property | Traditional VPN | ZTNA |
|---|---|---|
| What you connect to | The network | A specific application or resource |
| Default reach after login | Broad; often the whole subnet | Only what policy explicitly allows |
| Resource visibility | Scannable once connected | Hidden from unauthorized users |
| Re-authorization | Usually once per session | Per request, with posture signals |
| Typical failure mode | Concentrator vulnerability exposes everything behind it | Broker outage or misconfigured policy blocks legitimate access |
| Legacy protocol support | Broad | Varies; often weaker outside HTTP and RDP/SSH |
The strongest argument for ZTNA is the blast radius. A VPN grants network membership, so a stolen credential yields a position inside the network from which to look around. A ZTNA broker grants a connection to one named application, so the same stolen credential yields one application.
The honest counterpoints are worth stating. ZTNA moves the critical dependency to a broker that is now in the path of all remote work, which is an availability risk and a vendor concentration risk. It usually requires an agent, which brings its own management burden. Legacy applications that speak unusual protocols often still need a VPN-style tunnel, so many organizations end up running both for years rather than replacing one with the other. And a ZTNA deployment configured with one broad policy granting everyone access to everything is a VPN with a different bill.
What a realistic phased rollout looks like
Two US government documents are the most useful planning aids, regardless of whether you are a government body.
CISA’s Zero Trust Maturity Model, currently at version 2.0, organizes the work into five pillars: identity, devices, networks, applications and workloads, and data. Three capabilities cut across all five: visibility and analytics, automation and orchestration, and governance. Progress within each pillar is graded across four stages, from traditional to initial, advanced and optimal. Its practical value is permission to be uneven. Being advanced on identity and traditional on data is a normal, reportable state rather than a failure.
NIST’s SP 1800-35, published in final form on 11 June 2025, is the implementation companion. The National Cybersecurity Center of Excellence built 19 example implementations with 24 collaborating vendors, documenting the products, integrations and configurations used. If you want to know what a working architecture is made of rather than what it should achieve, this is the document.
A defensible sequence for most organizations looks like this:
- Inventory what you are protecting. Applications, data stores, administrative interfaces, and who currently reaches them. This is dull and it is the step most programmes skip.
- Fix identity first. One identity provider where possible, phishing-resistant MFA on administrative and remote access, and elimination of shared and orphaned accounts. This yields the largest measurable risk reduction per dollar.
- Add conditional access policies. Start by requiring a managed, healthy device for administrative functions and sensitive data, and log the decisions before enforcing them.
- Replace remote access for a subset of applications. Pick three or four internal web applications, move them behind a ZTNA broker, and keep the VPN for everything else while you learn.
- Isolate the crown jewels. Segment backup systems, hypervisor management, directory services and regulated data stores before attempting general microsegmentation.
- Instrument, then tighten. Without logging of allow and deny decisions, you cannot safely reduce permissions, and you cannot demonstrate to anyone that the programme worked.
Common failure modes
- Buying the architecture as a product. Gartner’s analysis stressed that zero trust is a shift in mindset rather than a technology-first effort. A purchase order does not change an access model.
- No definition of done. Without a protect surface and a measurable target, such as what percentage of applications sit behind conditional access, the programme runs forever and reports nothing.
- Enforcing before observing. Policies rolled out in enforcement mode without a logging period generate outages, and outages generate exceptions that never get reviewed.
- Leaving legacy access in place. If the old VPN, the old jump box or the vendor’s dial-in still works, the new architecture is decoration.
- Ignoring non-human accounts. Service accounts, API keys and machine identities usually outnumber employees and are rarely covered by policy.
- Treating it as a network project. The centre of gravity is identity. Programmes owned solely by network teams tend to produce segmentation without authorization improvements.
What this means for smaller organizations
The federal framing does not translate cleanly to a 60-person company, and pretending otherwise wastes money. The US Office of Management and Budget’s M-22-09 memorandum of 26 January 2022 gave federal agencies until the end of fiscal 2024 to hit specific zero trust goals, and conceded in the same document that the transition “will not be a quick or easy task” for an enterprise as complex as the federal government. Agencies had budgets and mandates. Most businesses have neither.
The good news is that the highest-value components are also the cheapest, and several are already included in subscriptions organizations pay for.
If you run a small or mid-sized organization, the practical version is: consolidate onto a single identity provider; turn on phishing-resistant MFA for administrators and remote access; use the conditional access features already bundled in your existing productivity suite; put your handful of internal applications behind an identity-aware proxy rather than a flat VPN; and isolate backups and administrative interfaces from general user access. That is most of the risk reduction, and none of it requires a dedicated programme office.
What to defer: full microsegmentation, data classification at scale, and any product whose value proposition depends on integrating six other products you do not own. Those are real capabilities with real payoffs at large scale, and they consume the entire budget of an organization that has not yet fixed its identity layer.
Frequently asked questions
Is zero trust a product I can buy?
No. It is an access model. Products can implement policy engines, enforcement points and posture signals, but the policy itself, the inventory of protected resources and the decision about who should reach what are yours to define.
Do I have to replace my VPN?
Not immediately, and possibly not entirely. Many organizations run ZTNA for modern applications and keep a narrowed VPN for legacy protocols. The failure is leaving a broad, unrestricted VPN in place next to a ZTNA deployment, which means the weaker path is still available.
How long does a zero trust programme take?
Identity improvements can show results in a quarter. A full architecture across all five CISA pillars is a multi-year effort for most organizations, which is precisely why the maturity model grades progress by pillar rather than as a single pass or fail.
Does zero trust stop ransomware?
It reduces two specific things: the chance a stolen credential works, and how far an intruder can move once inside. It does not patch your internet-facing appliances, and exploitation of those has led Mandiant’s initial-access rankings for six consecutive years. Zero trust is a containment strategy, not a prevention strategy.
Judging your own programme honestly
The test of a zero trust effort is not how many of the five pillars appear on a slide. It is whether you can answer a small number of blunt questions: if an attacker had valid credentials for an average employee right now, what could they reach? How would you know? How quickly could you cut the session?
Teams that can answer those precisely have done the work, whatever they call it. Teams that cannot have bought tools.
The useful move for most teams this year is not to launch a programme. It is to pick the single application that would hurt most to lose, put it behind an identity-aware access decision that considers device state, log every allow and deny for a month, and see what the logs reveal about who is currently reaching it. That exercise is usually more persuasive than any vendor deck.
Sources
- NIST — SP 800-207, Zero Trust Architecture
- NIST NCCoE — NIST Publishes Final Special Publication 1800-35, Implementing a Zero Trust Architecture
- CISA — Zero Trust Maturity Model
- US Office of Management and Budget — M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
- Cybersecurity Dive — Zero trust is moving from hype to reality
- Sophos — 79% of Ransomware Attacks Now Originate from Compromised Identities
- Google Cloud / Mandiant — M-Trends 2026
- CISA — Implementing Phishing-Resistant MFA (fact sheet)
- Cloudflare — Everything you need to know about NIST SP 1800-35
- Thales — What Is the CISA Zero Trust Maturity Model?
Image credit: Photo: Federal Bureau of Investigation — Public domain (via Wikimedia Commons)
