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 is a practical guide to Zero Trust security that argues modern defenders must replace implicit trust with continuous verification, least privilege, and containment.
Why it matters: It matters because IAM, PAM, NHI, and workload teams all have to operationalise trust decisions across identities that move, persist, and connect dynamically.
By the numbers:
- 90% of organizations have yet to achieve advanced cyber resilience as they struggle to operationalize Zero Trust strategies.
- Over 600 million cyberattacks occur daily.
- The average cost of a data breach totals $4.88M.
👉 Read Zero Networks' guide to practical Zero Trust security and implementation
Context
Zero Trust security is a governance model that removes implicit trust and forces every access decision to be verified before it is granted. That matters for identity programmes because the model applies to people, service accounts, applications, and workloads, not just remote users at the perimeter.
The article’s core claim is that Zero Trust only works when the architecture can actually enforce least privilege and containment across identity, network, application, and data layers. In practice, that means the control problem is not philosophical, it is operational: if identities can still move laterally or keep standing access, the model has not been implemented.
For IAM, PAM, and NHI teams, the relevant question is whether access is continuously evaluated and whether privileged pathways are closed by default. That starting point is typical of mature Zero Trust guidance, but atypical of most enterprise environments.
Key questions
Q: How should security teams implement zero trust for workloads?
A: Start by binding identity to the workload, not to the network location. Then enforce per-request authorisation, preserve identity across proxies and service boundaries, and issue only short-lived credentials that are scoped to the task. If identity is lost at any hop, the design is still perimeter-based in practice.
Q: Why do service accounts and workloads complicate Zero Trust programmes?
A: Because they often authenticate successfully but are governed like infrastructure, not identities. That creates standing access paths that are rarely reviewed with the same rigour as human access. Zero Trust only works when non-human identities are subject to the same policy discipline, telemetry, and revocation logic as any other actor.
Q: What breaks when segmentation is too coarse in a Zero Trust programme?
A: Attackers can move laterally once they get a foothold because large trust zones still behave like internal networks. Coarse segmentation leaves too many reachable assets behind one compromised identity. The result is a containment failure, not just a visibility problem.
Q: Who is accountable when Zero Trust only covers part of the environment?
A: Accountability sits with the security and identity owners who accepted exceptions without defining how risk would be contained, monitored, and reviewed. Framework alignment is strongest when access governance, telemetry, and privileged controls are managed as one programme rather than disconnected tools.
Technical breakdown
Zero Trust security vs zero trust architecture
Zero Trust security is the policy intent: assume breach, verify explicitly, and minimise implicit trust. Zero trust architecture is the implementation layer that turns that intent into enforceable workflows, policies, and control points. NIST SP 800-207 describes the distinction clearly. The security model can exist as a principle, but architecture is what determines whether identities, devices, workloads, and applications are actually subjected to per-request decisions rather than static trust assumptions.
Practical implication: Treat Zero Trust as an architecture programme, not a label, and validate that access decisions are enforced at real control points.
Why least privilege and continuous verification matter for identities
Least privilege in Zero Trust is not just about reducing permissions. It is about making access conditional, short-lived, and context-aware so that identity does not imply enduring trust. Continuous verification means the organisation keeps checking identity, device state, and network context instead of trusting a one-time login or a persistent session. This is especially important for service accounts and workloads, where standing access often outlives the business reason for it and creates lateral movement paths.
Practical implication: Rebuild privileged access so that identities receive only the minimum access needed for the current task and context.
How microsegmentation and ZTNA work together
Zero Trust Network Access controls who can reach a resource from the outside, while microsegmentation limits what can happen once an identity is inside. These are different control layers, and relying on one without the other leaves a gap. ZTNA can reduce exposure at the edge, but microsegmentation is what constrains east-west movement inside the environment. The article correctly notes that attackers usually need only one foothold before they hunt for higher-value systems.
Practical implication: Use ZTNA for entry control and microsegmentation for internal containment, especially around admin interfaces, databases, and legacy systems.
Threat narrative
Attacker objective: The objective is to expand from a single foothold into privileged access that reaches sensitive systems while remaining hard to contain.
- Entry occurs when an attacker gains a foothold through a compromised identity, exposed credential, or other initial access path and reaches an internal trust boundary.
- Escalation follows when the attacker uses standing access, open ports, or over-privileged accounts to move laterally and reach higher-value systems.
- Impact occurs when the attacker reaches sensitive workloads or crown-jewel assets that were not isolated well enough to contain the breach.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Zero Trust fails when organisations treat it as a perimeter strategy rather than an identity governance model. The article is right to emphasise continuous verification and least privilege, but the deeper issue is that trust now has to be enforced across people, service accounts, and workloads. If access can still persist without active contextual checks, then Zero Trust exists in policy language only. Practitioners should measure whether identity governance actually follows the architecture.
Standing privilege is the governance flaw Zero Trust is meant to eliminate. Lateral movement is not a network-only problem. It is what happens when accounts, ports, and permissions remain open after the business need has passed. Zero Trust maturity depends on removing those persistent pathways across human IAM, PAM, and NHI estates, because containment is only real when privilege is ephemeral or tightly bounded.
Identity blast radius is the right named concept for modern Zero Trust programmes. The article points to mini fortresses, but the practical question is how much damage a single identity can still do after compromise. That blast radius is determined by segmentation, privilege scope, and how quickly access can be withdrawn. Teams should treat blast radius as a control outcome, not an abstract design goal.
Zero Trust architecture is becoming the common control plane for human, NHI, and workload access decisions. The model spans multiple actor types, which is why IAM, PAM, and workload identity cannot be treated as separate conversations. The organisations that progress fastest are the ones that align access policy, segmentation, and verification across all three. Practitioners should build one governance model with actor-specific enforcement.
Least privilege only works when access decisions are dynamically enforceable at runtime. The article’s emphasis on JIT access and continuous monitoring reflects a broader market shift: static provisioning is no longer sufficient in environments where identities, devices, and services change constantly. The control that matters is the one that can respond at the speed of the connection. Practitioners should align policy design with runtime enforcement, not review cadence.
From our research:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
- That confidence gap is one reason to revisit Ultimate Guide to NHIs - Key Challenges and Risks alongside this Zero Trust model.
What this signals
Identity blast radius: Zero Trust only becomes operational when teams can measure how far a compromised identity can actually move before containment stops it. That requires aligning segmentation, privilege scope, and verification cadence across NIST SP 800-207 Zero Trust Architecture and the identity stack, not treating them as separate workstreams.
The biggest programme risk is still visibility. With 85% of organisations lacking full visibility into third-party OAuth-connected vendors, according to The State of Non-Human Identity Security, Zero Trust designs that ignore NHI and delegated access will leave unmanaged trust paths in place.
For practitioners, the next step is to connect Zero Trust policy with runtime identity control and workload isolation. Resources such as Guide to SPIFFE and SPIRE help translate that model into workload identity decisions that can actually be enforced.
For practitioners
- Map identity and connection pathways first Inventory users, service accounts, workloads, and applications, then map how they communicate before changing policy. This reveals which connections are truly necessary and where implicit trust still exists.
- Isolate crown-jewel systems with granular segmentation Place domain controllers, databases, admin interfaces, and legacy systems behind identity-informed segmentation so broad network reach is not the default condition.
- Replace standing privilege with task-scoped access Use just-in-time access patterns for privileged pathways and close sensitive ports by default. Access should open only for the right identity, from the right device, for the right task.
- Automate policy enforcement across changing environments Generate and update segmentation and access policies from observed behaviour so new devices, services, and identities do not create unmanaged trust gaps.
Key takeaways
- Zero Trust is an enforcement model, not just a security philosophy, and it fails when implicit trust remains inside the environment.
- The main evidence point is operational weakness, with 90% of organisations still not at advanced cyber resilience while attackers keep exploiting lateral movement paths.
- Practitioners should focus on runtime identity control, segmentation, and task-scoped privilege because those are the controls that shrink blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access decisions are central to the article's Zero Trust model. |
| NIST SP 800-53 Rev 5 | AC-6 | The article centres on least privilege and constrained access enforcement. |
| NIST Zero Trust (SP 800-207) | Section 2.1 | The article directly explains the distinction between Zero Trust security and architecture. |
| MITRE ATT&CK | TA0008 , Lateral Movement; TA0004 , Privilege Escalation | The article focuses on attacker movement after initial foothold and privilege expansion. |
| CIS Controls v8 | CIS-6 , Access Control Management | Access control management is the operational heart of the article's guidance. |
Map segmentation and privilege controls to lateral movement and escalation paths, then test containment.
Key terms
- Zero Trust Architecture: A practical implementation of Zero Trust security that turns the philosophy of continuous verification into enforceable policies, workflows, and control points. In practice, it defines how identities, devices, workloads, and applications are checked before access is granted and how trust is continuously reduced after entry.
- Microsegmentation: A containment technique that divides the environment into small, identity-aware trust zones. It limits lateral movement by ensuring a compromised identity cannot automatically reach unrelated systems, even if it is already inside the network.
- Just-in-Time Access: A privilege pattern that grants access only when a task requires it and removes it as soon as the task is complete. In Zero Trust programmes, it reduces standing privilege and shortens the time window in which an attacker can abuse credentials or ports.
- Identity Blast Radius: The amount of damage a single identity can cause if it is compromised or misused. The term captures privilege scope, reachable systems, and containment quality, which makes it a useful way to assess whether Zero Trust is actually reducing risk.
What's in the full article
Zero Networks' full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step breakdown of Zero Trust implementation stages, from inventory and baseline to policy automation.
- Specific guidance on combining ZTNA and microsegmentation without creating fragmented enforcement.
- Examples of common Zero Trust pitfalls, including performance trade-offs and internal lateral movement gaps.
- Product-level detail on the controls Zero Networks uses to operationalise identity-informed segmentation.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing identity security across users, workloads, and automated systems, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org