Zero trust is one of the most abused terms in enterprise security: half a real architectural shift, half a sticker on products that were already on the roadmap. The deployments that work share a few stubborn habits. The ones stuck in perpetual pilot share a few predictable mistakes. What follows is from real rollouts, tied to NIST SP 800-207 and the federal strategy in OMB M-22-09, with a phased path that has survived both greenfield builds and brownfield Active Directory estates.
What Zero Trust Actually Means
Agree on the definition before anyone buys a box. NIST SP 800-207 frames zero trust as a set of principles, not a product category. Trust is never granted based on network location and must be continuously evaluated for every access decision. The document enumerates seven tenets that every ZTA should satisfy.
The seven tenets of NIST SP 800-207
- All data sources and computing services are considered resources
- All communication is secured regardless of network location
- Access to individual enterprise resources is granted on a per-session basis
- Access is determined by dynamic policy, including observable state of identity, device, and environment
- The enterprise monitors and measures the integrity and security posture of all owned and associated assets
- All resource authentication and authorization are dynamic and strictly enforced before access is allowed
- The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications, and uses it to improve security posture
Notice what is not on this list. The word VPN does not appear. Neither does firewall, microsegmentation, or SASE. Those are implementation choices, not tenets. Teams that treat the tenets as the north star make better trade-offs than teams that start with a product.
Failure Mode One: Over-Rotating on Network Segmentation
The mistake we see most is shrinking zero trust down to aggressive microsegmentation. A team buys a segmentation product, spends eighteen months drawing east-west policy, and emerges with a brittle network map and no improvement in the identity story. The attacker who compromises a service account still moves laterally, just within a smaller blast radius.
Microsegmentation has a place, but it is a late-stage control. If your identity plane still issues long-lived credentials, if service-to-service auth still relies on shared secrets, if device posture is unknown, network segmentation is lipstick on a legacy trust model. The first principle from BeyondCorp, which we will revisit below, is identity-first security. Network controls follow identity, not the other way around.
Failure Mode Two: Policy Engine Sprawl
The second failure is quieter: policy engine sprawl. Every tool in the stack ships its own policy engine. Identity providers have one. EDR tools have one. SaaS applications have one. API gateways have one. Left unmanaged, a team ends up with a dozen policy engines whose rules overlap, contradict, and drift. When an incident happens, no one can answer the simple question of what policy was actually in effect at 14:07 UTC yesterday.
Successful deployments centralize policy authoring, even if enforcement remains distributed. That usually means a single policy-as-code repository, a review process for changes, and automated distribution to each enforcement point. Tools like Open Policy Agent, Styra, and native policy engines in Cloudflare Access or Zscaler Private Access can pull from a shared source of truth. The goal is one policy brain, many policy hands.
Failure Mode Three: Performance Bottlenecks
Zero trust introduces new network paths. Every request now traverses a policy decision point, a policy enforcement point, and sometimes a cloud inspection layer. When those components are centralized in one region, users on the other side of the world pay the latency bill. We have seen engineering teams revolt against ZTA rollouts because their build pipelines doubled in duration.
- Place enforcement points close to users and workloads, not in a single hub
- Cache decisions where the risk model allows, with short, explicit TTLs
- Measure p95 and p99 latency, not just averages, because the long tail is what drives user complaints
- Pre-warm policies during user login rather than evaluating from scratch on every call
A Phased Rollout That Works
The rollouts that did not stall used three phases, in this order, and they refused to skip ahead to the shiny network work.
Phase one, identity first
Start with identity. Consolidate on one identity provider. Kill local accounts where you can. Enforce phishing-resistant MFA with FIDO2 or platform authenticators. Shorten token lifetimes, then shorten them again. Wire in continuous verification so a session can be killed mid-flight when risk changes. Do this phase honestly and you close most of the lateral movement paths attackers still use.
Phase two, device posture
Once identity is trustworthy, attach device posture to every access decision. Managed devices enroll in MDM or a device trust service. Unmanaged devices either get a limited path or none at all. Posture signals (disk encryption, OS version, EDR health) should be fresh, not a nightly snapshot. The policy engine consumes these signals alongside identity claims, so a trusted user on a compromised laptop no longer equals trusted access.
Phase three, application and data
Do not touch the application and data layer until identity and device are solid. Then replace VPN access to internal apps with a software-defined perimeter that publishes applications individually. Inventory sensitive data stores and wrap them with identity-aware proxies. Apply microsegmentation to the workloads that justify the operational cost. This is also where API-level authorization should be pushed down into services rather than relying on edge gateways alone.
Lessons from Google BeyondCorp
BeyondCorp is the canonical case study because Google published extensively about it. Three of their lessons keep showing up in every ZTA that actually finished instead of stalling in a pilot.
- Start with an inventory you can trust. BeyondCorp would not have been possible without a device inventory service that knew which laptop belonged to which engineer. Most enterprises underestimate how long it takes to reach that baseline and how much data cleanup it requires.
- Migrate gradually. Google ran BeyondCorp and legacy VPN side by side for years. Teams that try a big-bang cutover almost always retreat. Design for coexistence from day one.
- Invest in tier-one engineering support. Users hit ZTA edge cases constantly during rollout. A well-staffed support team that can actually fix policy rather than just tell users to try again is the difference between adoption and rebellion.
Lessons from OMB M-22-09
The January 2022 federal zero trust strategy under OMB M-22-09 set specific ZTA goals for US federal agencies by the end of fiscal year 2024. Even for private sector teams, the memo is worth reading because it turns NIST SP 800-207 tenets into deadlines and measurable outcomes. A few highlights we have adopted in our own guidance.
- Enterprise-managed identities with phishing-resistant MFA are table stakes, not aspirations
- Every device used to access agency resources must be continually tracked and verified
- Agencies must encrypt all DNS requests and HTTP traffic, including internal traffic
- Applications must be treated as internet-facing and tested accordingly
- Agencies must make at least one internal application fully accessible over the internet without a VPN as proof of ZTA maturity
These are blunt, measurable checkpoints. Teams that adopt similar checkpoints internally have a much easier time explaining progress to executives, because the answer is no longer "we are doing zero trust." It is "we hit four of five checkpoints and here is the plan for the fifth."
How Identity-First Security Ties It Together
The throughline in every deployment that worked is identity-first security with continuous verification, not a new VPN with a zero-trust label. The policy engine, whatever shape it takes, is evaluating a constantly updated picture of who the user is, what device they are on, what they are trying to do, and what has changed in the last few minutes. Breach exposure data feeds that picture. If a user's credential surfaces in a stealer log overnight, their trust score should drop before they log in the next morning.
Conclusion
Zero trust architecture is not a product you install. It is a set of principles you operationalize in a specific order. Use NIST SP 800-207 as the tenets. Do not start with network segmentation. Centralize policy authoring even if enforcement stays distributed. Design for latency on day one, not after the first revolt from engineering. Identity first, then device posture, then application and data. Steal from BeyondCorp and OMB M-22-09; those lessons are already paid for. Skip a step and you have bought expensive theater.
Frequently asked questions
What is zero trust architecture in practice?
ZTA means every access decision is evaluated from identity, device, and context, not from network location. NIST SP 800-207 lists seven tenets. VPN, microsegmentation, and SASE are implementation choices that may support those tenets. They are not the architecture.
Should we start a zero trust project with microsegmentation?
Usually no. Microsegmentation is a late-stage control. If long-lived credentials, shared service secrets, and unknown device posture are still the norm, a smaller blast radius does not fix the identity problem. Start with identity: one IdP, phishing-resistant MFA, short token lifetimes, and the ability to revoke a session when risk changes.
How long does a zero trust rollout take?
Plan in years, not quarters, and design for coexistence with the legacy path. Google ran BeyondCorp alongside VPN for years. A useful first checkpoint is one internal application reachable over the internet without a VPN, which is also a goal in OMB M-22-09. Identity-first work can show results in months. Full application and data coverage takes longer.
How is zero trust different from replacing the VPN?
A rebranded VPN still trusts the network once you are on it. A ZTA grants access per session, per resource, based on current identity and device state, and can revoke that access when the picture changes. If the product cannot enforce device posture on refresh or drop a session in seconds, it is not doing the job the tenets describe.
How do NIST SP 800-207 and OMB M-22-09 fit together?
NIST SP 800-207 is the principles document. OMB M-22-09 turns those principles into federal deadlines and measurable outcomes: phishing-resistant MFA, continuous device verification, encrypted DNS and HTTP (including internal), internet-facing application testing, and at least one internal app reachable without a VPN. Private-sector teams can reuse those checkpoints even if the memo does not bind them.
Can a small team implement zero trust without a huge budget?
Yes, if you sequence the work. Consolidate identity, turn on phishing-resistant MFA for admins first, shorten tokens, and publish one application through an identity-aware proxy before you buy a segmentation platform. Policy-as-code (even a single repository feeding the IdP and the proxy) prevents the dozen-engine sprawl that burns small teams later.