Zero Trust in practice: implementing NIST 800-207 with the Microsoft stack

Zero Trust has been marketed to death, which is a pity, because underneath the vendor noise sits the most useful security architecture document of the last decade: NIST Special Publication 800-207. Its core proposition is unglamorous and correct: stop treating network location as a proxy for trust; evaluate every access request explicitly, against identity, device and context, every time. No inside. No outside. No implicit trust anywhere.

For organisations on Microsoft 365 and Azure, the honest news is that the tooling for a real Zero Trust implementation is already in the licence stack. What is usually missing is the architecture and sequence. Here is both.

The principles, stripped of marketing

One clarification first, because it is widely muddled. NIST SP 800-207 sets out seven tenets of Zero Trust, covering resources, per-session access, dynamic policy, asset integrity monitoring and the continuous collection of state to improve posture. The three principles almost everyone quotes (verify explicitly, least privilege, assume breach) are Microsoft's distillation, not NIST's text. They are a faithful and useful summary, and we use them below, but if you are writing an architecture document that cites 800-207, cite the seven tenets: an assessor who has read the publication will notice.

With that noted, Microsoft's three operating rules are the practical frame. Verify explicitly: authenticate and authorise every request using all available signals: identity, device health, location, workload, data classification, anomalies. Least privilege: grant the minimum access required, just-in-time where possible, and re-evaluate continuously rather than at sign-in only. Assume breach: design as though the attacker is already inside: segment, encrypt, monitor everything, and make lateral movement expensive.

In 800-207's architecture, every access decision flows through a policy decision point enforced at a policy enforcement point. In the Microsoft implementation, that machinery has a name: Conditional Access is the policy engine, consuming signals from the rest of the stack and enforcing decisions at every application gate. This is why a weak Conditional Access framework undermines everything else: it is the load-bearing wall.

One further piece closes the gap between 800-207's continuous evaluation and a sign-in-time check: Continuous Access Evaluation. Without it, a policy decision holds until the access token expires, which is a generous window for an attacker holding a stolen session. With it, critical events (a revoked account, a disabled user, a changed network location, a raised risk level) propagate to supporting Microsoft 365 services in near real time. Zero Trust that re-evaluates only at sign-in is not continuous, whatever the architecture diagram says.

The policy decision point and enforcement pattern described in NIST SP 800-207, realised in Entra Conditional Access. Modelled on the NIST SP 800-207 reference architecture and Microsoft Learn Zero Trust guidance.

Mapping the six pillars to the stack

Identity: Entra ID: MFA (phishing-resistant for privileged roles, for AiTM reasons), Conditional Access, Identity Protection risk signals, and PIM for just-in-time privileged access. Identity is the new perimeter: nearly every modern intrusion begins with a compromised identity, which is why this pillar comes first.
Endpoints: Intune + Defender for Endpoint: device enrolment, compliance policies as a Conditional Access grant control, and EDR feeding device-risk signals back into access decisions. The loop matters: a device Defender flags as compromised loses access automatically.
Applications: Defender for Cloud Apps: SaaS discovery (the shadow-IT census), session controls for unmanaged contexts, and OAuth-app governance, the consent-phishing surface most tenants have never audited.
Data: Purview: classification and sensitivity labels, DLP across endpoints and Teams, encryption that travels with the file. Assume-breach logic applied to data: protection that works after the perimeter has failed.
Infrastructure: Defender for Cloud + Azure Policy (+ Azure Arc for hybrid): posture management, workload protection, drift prevention as code.
Network: the pillar Zero Trust demotes, deliberately: segmentation via NSGs and Azure Firewall, private connectivity via Private Link, and the retirement of "on the VPN = trusted" as a concept. Where VPN replacement is in scope, Entra Internet Access and Private Access (the Global Secure Access family, licensed through the Entra Suite and included in Microsoft 365 E7) bring network access under the same Conditional Access policy engine as everything else, which is the architectural point rather than the tunnelling.

A seventh consideration now belongs alongside these six: non-human identities. Service principals, managed identities and, increasingly, AI agents hold access that is rarely subject to the joiner-mover-leaver discipline applied to people. Standing, unreviewed, unowned machine access is the most common Zero Trust blind spot we find in otherwise mature tenants, and it is the problem Agent 365 in E7 was built to address.

The sequence that works

Zero Trust programmes fail by attempting everything simultaneously. The dependency-ordered sequence we run:

Phase 1: Identity foundation. MFA everywhere via Conditional Access, legacy authentication blocked, break-glass governed, PIM live for admin roles. Weeks of work, the largest single risk reduction available.
Phase 2: Device signal. Intune enrolment, compliance policies, Defender for Endpoint deployed, and compliance made a grant requirement in Conditional Access. Access now requires healthy identity and healthy device.
Phase 3: Application and data control. Cloud Apps discovery, OAuth governance, then classification and DLP on the crown-jewel data locations first: Purview rollouts that start everywhere finish nowhere.
Phase 4: Infrastructure, network, and operations. Azure posture and segmentation, plus the monitoring loop that makes assume-breach real: signals correlated in a well-designed Sentinel deployment, detections that feed back into automatic access decisions.

Each phase produces measurable security value on its own; none depends on a later phase to justify itself. Budget realities interrupt programmes: sequence so interruption leaves you better off, not half-built.

The two failure modes to avoid

Buying Zero Trust as a SKU. Licensing E5 does not implement anything; we assess E5 tenants running entirely on implicit trust. Declaring victory after MFA. MFA-only is 2019's baseline: without device signal, session protection and least-privilege enforcement, one AiTM kit dissolves the whole claim.

Practical steps

Locate yourself honestly on the four phases above: most organisations we assess are mid-Phase 1 while believing otherwise. Close Phase 1 completely before spending on anything exotic. Then let Conditional Access accumulate signals phase by phase until "trusted because inside" has no meaning left in your environment. QG designs and implements Zero Trust architectures on the Microsoft stack, aligned to NIST 800-207 and measured on Secure Score, assessment first, then the sequence above, at the pace your operations can absorb.