Zero trust access still depends on continuous identity proofing

At a glance

What this is: This is a practitioner-oriented summary of NIST SP 1800-35 that argues Zero Trust must be implemented as continuous, context-aware identity enforcement, not as a one-time perimeter replacement.

Why it matters: It matters because IAM, NHI, and autonomous access programmes all fail when access decisions are static, overly broad, or detached from runtime context.

By the numbers:

• NHI outnumber human identities by 25x to 50x in modern enterprises.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read Pomerium's analysis of NIST SP 1800-35 and Zero Trust implementation

Context

Zero Trust Architecture is a model that assumes no implicit trust, even inside the network boundary. The practical challenge is that many organisations still treat identity as a login event instead of a continuous control surface, which leaves access decisions too static for modern environments.

This post is about how NIST SP 1800-35 turns Zero Trust into an implementable programme, especially where identity, context, and policy must align across human users, service accounts, and other non-human identities. The article’s starting position is typical: many teams understand the concept before they understand the operating model.

Key questions

Q: How should security teams implement Zero Trust without turning it into a one-time project?

A: Treat Zero Trust as a continuous operating model, not a deployment milestone. Start with identity-centric enforcement, then phase in context-aware access, segmentation, and monitoring. The key is to keep policy, identity data, and lifecycle events in sync so access decisions stay current as systems, users, and services change.

Q: Why do non-human identities matter so much in Zero Trust programmes?

A: Because service accounts, tokens, and other non-human identities often hold broad privileges and are poorly visible, they can bypass the assumptions that Zero Trust is built on. If those identities are not governed, the programme protects the network perimeter while leaving the most powerful access paths exposed.

Q: What breaks when access policies are not continuously revalidated in a Zero Trust model?

A: Static policies quickly drift away from reality. When access is not revalidated, stale entitlements, device changes, and privilege creep remain in place long enough for misuse or lateral movement. The result is a Zero Trust architecture in name only, because trust is still effectively granted once and reused.

Q: Who should own Zero Trust policy decisions in a mature identity programme?

A: Ownership should sit across security architecture, IAM, and the business systems that consume identity signals. Zero Trust fails when policy is owned only as a network control or only as an authentication control. The organisation needs clear accountability for identity truth, policy logic, and ongoing review.

Technical breakdown

Continuous verification and context-aware authorisation

NIST’s guidance treats access as a live decision, not a one-time authentication outcome. That means policy evaluates identity, device posture, resource sensitivity, location, and anomalous behaviour at the moment of access. This is the technical shift that makes Zero Trust different from perimeter-era controls. Identity is no longer a static label attached to a session. It becomes an input to ongoing authorisation, which can tighten or revoke access as conditions change. Practical implementations depend on policy engines that can re-evaluate risk in real time rather than at login only.

Practical implication: design access policies that can be re-evaluated during the session, not only at authentication.

Enhanced identity governance in Zero Trust architecture

NIST SP 1800-35 does not treat identity governance as a side activity. Enhanced identity governance is one of the core implementation patterns because access must be tied to role, need, and scope continuously. That matters for both human and non-human identities, because standing privilege and stale entitlements undermine least privilege even when the network is segmented. In practice, Zero Trust depends on governance signals that are current, accurate, and enforceable across systems, not just documented in policy. Without that, the architecture remains conceptually sound but operationally weak.

Practical implication: connect identity governance data to enforcement points so entitlement changes affect access decisions immediately.

Phased zero trust implementation and policy lifecycle

The NCCoE’s reference builds reflect a crawl-walk-run approach because Zero Trust is an operating model, not a single deployment. Organisations need to sequence identity controls, application access, segmentation, and monitoring over time while preserving business continuity. The important technical point is that policy lifecycle never ends. As environments change, access rules, trust signals, and application paths all need review and adjustment. That makes Zero Trust closer to a managed programme than a product purchase, especially in hybrid estates with multiple identity types and integration points.

Practical implication: plan Zero Trust as a staged programme with continuous policy review, not a one-off migration.

Threat narrative

Attacker objective: The objective is to preserve or expand access long enough to reach sensitive systems and data without triggering a new trust decision.

1. Entry begins when an attacker or insider reaches a resource through an access path that still relies on implicit trust or broad network reach.
2. Escalation occurs when static entitlements, weak context checks, or standing privilege allow movement from one resource to another without renewed verification.
3. Impact follows as lateral movement, over-broad access, or persistent misuse expands the blast radius across applications and data.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

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 identity is treated as a boundary event rather than a live control surface. NIST SP 1800-35 reinforces that access must be re-evaluated against context, not assumed safe after login. That shift matters because modern environments contain far more identities than humans, and many of them are machines or services. Practitioners should read this as a governance reset, not a tooling tweak.

Enhanced identity governance is the missing operating layer in many Zero Trust programmes. Segmentation and policy enforcement do not compensate for stale entitlements, poor visibility, or unmanaged service identities. The most common failure mode is not absence of strategy, but absence of current identity truth feeding the policy decision. The implication is that Zero Trust maturity depends as much on identity lifecycle discipline as on network architecture.

Continuous authorisation exposes the limits of static access models across human and non-human identities. A permission model created at provisioning time cannot fully reflect real-time context, especially where service accounts and other non-human identities carry excessive privilege. That is why Zero Trust increasingly converges with NHI governance. Practitioners should expect identity security and access control to be managed as one control plane, not separate disciplines.

Identity blast radius is the right named concept for this article’s core lesson. The problem is not simply unauthorised access, but how far a granted identity can move once trust is accepted too broadly. Zero Trust reduces that radius only when identity scope, context, and enforcement stay aligned throughout the session. The practical conclusion is that blast-radius control is now a primary design objective for IAM and NHI programmes.

Zero Trust validates the direction of modern identity governance, but it also raises the bar for operational accuracy. If policy engines are fed outdated identity data, the architecture becomes selective rather than continuous. That creates a gap between declared least privilege and actual runtime access. Practitioners should treat identity quality, entitlement freshness, and policy recertification as core security controls.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• For a broader baseline: Read Ultimate Guide to NHIs for visibility, rotation, and offboarding patterns that make Zero Trust operational.

What this signals

Identity governance is becoming the deciding factor in Zero Trust maturity. The architectural model now depends on the quality of identity signals, the freshness of entitlement data, and the ability to enforce policy continuously across human and machine accounts. In practice, that means Zero Trust programmes should be measured by how quickly they can translate identity change into access change, not by how many control points they have.

Service accounts will increasingly expose the gap between declared least privilege and actual runtime privilege. Many teams have strong perimeter and segmentation stories but weak non-human identity discipline, which leaves broad access intact inside the trust fabric. If the identity layer is not current, the rest of the architecture becomes an optimistic assumption rather than a control.

Zero Trust and NHI governance are converging into a single operational problem. The stronger the identity signal, the more accurately policy can reflect intent, scope, and risk. That is why teams should pair identity lifecycle controls with continuous enforcement and keep a close watch on workload identities, certificate-backed access, and privileged service paths.

For practitioners

• Bind policy to runtime context Require access decisions to re-evaluate identity, device, and resource context during the session, not just at login. This matters most for privileged applications and admin paths where broad access can become lateral movement quickly.
• Treat service accounts as first-class Zero Trust subjects Inventory non-human identities alongside user identities, then map each service account to its actual resource scope, rotation state, and privilege boundary. Zero Trust breaks down when machine identities are left outside the governance model.
• Connect lifecycle events to enforcement Make joiner, mover, and leaver updates affect access policy immediately so stale entitlements do not survive long enough to be abused. The same rule should apply to certificate renewal, token expiry, and workload offboarding.
• Validate policy drift continuously Review whether access rules still match business use cases, separation of duties, and least-privilege intent as environments evolve. A Zero Trust programme that is not continuously validated will drift back toward implicit trust.

Key takeaways

• Zero Trust only delivers on its promise when access is continuously re-evaluated against current identity and context.
• Non-human identities are central to Zero Trust success because excessive privilege and stale entitlements can defeat the model from inside.
• The practical test is not whether Zero Trust has been adopted, but whether identity changes are reflected in enforcement fast enough to shrink the attack surface.

Key terms

• Zero Trust Architecture: A security model that assumes no implicit trust and requires every access request to be evaluated in context. In practice, it shifts access control from network location to identity, device, resource sensitivity, and policy state, with verification continuing throughout the session rather than stopping at login.
• Continuous verification: A control pattern where access is re-checked as conditions change instead of being granted once and left alone. For Zero Trust, that means identity, posture, behaviour, and resource context can all trigger tighter policy or revocation when risk moves outside the approved boundary.
• Enhanced identity governance: An identity governance approach that feeds real-time policy enforcement with accurate entitlement, role, and lifecycle data. It is especially important in Zero Trust because static records and stale access reviews cannot support dynamic decisions across human and non-human identities.
• Identity blast radius: The amount of systems, data, and actions an identity can reach if it is compromised or over-privileged. In Zero Trust programmes, reducing blast radius means narrowing scope continuously so one accepted identity does not become a broad internal access path.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Pomerium: 5 Key Takeaways about ZTA from NIST SP 1800-35. Read the original.