Zero trust access still depends on continuous identity proofing

At a glance

What this is: This is Pomerium's analysis of NIST SP 1800-35, arguing that zero trust depends on continuous identity verification, context-aware enforcement, and ongoing policy validation.

Why it matters: IAM and security teams need this because zero trust fails when identity, context, and authorisation drift apart across sessions, resources, and change cycles.

Context

Zero trust is not a single product or perimeter replacement. It is an access model that verifies each request using identity, context, and policy rather than assuming trust because a user, device, application, or service is already inside the network.

For identity programmes, the practical challenge is not defining least privilege once. The challenge is keeping proof, policy, and enforcement aligned as roles change, device posture shifts, and resource sensitivity varies across a distributed environment.

NIST SP 1800-35 matters because it translates Zero Trust Architecture into implementation patterns that organisations can actually test. The article treats continuous identity proofing as a governance requirement, not a one-time login check.

Key questions

Q: How should security teams implement zero trust identity enforcement in a phased way?

A: Start with the access paths that concentrate the most sensitive resources and the weakest current controls. Build policy, telemetry, and enforcement together, then expand in stages so each new boundary is validated before the next one is added. That sequencing keeps zero trust practical and prevents architecture from outrunning governance.

Q: Why does continuous identity proofing matter in zero trust architectures?

A: Because authorisation decisions age quickly in distributed systems. If identity, device posture, or resource sensitivity changes after login, a one-time check no longer represents the current risk. Continuous proofing keeps the access decision tied to live context instead of stale assumptions, which is the core operating principle of zero trust.

Q: What breaks when zero trust policies are only validated at deployment time?

A: The control starts to drift away from real use cases. Policies that looked correct during rollout can become too broad, too narrow, or misaligned with changed business needs, leaving either blocked workflows or overpermissive access. Ongoing validation is what keeps least privilege and separation of duties intact over time.

Q: What is the difference between perimeter security and resource-level zero trust enforcement?

A: Perimeter security assumes trust based on location or network membership, while resource-level zero trust evaluates each request against identity, context, and policy at the point of access. That difference matters because distributed environments no longer have a reliable inside boundary, and access decisions must follow the resource, not the network edge.

Technical breakdown

Why static perimeter trust breaks in zero trust architecture

Traditional perimeter security assumes that traffic or identities inside the boundary are safe enough to trust by default. Zero Trust Architecture replaces that assumption with per-request verification, which means identity, device state, resource sensitivity, and policy all contribute to the decision. In practice, this shifts control from network location to access intent and current risk. NIST SP 1800-35 frames this as a move from broad internal trust to resource-level authorisation, where each request is evaluated on its own merits. That makes the access plane more precise, but also more dependent on current identity data and policy hygiene.

Practical implication: Treat network position as irrelevant to authorisation unless the current request can still be justified by verified identity and context.

How continuous context-aware enforcement changes identity governance

Continuous verification means access is not decided only at login. The policy engine keeps reassessing contextual inputs such as device posture, geolocation, resource sensitivity, and anomalous behaviour during the session. This matters because the trust decision can change even when the user’s identity does not. For NHI and human identities alike, that means access governance has to account for state drift after the initial authentication event. NIST SP 1800-35’s value is that it makes this dynamic enforcement operational rather than theoretical: the access decision becomes an ongoing control loop, not a single checkpoint.

Practical implication: Design governance so that access can be re-evaluated mid-session when context changes, not just at sign-in.

Why phased ZTA deployment is the realistic implementation path

NIST SP 1800-35 explicitly uses phased implementation because most enterprises cannot refactor identity and access controls overnight. Its crawl, walk, and run model reflects the reality of legacy estates, mixed trust boundaries, and existing applications that cannot be re-architected immediately. The architectural lesson is that Zero Trust Architecture is incremental by necessity, not by preference. Organisations need to prioritise the highest-risk access paths first, then expand coverage as policy, telemetry, and enforcement mature. That sequencing also reduces the chance of over-promising a full ZTA posture before the underlying identity data is ready.

Practical implication: Sequence adoption around the highest-risk access paths first, then expand enforcement only when telemetry and policy maturity support it.

NHI Mgmt Group analysis

Continuous identity proofing is the control that keeps zero trust from becoming static trust with new branding. The article correctly emphasises that Zero Trust Architecture depends on repeated verification, not a one-time authentication event. That is the governance shift practitioners still under-estimate: identity proof must remain current enough to support each access decision. The practitioner conclusion is that access governance has to be measured by proof freshness, not by login success alone.

Identity proofing for zero trust is not only a human IAM problem. The article references non-person entities in the access-time context, which is the right lens for modern environments where applications and services also request resources. That means the same zero trust logic must govern human sessions and machine access paths, but with different evidence and lifecycle expectations. The practitioner conclusion is to align human, machine, and service access policy around the same continuous-verification principle.

Zero trust succeeds when authorisation is treated as a living control plane, not a deployment milestone. The article’s phased model is important because it acknowledges that policy quality, telemetry, and enforcement maturity evolve together. A static rollout can give the appearance of maturity while the actual decisioning logic drifts out of date. The practitioner conclusion is to treat ZTA as an operating model that needs continuous validation and exception review.

Resource-level enforcement is the right named concept for this shift. NIST SP 1800-35 moves the focus from network zones to individually governed resources, which is what makes least privilege enforceable in distributed environments. That concept matters because practitioners need a vocabulary for the control boundary, not just the architecture label. The practitioner conclusion is to evaluate every access path at the resource level rather than at the perimeter level.

The central governance gap is not trust in the network, but trust in stale identity assumptions. Zero trust fails when systems keep authorising based on context that no longer matches the session, the device, or the user’s current need. The article shows why ongoing validation matters more than architectural declarations. The practitioner conclusion is to continuously test whether the policy engine is still using live identity context rather than inherited assumptions.

What this signals

Continuous proofing changes the unit of governance from session start to session duration. Once that shift is made, teams have to decide whether their current policy engine can still make trustworthy decisions after device posture, role, or resource sensitivity changes. The practical signal is simple: if your control only works at authentication time, it is not yet a zero trust control.

Zero trust programmes should be judged by how quickly policy can adapt to context drift. The article reinforces that phased rollout is not a weakness. It is a recognition that enforcement quality depends on telemetry, policy design, and operational validation improving together. Teams should expect the most difficulty where legacy applications cannot provide stable context or where exception handling becomes the default.

Resource-level access governance becomes the critical design boundary for hybrid environments. The more an organisation relies on distributed applications, cloud services, and machine access, the less useful broad zone-based trust becomes. Teams should align policy reviews, access recertification, and exception management around the resource itself rather than around the perimeter narrative.

For practitioners

• Implement per-request identity verification Require each access decision to evaluate the current subject, resource, and context rather than relying on the last successful login event.
• Map access paths to resource-level policy Break broad trust zones into individually governed resources so the authorisation logic can enforce least privilege at the point of access.
• Refresh context signals during sessions Feed device posture, location, and anomaly data back into policy so long-lived sessions can be re-evaluated when conditions change.
• Phase ZTA by highest-risk workloads first Start with the access paths that expose the most sensitive resources, then expand coverage as telemetry, policy design, and enforcement maturity improve.

Key takeaways

• Zero trust is still an identity governance problem as much as a network design problem, because access decisions only stay valid when identity proof remains current.
• NIST SP 1800-35 supports phased implementation, but the real test is whether policy, telemetry, and enforcement can keep pace with context drift.
• Teams that validate zero trust only at deployment time risk preserving the appearance of least privilege while allowing access decisions to go stale.

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.
• 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.
• Repository-level enforcement: A control model that applies policy at the source repository or pull request boundary rather than relying on individual developer devices. It improves consistency because the gate sits where code changes are validated before merge, which is closer to the point of production impact.
• Context-Aware Access Review: A decision process that evaluates access requests using request intent, existing entitlements, resource sensitivity, and operational evidence. In identity programmes, it reduces blind approvals by forcing reviewers or automation to weigh the real circumstances behind the request, not just the ticket itself.

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.