Most people can recite the three principles of Zero Trust.
Far fewer can tell you how the standard actually defines it.
That’s how we ended up in a situation where every security vendor claims to sell Zero Trust, every conference presentation mentions it, and organizations spend millions on projects without necessarily becoming any closer to it.
The interesting part is that we don’t have to guess what Zero Trust means. We don’t have to rely on vendor marketing, LinkedIn hot takes, or twenty-slide presentations full of lock icons.
The definition already exists. NIST published it.
And once you read it, one thing becomes obvious:
That’s not my interpretation. That’s the language of the standard itself.
Understanding that difference is the key to understanding everything else.
Where the Term Came From
The phrase Zero Trust predates most of the cloud services now associated with it.
John Kindervag introduced the concept at Forrester Research in 2010 in a paper called No More Chewy Centers: Introducing The Zero Trust Model Of Information Security.
The title itself explains the problem.
Traditional security treated organizations like a castle surrounded by a moat. Strong defenses existed at the perimeter. Once someone made it inside, trust was often assumed.
Kindervag described that model as a “chewy center.” Attackers only needed to get through the outer shell once. After that, movement inside the network was often unrestricted.
What’s worth remembering is that this wasn’t originally a response to cloud computing, SaaS applications, remote work, or AI. It was a response to flat internal networks and excessive trust.
That distinction matters because sixteen years later Zero Trust is often marketed as a cloud strategy when it actually began as a challenge to implicit trust itself.
And perhaps it’s time we stop calling it a new paradigm. In 2026, Zero Trust is old enough to drive.
What the Standard Actually Says
Most people encounter Zero Trust through a familiar three-part message:
If you’ve seen Microsoft’s Zero Trust guidance, you’ve seen these principles. They’re useful. They’re memorable. They’re also not the definition.
NIST defines Zero Trust as:
A collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services.
NIST SP 800-207
Notice what’s missing.
Then NIST goes further. It defines a Zero Trust Architecture as:
An enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies.
NIST SP 800-207
Read that again. A plan.
That’s the hinge point of the entire discussion. You can purchase technologies that support the plan. You cannot purchase the plan itself.
The Seven Tenets
NIST doesn’t define Zero Trust using three principles. It defines it using seven foundational tenets:
- 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 to resources is determined by dynamic policy — including the observable state of client identity, application/service, and the requesting asset.
- 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.
This is where the three-principle version starts to make more sense. Microsoft’s summary isn’t wrong. It’s a compression.
The seven tenets above are difficult to memorize. The three-principle version is easy to remember and easy to teach. That’s valuable.
But something important gets lost in the compression. The original tenets emphasize things many organizations still struggle with:
Those ideas are easy to overlook because they don’t fit neatly on a slide. Yet they’re central to the standard.
Why “We Bought a Zero Trust Solution” Doesn’t Really Mean Anything
This is where the conversation gets uncomfortable.
Organizations often announce they’ve implemented Zero Trust because they deployed a product category associated with it. NIST takes a different position:
Transitioning to ZTA is a journey concerning how an organization evaluates risk in its mission and cannot simply be accomplished with a wholesale replacement of technology.
NIST SP 800-207
That’s about as clear as standards language gets. You don’t become Zero Trust by replacing one tool with another.
NIST also notes that most organizations will continue operating in a hybrid state containing both traditional and Zero Trust approaches. In other words: nobody is finished.
The confusion isn’t really anyone’s fault. Different bodies are answering different questions.
| Source | What it defines | Question it answers |
|---|---|---|
| NIST SP 800-207 | An architecture — seven tenets, and the Policy Engine / Administrator / Enforcement Point model | How trust decisions work |
| CISA Zero Trust Maturity Model | An assessment — five pillars, three cross-cutting capabilities, four stages | How mature you are |
| The Open Group | Capabilities and governance — people, process and technology building blocks | Who owns what |
| DoD Zero Trust Strategy | A strategy and roadmap | What order to do it in |
That’s why conversations sometimes talk past one another. Someone discussing maturity is answering a different question from someone discussing architecture.
The detail most people miss
NIST doesn’t define pillars at all. The familiar Identity, Devices, Networks, Applications and Data pillars come from CISA’s maturity model.
They’re useful for assessment. But they’re not the architecture itself.
Products help you implement Zero Trust. Owning products does not prove you’re doing Zero Trust.
What a Trust Decision Actually Looks Like
The easiest way to understand Zero Trust is to follow a single access request. NIST describes three logical components.
Together, these components create a cycle that repeats continuously. A user requests a resource. Context is evaluated. A decision is made. Access is allowed or denied. Then the process happens again. Per session. Every time.
This leads to one of the most important observations in the entire model:
If a security platform knows an identity has been compromised but still allows access, you’ve implemented monitoring. You haven’t implemented Zero Trust.
The gap between knowing and refusing is where Zero Trust actually lives.
One Example: What This Looks Like in a Microsoft Environment
A note on scope
Everything up to this point applies whether you’re running Microsoft, Google, AWS, Okta, or an entirely on-premises environment. But let’s pivot into how it looks in a Microsoft environment.
In a typical Microsoft deployment:
- Policy Engine maps closely to Entra ID evaluating Conditional Access policies.
- Policy Administrator handles token issuance and revocation.
- Policy Enforcement Points exist at the resources granting or denying access.
- Context comes from signals such as user risk, sign-in risk, device compliance, workload identity, and location.
The interesting challenge today isn’t users. It’s agents.
AI agents can acquire and present tokens continuously while lacking many of the traditional signals Conditional Access was originally designed around:
Risk detection can still work. The platform may identify suspicious behavior, unusual access patterns, or workload anomalies. But detection alone doesn’t solve the problem.
You still need policy enforcement. Without a policy that consumes the risk signal and acts on it, the environment may continue authorizing access while simultaneously recording concerning activity.
Why this generalises
That’s not a Microsoft problem. That’s a Zero Trust problem. Any platform that detects risk faster than it can enforce decisions eventually runs into the same issue.
The Part Nobody Likes to Talk About: Cost and Friction
Zero Trust sounds great on a slide. It feels different on Monday morning.
The first thing you learn during a real implementation is that friction rarely lands on the people designing security controls. It lands on everyone else.
- It lands on the executive trying to access email from an airport lounge.
- It lands on the employee using an unsupported device.
- It lands on the administrator suddenly needing approval before elevation.
Least privilege has an operational cost. Access reviews require effort. Just-in-time access requires processes. Per-session validation requires infrastructure.
And assume breach often means spending money to prepare for an event you hope never happens. Those are difficult conversations.
The rule of thumb
The best controls are usually the ones users barely notice during normal work while creating significant obstacles for attackers during abnormal activity. Risk-based controls are often better than blanket restrictions.
And sometimes the honest answer is that a control isn’t worth implementing. A 40-person company does not need the same architecture as a multinational enterprise. Pretending otherwise helps nobody.
How to Tell Whether You’re Actually Doing Zero Trust
The most useful maturity model available today might also be the least controversial. CISA’s Zero Trust Maturity Model doesn’t sell products. It doesn’t promote platforms. It simply provides a way to evaluate where you are.
One detail that’s easy to miss: governance isn’t a pillar. It’s cross-cutting.
That’s important because organizations frequently mature their technical controls faster than they mature their decision-making and ownership models. You can reach Advanced maturity in identity while remaining fairly Traditional in governance. In fact, that’s one of the most common reasons Zero Trust initiatives stall.
CISA also makes another point that deserves repeating:
The path to zero trust is an incremental process that may take years to implement.
CISA Zero Trust Maturity Model v2.0
Years. Not quarters. Not product refresh cycles. Years.
Three questions worth asking
If you’re trying to figure out where your organization actually stands:
The answers are usually revealing.
Where This Goes Next
Understanding Zero Trust is one thing. Designing it is another.
That’s why Zero Trust appears explicitly in Microsoft’s SC-100 certification. Candidates are expected to design solutions that align with a Zero Trust strategy and validate Conditional Access implementations against Zero Trust requirements.
That’s no longer background knowledge. It’s an exam objective. And increasingly, it’s a job requirement.
In the next post, we’ll move from concept to implementation and look at Conditional Access Policies That Hold Up.
Because if this article can be summarized in one sentence, it’s this:
Following the track
If you’re following our Microsoft certification track, we’re also building in-depth guides for AZ-104, SC-500, AZ-305 and SC-100, including Zero Trust design scenarios and real-world implementation labs.
SOURCES — PRIMARY DOCUMENTS, READ 15 SEPTEMBER 2026
NIST SP 800-207: Zero Trust Architecture · CISA Zero Trust Maturity Model v2.0 · NIST SP 1800-35: Implementing a ZTA · Kindervag, J. (2010), No More Chewy Centers, Forrester Research · Microsoft SC-100 study guide