Zero trust access patterns for identity-driven authorization in NIST

At a glance

What this is: This is an analysis of five Zero Trust implementation patterns from NIST SP 1800-35, focused on identity-driven authorization, per-request policy, auditing, and short-lived access.

Why it matters: It matters because IAM, NHI, and security teams are being pushed toward continuous verification models that affect humans, service identities, and emerging agentic access patterns.

👉 Read Pomerium's analysis of five Zero Trust patterns from NIST SP 1800-35

Context

Zero Trust fails when access is treated as a one-time event instead of a continuously verified decision. For identity and access programmes, the practical issue is not whether policy exists, but whether it is evaluated against identity, device posture, and request context at the moment access is used.

Pomerium’s summary of NIST SP 1800-35 is useful because it turns Zero Trust guidance into implementation patterns rather than abstract principles. That makes it directly relevant to IAM teams, NHI governance leads, and architects trying to move from static permissions toward per-request authorisation and short-lived access.

Key questions

Q: How should security teams implement zero trust access for sensitive applications?

A: Start by binding access to identity, device posture, and policy rather than network location. Then enforce request-time authorisation, short session lifetimes, and full audit logging so access remains continuously verifiable. The goal is to make each request independently trustworthy instead of relying on a trusted session established earlier.

Q: Why do static access controls fall short in zero trust environments?

A: Static controls assume the risk state stays stable after access is granted, but Zero Trust assumes the opposite. Endpoint health, location, and user context can change during a session, so access decisions need to be re-evaluated continuously. Without that, stale permissions survive longer than the trust condition that justified them.

Q: How do short-lived credentials reduce access risk in practice?

A: Short-lived credentials reduce the window in which stolen, shared, or overused access can be abused. They work best when paired with re-authentication, centralized logging, and tight policy checks so the organisation can limit exposure without losing traceability. Expiry alone is not enough if renewal is too permissive.

Q: Who is accountable for access decisions under zero trust governance?

A: Accountability sits with the organisation that defines policy, operates the gateway, and owns the logging and review process. In practice, IAM, security architecture, and audit teams need shared ownership of the control model so access decisions are explainable, repeatable, and reviewable across human and non-human identity use cases.

Technical breakdown

Identity-driven access control in zero trust

Identity-driven access control means the policy decision starts with who or what is requesting access, then layers in trust signals such as device state and policy compliance. In Zero Trust, identity is not just an authentication event. It becomes the anchor for repeated authorisation checks, whether the subject is a human user, a workload, or another non-human identity. This is what separates modern access control from coarse network-based trust. Once identity is the control plane, privilege is granted only within the current context and can be revoked or narrowed as conditions change.

Practical implication: move high-risk resources off network-only controls and onto identity-bound policy decisions.

Contextual per-request authorization

Per-request authorisation evaluates each access attempt dynamically instead of assuming a session remains trustworthy after login. The policy engine can consider endpoint health, location, behaviour, and other signals at the time of the request, which is how Zero Trust avoids stale decisions. This is especially important in environments where credentials are reusable, sessions persist, or access paths cross multiple systems. Static ACLs cannot see changing risk; request-time evaluation can. The key architectural shift is that authorisation becomes an ongoing control loop rather than a gate at the front door.

Practical implication: replace broad, persistent permissions with request-time policy checks tied to current context.

Ephemeral credentials and audit-ready access

Short-lived credentials reduce the time window in which stolen or overused access can be abused, while detailed logging preserves evidence of every authorisation decision. In Zero Trust architectures, these two controls work together: short sessions limit exposure, and continuous logs make the decision trail reviewable for operations, compliance, and incident response. This is particularly valuable where service identities or application-level gateways mediate access, because the access path itself becomes part of the record. The architecture is not just about blocking access. It is about making access accountable and bounded.

Practical implication: enforce short session lifetimes and retain centralized logs for every access decision.

NHI Mgmt Group analysis

Zero Trust succeeds only when identity becomes the control plane for every access decision. The article correctly centers identity-driven access because network location alone cannot express modern privilege boundaries. Once identity, device state, and policy compliance are evaluated together at request time, the organisation gets a control model that can govern humans and non-human identities with the same discipline. The practitioner lesson is to stop treating network reachability as a proxy for trust.

Static access policies are the wrong model for environments that change faster than review cycles. Per-request authorisation is not an enhancement to legacy IAM, it is the mechanism that prevents stale permissions from surviving into the next risk state. That matters across human IAM, workload identity, and emerging agentic access patterns where context can shift mid-session. The practitioner implication is to redesign entitlement enforcement around current context, not issued access alone.

Short-lived access is a Zero Trust requirement, but it also exposes governance assumptions in IAM programmes. Traditional review processes assume access remains stable long enough to be observed, audited, and certified. When credentials are ephemeral, the control value moves from periodic review to continuous enforcement, and that changes how organisations should measure privilege exposure. The practitioner implication is to align session design, logging, and revocation logic before expanding access scope.

Identity-aware gateways are becoming the practical layer where Zero Trust is actually enforced. The article’s emphasis on direct application access, auditing, and dynamic policy shows that the architectural centre of gravity is moving away from VPN-style perimeter controls. For practitioners, that means the implementation conversation is less about replacing one tunnel with another and more about binding each request to policy, identity, and evidence. The practitioner implication is to treat the gateway as a governance point, not just a connectivity layer.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most identity programmes still lack reliable coverage of non-human access paths.
• For the standards angle, see Ultimate Guide to NHIs - Standards for how Zero Trust and NHI guidance fit together.

What this signals

Identity-driven access control will increasingly become the default governance layer for both human and non-human access. As organisations reduce dependence on network trust, the practical challenge shifts to policy quality, context signals, and enforcement consistency. Teams that already map access to application-level policy will adapt faster than teams still anchored to perimeter logic.

With 97% of NHIs carrying excessive privileges, per the Ultimate Guide to NHIs, Zero Trust programmes need to treat privilege scope as a live control problem rather than a provisioning task. That is especially true when credentials are short-lived but still overbroad during their usable window.

The next maturity step is to connect access policy, audit evidence, and lifecycle governance so that humans, workloads, and agents are governed with the same decision model. That makes least privilege measurable instead of aspirational.

For practitioners

• Implement identity-bound policy for sensitive applications Require identity, device posture, and policy compliance to be evaluated before access is granted to high-value systems. Replace broad network trust with application-level decisions that can be inspected and revoked.
• Move from static ACLs to request-time authorization Use dynamic policy evaluation for every request so permissions reflect current context instead of stale approval states. This is especially important where session reuse or shared access paths create hidden exposure.
• Shorten credential lifetime across privileged access paths Use ephemeral credentials and strict session durations for access to critical applications and infrastructure. Pair expiry with re-authentication so stolen or overused access has less time to be abused.
• Centralize access logs for audit and response Record each authorisation decision in a consistent log stream so security, audit, and incident teams can reconstruct who accessed what, when, and under which policy conditions.
• Reassess VPN dependency for application access Limit traditional VPN use to cases where network tunnelling is truly required, and shift routine access to policy-enforced application entry points that expose less of the environment.

Key takeaways

• Zero Trust is not a perimeter replacement exercise, it is an access governance model that depends on identity and context at request time.
• Short-lived access and continuous logging reduce exposure, but only if policy enforcement is tied to the current trust state rather than a stale session.
• IAM and NHI teams should treat identity-aware gateways as governance enforcement points and redesign controls around per-request decisions.

Key terms

• Zero Trust Architecture: A security model that assumes no request is trusted by default, even inside the network. Access is granted only after identity, context, and policy checks succeed, and those checks continue throughout the session rather than stopping at login.
• Per-request authorization: An access control approach that evaluates each request at the moment it is made instead of relying on a prior session decision. It is central to Zero Trust because it lets policy respond to changing risk, device posture, and identity context.
• Ephemeral credentials: Credentials that expire quickly and are intended for short, task-scoped use. They reduce the time window available for abuse, but they only improve security when paired with strong policy enforcement, re-authentication, and reliable logging.
• Identity-aware gateway: A control point that brokers access based on identity and policy instead of allowing broad network reachability. It turns access into a governed decision and creates a place to enforce verification, auditing, and application-level restrictions.

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

This post draws on content published by Pomerium: 5 actionable zero trust patterns from NIST SP 1800-35 and how to implement them. Read the original.