TL;DR: The NSA’s Zero Trust Implementation Guidelines translate Zero Trust into 91 measurable activities across discovery, identity, segmentation, visibility, and automation, while the article says 88% of CISOs still struggle to implement it and 90% of security leaders see it as central to security posture, according to Zero Networks. The real issue is not Zero Trust intent, but the gap between policy language and enforceable operational controls.
At a glance
What this is: This is an analysis of the NSA’s Zero Trust Implementation Guidelines and the article’s central claim that Zero Trust fails when principles are not translated into enforceable operational controls.
Why it matters: It matters because IAM, PAM and network security teams have to align identity decisions, segmentation and continuous enforcement if Zero Trust is going to work beyond policy language.
By the numbers:
- The NSA’s Zero Trust Implementation Guidelines cover 91 activities across five modular phases.
- 88% of CISOs have experienced significant challenges in their Zero Trust implementation attempts.
Context
Zero Trust is not a policy statement. It is an operating model that only works when identity, device state, segmentation and enforcement points are tied together in real time.
The article argues that the NSA’s Zero Trust Implementation Guidelines are useful because they convert a broad architecture idea into measurable activities, but the real difficulty is operational execution rather than agreement on the principle.
For IAM teams, the practical question is how to move from login-centric controls to continuous, identity-aware enforcement across internal traffic, privileged paths and system-to-system access.
Key questions
Q: What breaks when Zero Trust only covers login and privileged access?
A: Security gaps remain in applications, cloud services, and machine identities that are not subject to the same verification discipline. That creates inconsistent enforcement and weak visibility, which means attackers or misconfigurations can move through areas the programme was never designed to govern. Coverage has to extend beyond the front door to matter.
Q: Why does Zero Trust adoption stall even when organisations agree with the model?
A: Adoption often stalls because the easiest option is to do nothing. Fear of blame, uncertainty about the right sequence, and lack of incentives can make teams avoid change even when the risk of inaction is higher. Zero Trust succeeds when leadership removes that hesitation and treats progress as a governed programme, not an optional experiment.
Q: What are the signs that a zero trust rollout is failing in practice?
A: Common warning signs include overlapping tools that do not integrate well, inconsistent policy enforcement across environments, weak visibility into asset and transaction flows, and users bypassing controls because processes are too cumbersome. If teams cannot tell who accessed what, when, and why, the program is not delivering the verification and control zero trust is supposed to provide.
Q: Should organisations prioritise identity governance before micro-segmentation in Zero Trust?
A: In most hybrid and cloud-first environments, yes. Identity governance addresses who gets access and whether that access still makes sense, while segmentation mainly constrains where traffic can go. If the underlying identity model is weak, segmentation often just contains bad access rather than preventing it.
Technical breakdown
Why Zero Trust breaks when enforcement stays at login
Zero Trust fails when organisations treat authentication as the only decision point. The article’s core mechanism is that trust must be re-evaluated where access is used, not only where a session begins. That requires identity-aware network enforcement, default-deny internal access, and policy decisions that follow the request context across east-west traffic. Without those controls, internal communications inherit implicit trust even after the initial login is strong. In practice, this is the difference between a security slogan and an architecture that can contain breach impact.
Practical implication: move privileged and internal access decisions into network enforcement points instead of relying on perimeter login controls.
How segmentation and least privilege work together in Zero Trust
Segmentation limits where a compromised identity or workload can move, while least privilege limits what it can reach. The article shows these as mutually reinforcing controls rather than separate projects. Granular access rules must be evaluated continuously for identities, devices and workloads, and they need to be explicit for internal as well as external traffic. That matters because blast-radius reduction depends on both reachability design and access scope. If either is weak, lateral movement remains possible even in a nominally zero-trust environment.
Practical implication: align segmentation boundaries with identity-based access rules so every internal path is explicitly governed.
Why automation is part of Zero Trust operations, not an add-on
The NSA mapping in the article makes a practical point: static rules drift as environments change. Automation is needed to keep policy aligned with real communication patterns, reduce standing access, and avoid the human error that creeps into manual rule maintenance. This is not about replacing governance. It is about sustaining enforcement at a scale and speed that manual review cannot match. In Zero Trust programmes, automation becomes the mechanism that keeps continuous verification continuous.
Practical implication: automate policy lifecycle and access enforcement where manual updates would create drift or delay.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Zero Trust fails when organisations confuse adoption with enforcement: The article shows that broad agreement on Zero Trust does not solve the operational gap between architecture language and implementable controls. That gap is visible whenever identity and network policy remain separate, because internal trust still exists even when the perimeter has been modernised. Practitioners should treat Zero Trust as an enforcement model, not an intent statement.
Blast-radius control is the decisive operational outcome of Zero Trust: The strongest value in the NSA guidance is not the label of Zero Trust itself but the insistence on containment. Segmentation, default-deny internal access and continuous evaluation only matter if they reduce lateral movement when compromise happens. Practitioners should evaluate whether their current design can actually confine an identity or workload after initial access is granted.
Continuous enforcement exposes the weakness of static access design: A zero-trust programme that depends on one-time approvals, fixed exceptions or periodic cleanup is already behind the environment it is meant to govern. Modern networks change faster than static policy cycles, so the control model has to be context-aware and ongoing. Practitioners should expect policy drift unless enforcement is automated.
Operational discipline for Zero Trust: The NSA guidance effectively turns Zero Trust into a governance problem with measurable execution steps, not a philosophical position. That is why it is useful for boards and auditors as well as architects. Practitioners should use it to test whether access, segmentation and visibility are being governed as one system rather than three silos.
From our research library:
- By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
- Read next: Zero Trust Identity Guide
What this signals
Identity-aware enforcement is now the operational test of Zero Trust: Programmes that stop at MFA or perimeter logic will continue to miss the internal access paths that matter most. The architecture has to follow the request through the network, not sit only at the front door.
Zero Trust governance is becoming a measurement problem: The NSA-style activity model makes it easier to ask whether a programme can actually prove continuous enforcement, not just claim alignment. That shifts maturity discussions from policy coverage to observable control behaviour.
Policy drift is the hidden failure mode: Static segmentation and manual rule maintenance decay as applications change, which is why continuous verification and automation need to be part of the operating model, not a future enhancement.
For practitioners
- Tie identity to network enforcement Move privileged and sensitive internal access decisions to enforcement points that evaluate identity, device and context together instead of only at login.
- Remove implicit internal trust Default-deny east-west traffic and explicitly approve internal communications that are required for business function, including system-to-system flows.
- Automate segmentation policy lifecycle Use automation to keep segmentation boundaries and access rules aligned with live traffic patterns so policy does not drift as systems change.
- Build continuous verification into access paths Require repeated trust evaluation for privileged paths so access remains valid only while the current context still justifies it.
- Map internal dependencies before tightening controls Inventory which applications, workloads and services depend on each other so segmentation changes do not break legitimate traffic while still shrinking blast radius.
Key takeaways
- Zero Trust is still failing in many organisations because the architecture is not being enforced where access is actually used.
- The article’s main evidence is the NSA’s 91 activities model, which turns an abstract framework into measurable operating work.
- The decisive control shift is from static policy to continuous, identity-aware enforcement that can reduce lateral movement and contain breach impact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | Zero Trust Principles — Zero Trust Principles | The article centres on operationalising Zero Trust Architecture and continuous enforcement. |
| Recommendation — Apply Zero Trust principles at enforcement points that evaluate identity, device and context continuously. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Identity-aware access decisions and least privilege are central to the article's guidance. |
| Recommendation — Align access permissions and authorisations to live context instead of static trust assumptions. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article stresses reducing standing access and controlling privileged paths. |
| Recommendation — Review and restrict privileged accounts so access is explicit, current and operationally enforced. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is a core theme in the article's internal access and segmentation guidance. |
| Recommendation — Enforce least privilege across internal and privileged network paths, not only at authentication. | ||
Key terms
- Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
- Identity-Aware Enforcement: Identity-aware enforcement is policy decisioning that uses who the user is and which account or context they are using. For browser AI, it helps distinguish sanctioned corporate use from unmanaged personal sessions and applies different controls based on that distinction.
- Continuous Verification: A Zero Trust practice that re-evaluates trust during the session instead of relying on a single successful login. The control is stronger when context signals are available in real time and when the identity programme can act on those signals without creating excessive exceptions.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org