Notifications
Clear all
Topic starter
12/06/2026 9:10 pm
TL;DR: NIST SP 1800-35 translates Zero Trust into five practical patterns for identity-driven access control, contextual per-request authorization, remote access without traditional VPNs, end-to-end auditing, and short-lived credentials, according to Pomerium. The real shift is that access decisions must be continuous, context-aware, and tightly bound to identity, not session assumptions.
NHIMG editorial — based on content published by Pomerium: 5 actionable zero trust patterns from NIST SP 1800-35 and how to implement them
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Shorten credential lifetime across privileged access paths Use ephemeral credentials and strict session durations for access to critical applications and infrastructure.
What's in the full article
Pomerium's full blog post covers the implementation detail this analysis intentionally leaves for the source:
- The article shows how NIST SP 1800-35 patterns map to Pomerium's routing and authorization model for practitioners who need implementation detail.
- It explains how identity, context, and policy are combined on each request rather than describing the broader Zero Trust principle alone.
- It outlines how certificate-based ephemeral access and audit logging are applied in the product's access flow.
- It also points to related use cases such as SSH access and application-level gateway patterns that this post does not unpack.
👉 Read Pomerium's analysis of five Zero Trust patterns from NIST SP 1800-35 →
Zero trust access patterns for identity-driven authorization?
Explore further
12/06/2026 11:03 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Zero trust access patterns for identity-driven authorization in NIST
