Zero Trust isn't a product. It's a roadmap
A field-update explainer published on this site. Sources at the bottom.
If you've sat through any vendor pitch this year, you've heard "Zero Trust" used as a product feature. As a category. As a checkbox. As a thing you can buy.
Gartner's surveys say 81% of organizations plan to implement Zero Trust in 2026, and the global market is projected to exceed $78 billion by 2030. The same surveys, when they probe deeper, find that most of those organizations have bought a Zero Trust product and not done much else. They've branded their existing VPN as "Zero Trust Network Access." They've turned on conditional access policies in Entra ID. They consider it shipped.
This post is about what Zero Trust actually is according to the people who defined it (NIST), what the phased adoption pattern looks like (CISA), and why the "buy a thing" approach falls short.
What NIST actually said
NIST Special Publication 800-207, published in 2020 and the canonical reference, defines Zero Trust as a set of principles and a security paradigm: explicitly not a product, not an architecture diagram, not a single technology.
The three load-bearing principles:
- Verify explicitly. Authenticate and authorize every request, every time, based on all available data points: identity, device posture, location, time of day, behavioural anomalies. "This user logged in this morning" is not a basis for trusting a request at 3 PM from a new geo.
- Use least privilege access. A user, device, or service should have access to exactly what it needs to do its current task, not what it might need someday. Just-in-time elevation, not standing admin.
- Assume breach. Architect under the assumption that an attacker is already inside the perimeter. Limit blast radius. Encrypt everything in transit even on "internal" networks. Log everything. Monitor for lateral movement.
Notice what's missing from this list: any specific product. NIST 800-207 lists components (Policy Engine, Policy Administrator, Policy Enforcement Point) but explicitly leaves implementation to the organization.
The failure mode of "buying Zero Trust" is that the product implements maybe one of these, usually a Policy Enforcement Point at the network edge, and leaves the other 90% of the work undone.
CISA's Maturity Model
CISA published the Zero Trust Maturity Model v2.0 to make this measurable. It defines five pillars (Identity, Devices, Networks, Applications & Workloads, Data) and four maturity stages per pillar: Traditional → Initial → Advanced → Optimal.
"Traditional" is roughly: passwords + VPN + flat networks + tickets-to-grant-access. "Optimal" is roughly: phishing-resistant MFA everywhere + continuous device posture + microsegmented networks + per-request authorization + DLP + everything in audit logs in real time.
Most organizations that say they're "doing Zero Trust" are at Initial across most pillars. The path to Advanced is years of work, not a procurement decision.
The DoD playbook (released January 2026)
The US Department of Defense released their Zero Trust Implementation Guidelines in January 2026: three documents totalling several hundred pages, defining 91 specific implementation activities across phases (Discovery → Phase One → ongoing).
This is the most concrete public guide that exists today, and the headline pattern is phased:
- Discovery first. What identities exist? What devices? What data flows? What's the actual current state? You cannot Zero-Trust an environment you haven't inventoried, and the inventory takes longer than people expect.
- High-value targets next. Privileged identities and crown-jewel applications first. Domain admins, root accounts, the customer database. These are where every breach actually wants to land. Defending them well buys the most risk reduction per dollar.
- Expand outward. Standard users, standard workloads, the long tail. These take longer because there are more of them, but the controls you've built for the high-value targets template down.
- Adaptive enforcement last. Real-time risk signals (UEBA, device-posture-driven policy, behavioural anomalies feeding policy decisions) only become reliable once the foundational controls underneath are solid. Building this on a weak identity foundation produces noise, not security.
What to actually do, regardless of size
Most organizations don't have DoD's resources. The same phased pattern still works, just smaller:
Step 1: Identity is the new perimeter. A single phishing-resistant identity provider (Entra ID, Okta, Workspace), federated across every system that supports SAML/OIDC. Every privileged account on phishing-resistant MFA (passkeys, FIDO2 hardware keys; not SMS or TOTP for admins). MFA bypass is the #1 path attackers take in 2026; close it.
Step 2: Device posture matters. Conditional access that can refuse a login from an unmanaged device or one that's missed three patch cycles. This is the single highest-leverage control after MFA, and most organizations have the capability already in their existing tools; they just haven't enabled it.
Step 3: Microsegment what you can. Production database traffic shouldn't be reachable from a developer laptop. "Internal network" is no longer a meaningful trust boundary. Replace flat networks with explicit allow lists between services.
Step 4: Just-in-time everything. Standing access is the enemy. Privileged operations require a request, justification, time-bound elevation, and an audit trail. Off-the-shelf tooling exists for this; "we'll build it ourselves" is a known failure mode.
Step 5: Log enough to investigate. When the breach happens (and it will), the question is whether you can reconstruct what happened. Centralized logging in a separate trust domain. Six months of retention minimum. Searchable.
The practitioner's framing
Zero Trust is not a project with a finish line. It's a direction. Every quarter, you should be able to point at a specific pillar (CISA's framework is fine for this) and say "we moved from Initial to Advanced on Identity this quarter; here's the evidence." That's progress.
What isn't progress: replacing the VPN, calling it "Zero Trust," and putting it on the slide deck. That's marketing.
The attackers don't care which slide deck you put it on. They care whether stolen credentials still work, whether the workstation they're on can reach the database server, and whether their lateral movement makes a sound in your logs. Those are the questions Zero Trust is supposed to make hard. Buying the product doesn't answer them.