What breaks when organisations treat Zero Trust as a linear maturity path instead of an architectural model?

Teams stall because they wait to complete one domain before starting another, such as finishing identity before touching network or devices. John Kindervag’s guidance is to avoid that trap. Zero Trust works when teams secure discrete protect surfaces end to end, rather than endlessly sequencing broad enterprise transformation work.

Why a Maturity-Path Mindset Distorts Zero Trust

Treating zero trust as a linear maturity model turns an architectural approach into a programme-of-record, which changes the question from “what do we need to protect?” to “what domain do we finish next?” That shift is risky because Zero Trust is meant to reduce implicit trust across discrete protect surfaces, not certify an enterprise in stages. NIST SP 800-207 Zero Trust Architecture describes this as an architectural model, not a sequential compliance ladder, so the control objective stays tied to access decisions and trust boundaries rather than programme milestones. NIST SP 800-207 Zero Trust Architecture

Teams that optimise for maturity often delay useful controls because one dependency is treated as a prerequisite for everything else. The result is partial coverage, longer exposure windows, and a false sense of progress when workshops and roadmaps advance faster than enforcement. In practice, many organisations discover the problem only after they have spent months sequencing domains instead of reducing access risk around specific assets.

How the Architecture Model Changes Implementation

Zero Trust works best when teams start with a clearly bounded protect surface and apply policy, identity, device, and session controls end to end around that scope. The architecture question is not whether identity, endpoints, network segmentation, telemetry, and response are all perfect first. It is whether access to the thing that matters is continuously verified and constrained by policy. That means the team can advance multiple control planes in parallel, provided each one measurably improves the same protected boundary.

A maturity-path interpretation breaks this logic in several ways. First, it encourages serial dependency planning, where identity is “done” before network work begins, even though both may be needed to protect the same resource. Second, it can overvalue documentation and scoring over enforcement, so the programme appears advanced while real traffic still relies on broad trust. Third, it often expands scope too early. Instead of proving the model on a critical application, data set, or service, the team tries to uplift the whole enterprise at once and slows itself down.

Protect the smallest meaningful surface first, then extend the pattern to adjacent services.
Use policy decisions that combine identity, device state, and context, rather than relying on a single control family.
Measure whether access paths are shrinking, not whether a roadmap has reached a later stage.

The model also matters for governance: architecture lets security and platform teams test whether a control removes implicit trust, while maturity models often reward sequence completion even when the underlying exposure remains. This guidance breaks down when an organisation has not defined any protect surface at all, because then neither architecture nor maturity can be implemented coherently.

Where the Maturity Trap Shows Up, and What to Watch For

Tighter access control often increases coordination overhead, requiring organisations to balance faster risk reduction against slower cross-team sequencing. That tradeoff becomes most visible in mixed estates where cloud, on-premises, legacy, and identity tooling do not move at the same pace.

One common edge case is partial adoption across a high-value application estate. A team may complete conditional access for users but leave service accounts, admin paths, or east-west traffic outside the policy boundary. Another is control substitution, where an organisation assumes network segmentation alone equals Zero Trust, or treats MFA rollout as the finish line. Those are implementation fragments, not the architectural outcome.

There is also a genuine governance nuance: a maturity roadmap can still be useful for funding and sequencing, but only if it serves the architecture rather than replacing it. That distinction is important because the industry largely agrees that Zero Trust should be iterative, but there is less consensus on how to score “maturity” without creating artificial gates. The safest reading is to treat maturity as a reporting construct and architecture as the operating model.

When the approach breaks down, it is usually because teams confuse progress visibility with exposure reduction. If the access policy is not changing for a real protect surface, the model is not advancing even if the programme calendar is.

Risk and Threat Considerations

The main risk in linearising Zero Trust is architectural delay that preserves implicit trust longer than necessary. That creates a larger attack window around applications, identities, devices, and internal paths that should have been narrowed earlier. It can also leave organisations with uneven enforcement, where some trust boundaries are tightened while adjacent ones remain easy to abuse.

Failure mechanism: Sequencing broad transformation work turns Zero Trust into a dependency chain. Attackers and abuse cases benefit when high-value access paths remain governed by legacy trust assumptions, especially where segmentation, session validation, or privilege checks have not yet been applied to the same protect surface.

Impact: The organisation may believe it is “in progress” while still exposing lateral movement paths, overly broad access, and inconsistent policy enforcement. That weakens containment, slows detection of abnormal access, and makes recovery harder because the architectural boundary was never actually reduced.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST AI RMF, NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST AI RMF	GOVERN — Govern	Architectural AI-style governance parallels iterative trust-boundary design.
Recommendation — Define decision boundaries around protect surfaces and govern access continuously.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	Zero Trust failures arise when access control stays broad or sequentially delayed.
Recommendation — Tighten identity and access decisions around each protect surface as work progresses.
CIS Controls v8	6 — Access Control Management	The topic centers on reducing implicit trust and uncontrolled access paths.
Recommendation — Remove unnecessary access paths and verify least-privilege enforcement on priority assets.
NIST Zero Trust (SP 800-207)	1 — Enterprise Architecture	The question directly concerns Zero Trust as an architectural model, not a maturity path.
Recommendation — Model Zero Trust as architecture around protect surfaces rather than a phased checklist.

Practitioner Guidance

What to prioritise: Define one protect surface with enough business value to justify end-to-end policy enforcement. If the team cannot name the asset, service, or data set that is being protected, the initiative is still a programme exercise rather than an architectural one.

Decision rule: If a proposed step does not reduce implicit trust for the chosen surface, treat it as supporting work, not a prerequisite. That helps avoid the common mistake of waiting for one domain to be “complete” before another can begin.

What to verify: Check whether access decisions actually depend on more than one control plane, and whether exceptions are shrinking over time. A credible implementation shows narrower access paths, not just more documentation, workshops, or policy language.

Practitioner takeaway: Zero Trust succeeds when teams prove enforcement around a real boundary, not when they advance through a maturity checklist that leaves the same trust assumptions intact.