By NHI Mgmt Group Editorial TeamPublished 2026-01-22Domain: Best PracticesSource: SGNL

TL;DR: Continuous identity shifts IAM from static onboarding and periodic review toward runtime decisions informed by context, downstream activity, and changing risk, according to Simon Moffatt's guest analysis. The governance challenge is no longer just who has access, but when and under what conditions that access should change.


At a glance

What this is: This guest analysis argues that continuous identity extends IAM beyond static provisioning into runtime, context-aware access decisions across humans and non-humans.

Why it matters: It matters because NHI and agentic AI governance depends on reacting to changing risk after authentication, not only at onboarding or review time.

👉 Read Simon Moffatt's guest analysis on continuous identity and runtime access decisions


Context

Continuous identity is a runtime approach to IAM that updates access decisions as context changes, rather than treating authentication or access review as a one-time event. In a modern enterprise, that matters because humans, service accounts, API keys, workloads, and AI agents all create identity events that can drift after initial approval.

The central governance gap is familiar to IAM teams: existing models often lack enough context to decide whether access should be reduced, preserved, or revoked after the original request has already been approved. For NHI governance, this is the same structural problem seen in service account sprawl, stale permissions, and delayed offboarding, where the control plane knows the identity exists but not whether its current state still matches the risk.

This article is about that gap, not about any single product. Its starting position is typical for enterprises that have invested in identity governance but still rely on periodic checks, copied entitlements, and delayed remediation when conditions change.


Key questions

Q: How should security teams implement continuous identity for non-human identities?

A: Start by treating runtime signals as policy inputs for NHIs, not just humans. Define which events can shorten token life, reduce privileges, or terminate a workload session, then connect those decisions to inventory, ownership, and logging so the response is fast enough to matter.

Q: When does just-in-time access create more risk than it reduces?

A: Just-in-time access creates more risk when teams issue temporary privileges but cannot detect when the session changes state, the token is reused, or the identity behaves outside scope. In that case the access is short-lived on paper but still too permissive in practice.

Q: What is the difference between zero standing privilege and continuous identity?

A: Zero standing privilege removes persistent access, while continuous identity decides whether access should continue as conditions change. ZSP changes the default entitlement model. Continuous identity adds runtime judgment, which is necessary when workloads, secrets, and agents can drift after access begins.

Q: Why do NHIs complicate zero trust architecture assumptions?

A: NHIs complicate zero trust because they often authenticate automatically, operate at machine speed, and reuse credentials across systems. That makes static trust assumptions fragile. Zero trust only holds if the organisation can continuously verify both the identity state and the context in which it is acting.


Technical breakdown

How continuous identity uses runtime context

Continuous identity extends the identity decision beyond login or request time by using signals such as device health, threat intelligence, downstream activity, and business context. The point is not to replace IAM policy with telemetry, but to feed policy with fresher evidence so the system can adjust trust dynamically. For NHIs, the same logic applies to service account activity, workload behavior, and token usage, because static entitlements tell you very little about whether the identity is still acting within scope. This creates a control model that is responsive rather than calendar-driven.

Practical implication: Practitioners should treat context sources as control inputs and define which signals can trigger step-down, re-authentication, or revocation.

Why post-authentication enforcement matters for NHI and AI agents

Traditional IAM tends to concentrate on the point of authentication, but many identity risks emerge after access has been granted. Continuous identity moves enforcement into the session and execution phase, which is where compromised credentials, overbroad permissions, or agent misbehavior become operationally dangerous. For non-human identities, this matters even more because tokens and certificates can keep working long after the original trust decision was made. If the runtime state changes, the control must be able to change with it, otherwise least privilege remains theoretical.

Practical implication: Teams should add session controls, runtime checks, and revocation paths that can act on NHIs after authentication, not just before it.

How ZSP and JIT fit into continuous identity

Zero Standing Privilege and Just-in-Time access are complementary to continuous identity because both reduce the duration and breadth of standing access. JIT narrows the window in which an identity can be abused, while ZSP removes persistent entitlement assumptions altogether. Continuous identity adds the missing runtime layer by deciding whether access should continue as conditions shift. In NHI environments, that combination is especially relevant for cloud workloads, automation accounts, and AI agents that need task-scoped access but should not retain it by default.

Practical implication: Use JIT and ZSP as baseline controls, then add runtime risk evaluation so temporary access can still be shortened or withdrawn when conditions change.


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 best understood as a runtime governance model, not a richer login flow. The article correctly shifts attention away from static approval and toward the moment when identity state changes. That distinction matters for NHI governance because service accounts, tokens, and agents do not fail safely just because they were approved correctly once. Practitioners should design for continuous decisioning, not just continuous monitoring.

Ephemeral access does not solve trust debt if the runtime model stays static. JIT and temporary credentials reduce exposure, but they still rely on the assumption that the identity remains within scope for the full session. In NHI environments, that assumption breaks quickly when downstream systems, workloads, or agents change behavior. Teams should pair short-lived access with controls that can still react after issuance.

Identity governance platforms need better external signals to avoid blind remediation. The article highlights a core failure mode in IAM: reviews and revocation often happen without enough operational context to make good decisions. For NHIs, that problem is amplified because inventories are incomplete and usage is often machine-driven. The practical answer is to bind lifecycle controls to runtime evidence, not to rely on periodic certification alone.

Identity blast radius is the real design variable in continuous identity. If a control cannot change privilege or session state fast enough, the identity can continue moving even after risk is detected. That is why continuous identity should be judged by how quickly it can shrink blast radius across humans and NHIs. Practitioners should measure response latency, not just policy coverage.

Continuous identity will pressure IAM teams to unify governance and enforcement. The old split between identity governance, access control, and session response is increasingly artificial when risk changes mid-session. That is especially true for AI agents and workloads, which may need to be paused, stepped down, or terminated based on contextual signals. Teams should plan for tighter integration across request, review, and runtime enforcement.

From our research:

  • 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
  • From our research: Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
  • From our research: Use the NHI Lifecycle Management Guide to pair runtime control with lifecycle actions that actually reduce standing exposure.

What this signals

Identity blast radius: continuous identity will become a governance requirement wherever NHIs can act autonomously across multiple systems. If the runtime layer cannot narrow privilege quickly, the enterprise inherits the same standing-access problem under a different name, which is why lifecycle discipline must extend into enforcement.

With 91.6% of secrets still valid five days after notification, according to Ultimate Guide to NHIs, delayed response is already a structural weakness. Continuous identity should therefore be measured by how quickly it can reduce access after risk changes, not by how neatly it documents approvals.

Practitioners should expect continuous identity to push IAM closer to Zero Trust Architecture and closer to operational control loops. The organisations that prepare now will be the ones that can link review, revocation, and runtime decisions without waiting for the next certification cycle.


For practitioners

  • Map runtime signals to access decisions Define which signals can downgrade a session, require re-authentication, or revoke access for both humans and NHIs. Start with device health, token age, workload behavior, and downstream anomaly signals, then document the exact action each signal can trigger.
  • Apply ZSP and JIT to non-human identities Reduce standing access for service accounts, automation tokens, and AI agents by issuing task-scoped access only when needed. Build the revocation path first so temporary access can actually be removed when the work completes or risk changes.
  • Connect identity review to usage evidence Stop treating access review as a paperwork exercise. Use downstream logs, application activity, and ownership data to decide whether an entitlement is still justified, then remove anything that cannot be explained in current business terms.
  • Establish a response ladder for changing risk Predefine what happens when risk rises during a live session, including step-down, forced logout, token invalidation, and helpdesk recovery. That response ladder should be different for high-risk NHIs than for low-risk user sessions.

Key takeaways

  • Continuous identity moves IAM from static approval to runtime governance, which is essential when access conditions change after authentication.
  • NHIs make the problem sharper because tokens, service accounts, and agents can remain active long after the original trust decision.
  • Security teams should pair JIT, ZSP, and contextual enforcement so access can be reduced in real time when risk increases.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Continuous identity depends on controlling stale and overly broad NHI access.
NIST CSF 2.0PR.AC-4Runtime access decisions align with least-privilege and dynamic access control.
NIST Zero Trust (SP 800-207)AC-3Zero trust requires continual verification of identity and context, not one-time trust.

Apply continuous verification so high-risk NHIs can be stepped down or terminated in real time.


Key terms

  • Continuous Identity: A runtime identity model that updates access decisions as context changes after authentication. It treats identity as a living state, not a fixed record. For NHIs, this means service accounts, tokens, and agents can be stepped down or revoked when behavior or risk changes.
  • Identity Blast Radius: The amount of damage an identity can cause before controls interrupt it. In practice, blast radius is shaped by privilege scope, token lifetime, session duration, and enforcement speed. For NHI governance, smaller blast radius means faster containment when automation or agents misbehave.
  • Zero Standing Privilege: An access model in which no identity keeps persistent elevated permissions by default. Access is granted only when needed and for a limited purpose. In NHI environments, ZSP reduces the exposure created by dormant service accounts, long-lived tokens, and reusable secrets.
  • Just-in-Time Access: A provisioning pattern that grants permissions only for the duration of a task or session. It reduces standing exposure, but it still depends on strong revocation and monitoring. For non-human identities, JIT is most effective when paired with runtime signals and strict scope control.

Deepen your knowledge

Continuous identity and runtime access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a programme that has to account for post-authentication risk, it is worth exploring.

This post draws on a guest analysis by Simon Moffatt, founder of The Cyber Hut, on continuous identity and runtime IAM. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-01-22.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org