Notifications
Clear all
Topic starter
12/06/2026 9:10 pm
TL;DR: NIST SP 1800-35 translates Zero Trust Architecture into a practical implementation guide, stressing continuous verification, context-aware policy, phased adoption, and ongoing policy validation rather than perimeter trust, according to Pomerium. The deeper lesson is that ZTA only works when identity, context, and access governance stay in sync as the environment changes.
NHIMG editorial — based on content published by Pomerium: 5 Key Takeaways about ZTA from NIST SP 1800-35
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.
Questions worth separating out
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.
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.
Q: What breaks when access policies are not continuously revalidated in a Zero Trust model?
A: Static policies quickly drift away from reality.
Practitioner guidance
- Bind policy to runtime context Require access decisions to re-evaluate identity, device, and resource context during the session, not just at login.
- 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.
- 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.
What's in the full article
Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:
- The article breaks down NIST SP 1800-35’s four implementation approaches, including Enhanced Identity Governance, SDP, microsegmentation, and SASE.
- It summarises the four-year NCCoE collaboration and the 19 example implementations behind the guidance.
- It explains how Pomerium positions identity-aware, context-based authorization in relation to Zero Trust deployment.
- It links the guidance to practical next steps for teams trying to implement Zero Trust without reworking every system at once.
👉 Read Pomerium's analysis of NIST SP 1800-35 and Zero Trust implementation →
Zero trust identity enforcement: what practitioners still miss?
Explore further
12/06/2026 11:03 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Zero trust access still depends on continuous identity proofing
