What 19 Real-World Zero Trust Implementations Reveal About Doing It Right

If you’ve ever asked, “What does Zero Trust actually look like when deployed?”—this is the closest answer we’ve got.

National Institute of Standards and Technology (NIST) National Cybersecurity Center of Excellence (NCCoE) released one of the most useful public resources on Zero Trust implementation to date: Special Publication 1800-35. It’s the result of a multi-year, lab-based initiative involving 24 vendors.

It’s not a checklist or another high-level maturity model.

Together, they built and tested 19 different Zero Trust architecture (ZTA) implementations using only commercially available, off-the-shelf products.

No vendor fluff. No theoretical promises.

Just actual builds—with diagrams, implementation instructions, use cases, and measurable outcomes.

Why does that matter?

Because too many organizations are still stuck treating Zero Trust as a compliance box to tick or a marketing term to buy. This guide shows us that Zero Trust is neither of those. It’s an architectural shift, a practical design choice—and, done right, it helps reduce lateral movement, limit data exposure, and improve control without killing the user experience.

Where Every Organization Should Start

The first thing NIST calls out is that there is no one-size-fits-all Zero Trust solution. Instead, they offer a phased approach that almost every organization can relate to:

• EIG Crawl Phase: Identity-first, on-premises controls with basic policy enforcement
• EIG Run Phase: Add cloud workloads, device discovery, and limited tunneling
• SDP, SASE, and Microsegmentation Phase: Full-blown risk-based, session-aware policy enforcement across hybrid environments

In other words, you start with what you have—usually an identity platform and endpoint security—then build from there based on your actual business needs and risks.

EIG stands for Enhanced Identity Governance, and in the context of the NIST Zero Trust Architecture project, it refers to the foundational phase of Zero Trust implementation that focuses on identity-first controls.         

Core Characteristics of the EIG Crawl Phase:

• Identity is central: Uses existing Identity, Credential, and Access Management (ICAM) systems as the Policy Decision Point (PDP).
• Endpoint security and visibility: Includes basic endpoint posture checks but not full behavioral analytics.
• On-prem focus: Primarily protects on-premises resources, not cloud workloads yet.
• Minimal integrations: Relies on out-of-the-box capabilities—no custom connectors or orchestration.
• Static policy evaluation: Periodic reauthentication, but less real-time risk-based policy enforcement.

Why It's Called “Crawl”: This is the entry point into Zero Trust maturity—think of it as laying down the foundation:

• Who is requesting access?
• From what device? Is that device healthy?
• Are they using their assigned identity?

Once these signals are enforced at the basic level, organizations can evolve toward more dynamic and cloud-native Zero Trust (the “Run” and “Fly” phases).

From Authentication to Authorization (and Then Again)

One of the most important lessons from the lab builds: Zero Trust decisions are not one-time events. Just because a user is authenticated doesn’t mean they stay authorized. The environment, device posture, location, and behavior all matter—and they change.

NIST makes this point repeatedly through the guide:

“Authorization is continuously evaluated. Session state is not a free pass.”

Several builds terminated active sessions the moment endpoint health dropped or a confidence score fell below threshold. In others, policy engines used signals from security analytics, posture checks, and behavioral analytics to either step up authentication or revoke access dynamically.

This level of enforcement isn’t hypothetical—it’s real, and it works when vendors can integrate. Which brings us to the next point…

Tool Sprawl Isn’t the Enemy—Integration Gaps Are

One of the more sobering observations: most organizations already own the right tools. But without interoperability—especially between identity, endpoint, and policy engines—you’re building silos, not Zero Trust.

“What broke down wasn’t the control—it was the signal never reaching the decision point.”

The guide highlights how policy engines need input from EDR, MDM, and security analytics to make context-rich decisions. Without those integrations, policies become overly permissive, or worse, outdated and ineffective.

A Useful Way to Think About the Journey

NIST closes the document with a sequence that’s refreshingly grounded:

1. Inventory your environment. [Captain Obvious] You can’t protect what you don’t see.
2. Write a policy based on actual business use. Least privilege doesn’t mean least access—it means right-sized access.
3. Reuse what you already have. Don’t rip and replace without reason.
4. Apply a risk-based approach. Not all resources need the same protection.
5. Build incrementally. Add and integrate controls as needed.
6. Validate continuously. Logging is not verification.
7. Evolve. The threat landscape doesn’t wait for you to catch up.

If you’re trying to define your Zero Trust roadmap or validate your current approach, this guide is well worth a deep dive.

Final Thoughts

There’s no single “Zero Trust product.” And there never will be. But there is a repeatable, testable way to design Zero Trust into your environment—and NIST just showed us how.

Subscribe to Zero Trust Journey for latest insights about #ZeroTrust