TL;DR: Zero Trust replaces implicit network trust with continuous verification, least privilege, and containment, and the article argues that 90% of organisations still struggle to operationalise it while attackers continue moving laterally after a foothold, according to Zero Networks. The governance problem is not the idea of Zero Trust, but the gap between architectural intent and enforceable identity, network, and workload controls.
At a glance
What this is: This guide argues that Zero Trust security fails when teams treat it as policy alone rather than enforceable identity, network, and workload control.
Why it matters: IAM, PAM, NHI, and security architecture teams need to see where Zero Trust becomes operationally real, because least privilege and containment depend on enforcement, not branding.
By the numbers:
- 90% of organisations have yet to achieve advanced cyber resilience as they struggle to operationalize Zero Trust strategies.
Context
Zero Trust security is a governance model for environments where implicit trust no longer holds, but its value depends on enforcement rather than aspiration. In identity programmes, that means every user, device, service account, workload, and application must be evaluated through explicit access rules instead of assumed network trust.
The article’s central problem is the gap between Zero Trust policy and operational control. That gap matters to IAM, IGA, PAM, and NHI teams because least privilege, continuous verification, and containment only reduce risk when they are reflected in identity decisions, segmentation, and access lifecycle enforcement.
Key questions
Q: What breaks when Zero Trust is applied only at the perimeter and not to the connection itself?
A: Perimeter-only Zero Trust leaves internal traffic and service-to-service calls too exposed. Once an attacker reaches the environment, they can often move laterally, discover services, and abuse broad network access. Without connection-level authentication and segmentation, the policy boundary stays at the edge while the real workload interactions remain weakly controlled.
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.
Q: What are the signs that privileged access controls are too weak in a Zero Trust program?
A: Common warning signs include excessive privilege, unrestricted access that never expires, weak monitoring of privileged activity, and inconsistent enforcement of authentication checks. If teams cannot explain who has access, for how long, and under what conditions, the control environment is too loose. Misconfigurations, blind spots, and manual exceptions usually appear before a major access failure.
Q: What should teams do when a Zero Trust programme still allows lateral movement?
A: They should treat the problem as an enforcement gap, not a branding issue. The immediate focus should be the paths that remain open after authentication, because those are the routes attackers use to escalate and reach high-value assets.
Technical breakdown
Why Zero Trust security depends on enforceable identity decisions
Zero Trust is not a product category. It is a security model that removes implicit trust and requires every access request to be evaluated against identity, device, context, and policy before permission is granted. In practice, that means the model lives or dies on access enforcement points, not on whether an organisation has adopted the language of Zero Trust. For human identities, that often means MFA and conditional access. For NHIs and workloads, it means authenticators, privileges, and communication paths must be governed continuously, not assumed safe because they sit inside the network.
Practical implication: map every access path to the control that actually enforces least privilege, not the policy that describes it.
Microsegmentation and ZTNA solve different parts of the same problem
Zero Trust architecture separates outside-in access control from inside-the-network containment. Zero Trust Network Access limits who can reach a resource, while microsegmentation limits where an authenticated identity can move once inside. Without both, lateral movement remains possible because the attacker or over-privileged identity still finds open internal pathways. This distinction matters because many programmes stop at perimeter-style enforcement and call the result Zero Trust. The architecture only behaves as intended when access and movement are constrained together across users, services, and workloads.
Practical implication: validate both external access controls and internal segmentation before claiming Zero Trust maturity.
Why least privilege must be runtime-aware for users, services, and workloads
Least privilege in Zero Trust is not a one-time role assignment. The article points to just-in-time controls, continuous verification, and adaptive policy enforcement because standing access and broad permissions are what enable lateral movement after a foothold. That makes lifecycle and runtime governance central for service accounts, privileged users, and connected workloads alike. If access is granted for longer than the task requires, the control starts protecting the wrong thing. The effective unit of enforcement is the current session, connection, or communication path, not the abstract role on paper.
Practical implication: shift high-risk access from standing entitlement to task-scoped, continuously verified permission.
NHI Mgmt Group analysis
Policy without enforcement is not Zero Trust, it is documentation. The article is right to separate the philosophy from the architecture, because a written least-privilege model does not change attacker movement by itself. What matters is whether identity, device, network, and workload controls enforce the policy at the point of access. Practitioners should judge Zero Trust by containment outcomes, not by whether the policy exists.
Zero Trust exposes an operational gap, not a conceptual one. Most organisations do not fail because they reject the idea of continuous verification. They fail because their enforcement points still allow standing access, broad network reach, or unmanaged service-to-service trust. The lesson for IAM and NHI teams is that governance must be expressed as runtime control, not just architecture diagrams.
Least privilege must become a living control plane, not a provisioning event. The article’s strongest practical signal is that attackers exploit what remains open after initial authentication. That makes privilege duration, connection scope, and segmentation boundaries the real control variables. Teams should treat access persistence as the thing to eliminate, not simply the thing to review later.
Zero Trust is now a cross-domain identity problem. Human authentication, service account governance, workload connectivity, and privileged access are all part of the same enforcement chain. A programme that isolates these disciplines will keep producing policy that cannot be operationalised. The practitioner conclusion is to align governance, access, and containment under one model.
Runtime containment is the named concept this article surfaces. Zero Trust becomes meaningful only when the environment can restrict what an identity can do after it authenticates, not just whether it can authenticate. That is the point at which least privilege, segmentation, and verification converge into a defensible identity security posture. Practitioners should use that concept to test whether their Zero Trust programme is enforceable or aspirational.
From our research library:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- 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
Runtime containment: Zero Trust programmes only change risk when they reduce what an authenticated identity can still do after login. That means the practical question is not whether policy exists, but whether the policy is enforced at identity, network, and workload boundaries.
The next governance test is whether service accounts, admin paths, and east-west traffic are all constrained by the same least-privilege logic. If internal movement is still possible after authentication, the programme is closer to access management than to Zero Trust.
NHI and PAM teams should expect Zero Trust to converge with lifecycle control and segmentation design. In mature programmes, the same governance model governs who can enter, what they can reach, and how far they can move.
For practitioners
- Map policy to enforcement points Inventory where access is actually allowed, denied, or narrowed across identity providers, network controls, and workload layers. If a rule cannot be tied to a live control, it is only intent.
- Remove standing access from high-risk paths Prioritise privileged users, service accounts, admin interfaces, and east-west connections that remain open outside the exact task window.
- Separate external access from internal containment Treat remote access controls and internal segmentation as different enforcement problems. Confirm that a successful login does not automatically create broad internal reach.
- Baseline communication patterns before tightening policy Use observed traffic and identity relationships to define what normal access looks like, then enforce only those paths that are required for business operation.
- Test whether access is task-scoped or persistent Review whether privileged connectivity survives beyond the purpose for which it was granted. Persistent reach is the clearest sign that Zero Trust remains aspirational.
Key takeaways
- Zero Trust fails when organisations stop at policy and never convert least privilege into enforceable access and containment controls.
- The article’s own evidence says 90% of organisations still struggle to operationalise Zero Trust, which points to a maturity gap rather than a concept gap.
- Practitioners should focus on runtime enforcement, internal segmentation, and removal of standing access if they want Zero Trust to reduce lateral movement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST Zero Trust (SP 800-207), NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture — Zero Trust Architecture | The article is fundamentally about turning zero trust concepts into an enforceable architecture. |
| Recommendation — Define access policies, enforcement points, and trust boundaries before calling the programme Zero Trust. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Least privilege and access enforcement are the article's core governance issue. |
| Recommendation — Review permissions and entitlements for runtime enforcement, not just for policy alignment. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article repeatedly centres least privilege as the control principle behind Zero Trust. |
| Recommendation — Apply least-privilege controls to remove standing access and narrow privilege scope. | ||
| CIS Controls v8 | CIS-5 — Account Management | Standing access and overprivileged accounts are identified as major failure points. |
| Recommendation — Harden account management to eliminate persistent access paths that enable lateral movement. | ||
| MITRE ATT&CK | TA0004; TA0008 — Privilege Escalation; Lateral Movement | The article describes the attack progression Zero Trust is meant to contain. |
| Recommendation — Map open internal pathways to privilege escalation and lateral movement opportunities. | ||
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.
- Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
- Microsegmentation: A network control approach that divides environments into small security zones with explicit rules between them. Its purpose is to limit lateral movement and reduce blast radius when an identity, workload, or device is compromised.
- Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
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 12, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org