NIST zero trust gaps show why continuous identity controls matter

At a glance

What this is: This analysis argues that NIST SP 1800-35 validates Zero Trust in practice while exposing the limits of periodic verification, JIT provisioning, and fragmented policy data.

Why it matters: It matters because IAM and NHI teams cannot treat scheduled checks as sufficient when autonomous workloads and non-human identities need continuous, session-level control.

By the numbers:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read SGNL's analysis of NIST SP 1800-35 and continuous identity control

Context

Zero Trust is supposed to reduce implicit trust, but in practice many deployments still rely on scheduled rechecks, temporary entitlements, and fragmented policy inputs. That leaves a gap between the architecture teams want and the enforcement model they can actually operate for NHI governance, especially when service accounts, API keys, and AI agents move faster than human review cycles.

NIST SP 1800-35 is useful because it shows Zero Trust can be demonstrated, not just theorised. The problem is that demonstration is not the same as continuous control. For practitioners, the open question is whether JIT access and periodic polling are enough when access decisions must track device state, business context, and session risk in real time. The closest governance baseline is still the Ultimate Guide to NHIs, but the operational model clearly needs to move beyond static identity checks.

Key questions

Q: How should organisations apply Zero Trust to non-human identities?

A: Start by treating each non-human identity as a controllable access path, not a background system object. Apply least privilege, session scoping, ownership, and continuous revocation to service accounts, API keys, certificates, and automation agents. The goal is to reduce the blast radius of any one identity and ensure access changes when risk changes.

Q: What is the difference between just-in-time access and zero standing privilege?

A: Just-in-time access gives privilege for a limited period, but the privilege still exists for that window. Zero standing privilege aims to avoid reusable access altogether by binding authorisation to the live task or session. For NHI governance, that difference matters because temporary access can still be abused before it expires.

Q: Why do periodic checks fall short for NHI governance?

A: Periodic checks create a delay between a risk change and the enforcement response. That delay is tolerable for slow administrative workflows but dangerous for workload identities, API tokens, and agent sessions that can be abused in minutes. Continuous evaluation closes the gap by reacting to state changes as they occur.

Q: What is the difference between policy coherence and policy fragmentation?

A: Policy coherence means the enterprise can make one access decision from multiple signals, such as device posture, user context, and workload state. Policy fragmentation means those signals sit in separate tools that do not act on the same picture. Coherence is essential when identities are autonomous and access decisions must be explainable.

Technical breakdown

Why JIT provisioning is not the same as zero standing privilege

Just-in-time provisioning creates access for a limited period, but it still creates standing privilege for that window. Zero standing privilege is narrower: access should exist only as long as the session, task, or decision requires it, and it should expire without relying on human cleanup. That distinction matters because privileged non-human identities are often exploited in the gap between issuance and revocation. In NHI environments, the control question is not whether a role was temporary, but whether a credential ever became broadly reusable. Practical implementations need session-bound authorisation, not just delayed deprovisioning.

Practical implication: Treat JIT as a provisioning pattern, not a security end state, and design controls that remove reusable privilege from the start.

How continuous identity decisions differ from periodic polling

Periodic polling asks systems to check posture at intervals, which creates latency and blind spots between checks. Continuous identity decisions use event-driven signals, such as device compromise, session risk, or policy changes, to re-evaluate access as conditions change. That shift is important for Zero Trust because trust is not a one-time act. For NHI and agentic workloads, the same principle applies to tokens, workload sessions, and service credentials that can be abused faster than an hourly review cycle can respond. Event-driven enforcement is the architectural difference between reactive access management and real control.

Practical implication: Replace scheduled verification with event-driven revocation paths wherever a changed signal should immediately affect access.

Why fragmented policy data weakens zero trust enforcement

Zero Trust architectures often fail at the handoff between policy decision points because the relevant signals sit in different systems that do not share a common identity picture. One tool may know the device is non-compliant while another still sees the session as valid. That fragmentation makes access decisions inconsistent and hard to audit, especially for NHI governance where workload context, ownership, and runtime state all matter. The technical issue is not only policy logic, but policy coherence across identity, security, and business systems. Without that coherence, least privilege becomes a local rule rather than an enterprise control.

Practical implication: Build a shared identity and context layer before expecting consistent enforcement across IdP, EDR, and cloud controls.

Threat narrative

Attacker objective: The attacker aims to turn a temporary trust decision into durable access that outlives the original business task.

1. Entry occurs when attackers abuse exposed or over-privileged non-human identities that were issued for convenience rather than tightly scoped use.
2. Escalation follows when standing or reusable access survives long enough for the attacker to pivot, query more systems, or impersonate trusted automation.
3. Impact is achieved when the attacker uses that access to move through identity and cloud controls faster than periodic reviews can revoke it.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Continuous identity is the real next step in Zero Trust. The article’s core point is that proving ZTA is possible does not make it complete. Scheduled checks and temporary roles still leave a governance gap for identities that execute faster than human oversight. Practitioners should treat continuous identity evaluation as the control objective, not as an optional enhancement.

Zero standing privilege is a control model, not a provisioning trick. The distinction between JIT provisioning and true ephemeral access matters because many programmes stop at time-limited entitlements. That still leaves reusable privilege alive during the window of exposure. Security teams should design for session-bound authorisation and immediate revocation, especially for high-risk NHI paths.

Policy fragmentation is now an identity risk, not just an integration nuisance. When policy decision points do not share context, the enterprise cannot reliably explain why access was granted or removed. That undermines both enforcement and auditability. Practitioners should re-evaluate whether their Zero Trust stack can make one coherent decision from multiple security signals.

Identity blast radius is the most useful way to judge maturity here. The question is not whether the architecture has controls, but how much damage a compromised credential can still do before those controls react. NHI governance should therefore focus on shortening exposure windows, limiting session scope, and reducing the number of systems any one identity can reach.

Operational maturity will hinge on event-driven enforcement, not more frequent review meetings. The market keeps describing Zero Trust as a policy problem, but the harder problem is response latency. Teams that cannot act on live risk signals will continue to rely on controls that are correct in theory and late in practice.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably inventory the identities that Zero Trust is supposed to govern.
• For a broader control baseline, Ultimate Guide to NHIs , Standards maps NHI governance to Zero Trust, OWASP NHI, and related frameworks.

What this signals

Continuous identity will become the practical benchmark for Zero Trust maturity. Teams that still rely on periodic polling will keep finding enforcement lag between risk detection and access removal. With 97% of NHIs carrying excessive privileges, according to Ultimate Guide to NHIs, the governance problem is no longer whether to tighten access, but how quickly the control plane can react.

Identity blast radius is the more useful programme metric than policy count. A stack can have many rules and still fail if one compromised service account can reach too many systems. Practitioners should measure how far a single credential can travel across cloud, CI/CD, and business workflows, then use that number to prioritise remediation.

Zero Trust and NHI governance are converging around the same operational question. Can your control plane see, decide, and revoke fast enough to outpace misuse? The answer increasingly depends on event-driven enforcement, shared context, and standards such as NIST SP 800-207 Zero Trust Architecture rather than on slower review cycles.

For practitioners

• Map every NHI to a session owner Assign explicit ownership for service accounts, API keys, certificates, and automation identities so that each one has a human accountable for approval, review, and revocation.
• Separate JIT provisioning from ephemeral access Use JIT only when you must create an identity object, but prefer session-bound authorisation for privileged tasks so access can expire without leaving reusable standing privilege.
• Unify policy inputs before tightening enforcement Correlate IdP, endpoint, cloud, and business context so access decisions can react to one coherent state rather than conflicting signals from multiple policy decision points.
• Instrument immediate revocation paths Trigger access removal on device non-compliance, incident escalation, token misuse, or ownership changes, and verify that revocation reaches the enforcement point without polling delays.
• Review NHI blast radius quarterly Measure how far a single non-human identity can move across cloud, CI/CD, and data systems, then reduce that reach by tightening scopes, expirations, and approvals.

Key takeaways

• Zero Trust demonstrations are useful, but they do not eliminate the governance gap created by periodic checks and temporary privilege.
• NHI risk persists because secrets and service accounts remain visible, reusable, and over-privileged long after teams think they have addressed them.
• Practitioners should move from time-bound access reviews to continuous, event-driven identity control with measurable blast-radius reduction.

Key terms

• Zero Standing Privilege: Zero Standing Privilege is an access model where no identity keeps reusable elevated access by default. Privilege is created only when needed and should disappear when the task ends, reducing the time window in which service accounts, API keys, or agent sessions can be abused.
• Just-in-Time Access: Just-in-Time Access is a provisioning pattern that grants privilege for a limited purpose and duration. It can reduce exposure, but it still creates standing access for the life of the entitlement, so it is not the same as true ephemeral authorisation for NHI governance.
• Continuous Access Evaluation: Continuous Access Evaluation is the practice of rechecking access decisions as risk signals change, rather than waiting for a scheduled review. For non-human identities, it is the mechanism that helps revoke workload or agent access quickly when device, policy, or session conditions change.
• Identity Blast Radius: Identity blast radius is the amount of damage one credential or identity can cause before containment occurs. In NHI environments, it is shaped by privilege scope, session duration, token reuse, and the number of systems an automation identity can reach without reauthorization.

Deepen your knowledge

Zero Trust identity governance and ephemeral access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for service accounts, API keys, and agent sessions from a similar starting point, it is worth exploring.

This post draws on content published by SGNL: Exceed NIST 1800-35’s Zero Trust demonstrations with continuous, context-aware identity. Read the original.