Because attackers operate at runtime, not on review cycles. Periodic reviews can confirm that access was once acceptable, but they do not stop a compromised session or abused service account in the moment. Runtime controls matter when the decision to restrict access must happen before the attacker pivots.
Why This Matters for Security Teams
Periodic access reviews are useful for compliance, but they are a weak control for runtime risk. A service account can be approved on paper and still be abused in the next minute through stolen tokens, overbroad scopes, or a compromised workload. That gap is why runtime identity controls matter: they decide whether a session, token, or tool call should be allowed right now, not whether it looked acceptable last quarter.
NHI Management Group’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and only 5.7% of organisations have full visibility into their service accounts. That combination makes periodic review too slow for modern attack paths. Current guidance from the OWASP Non-Human Identity Top 10 points to runtime misuse, credential sprawl, and weak lifecycle control as recurring failure points.
In practice, many security teams discover the problem only after a token has already been reused for lateral movement, rather than through an intentional access review.
How It Works in Practice
Runtime identity control shifts the decision point from governance meetings to the moment of use. Instead of asking whether an identity should generally have access, the control checks whether this specific request, from this workload, in this context, should proceed. That means evaluating identity, workload posture, request purpose, network location, resource sensitivity, and token freshness together.
For NHI and agentic workloads, that often requires short-lived credentials, workload identity, and policy evaluated at request time. A workload can prove what it is through cryptographic identity, such as SPIFFE/SPIRE or OIDC-based workload assertions, then receive just-in-time access for the task at hand. That approach aligns with NHI lifecycle and Zero Trust principles described in the NHI Lifecycle Management Guide and the broader research in Top 10 NHI Issues.
- Issue ephemeral credentials with a narrow TTL tied to the task, not the account.
- Evaluate policy in real time using policy-as-code, such as OPA or Cedar, rather than relying only on quarterly recertification.
- Bind access to the workload, not just the secret, so a stolen token is less useful outside its context.
- Revoke or expire access automatically when the task completes, the posture changes, or risk signals increase.
This is especially important when service accounts are shared, when secrets are embedded in CI/CD, or when third-party automations access production systems without clear ownership. These controls tend to break down when long-lived credentials are reused across many systems because revocation and attribution become too slow to stop active abuse.
Common Variations and Edge Cases
Tighter runtime controls often increase operational overhead, requiring organisations to balance security gains against deployment complexity and latency. That tradeoff is real, especially where legacy applications cannot refresh tokens cleanly or where batch jobs need long-running access.
Best practice is evolving, but current guidance suggests treating periodic reviews as a backstop, not a primary safeguard. Reviews still matter for entitlement hygiene, while runtime controls handle the moment when risk becomes active. In high-churn environments, such as CI/CD pipelines, data integrations, and agentic AI systems, static approvals age quickly and can give false confidence.
There is also no universal standard for how aggressively runtime checks should interrupt workflows. Some teams block high-risk calls outright; others step up verification, constrain scopes, or require re-issuance of a just-in-time credential. The right choice depends on tolerance for friction, blast radius, and the sensitivity of the target system. For deeper breach patterns that show how quickly abuse moves after exposure, see 52 NHI Breaches Analysis and the Ultimate Guide to NHIs — Key Challenges and Risks.
Periodic review answers whether access once made sense. Runtime control answers whether it is safe this second, which is why it becomes the decisive layer when attackers are already inside.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses credential lifecycle and rotation gaps that periodic reviews miss. |
| NIST CSF 2.0 | PR.AC-4 | Supports continuous access enforcement for identities and workloads. |
| NIST AI RMF | GOVERN | Runtime decisions need clear accountability and governance for automated identity actions. |
Replace long-lived NHI secrets with short-lived, auto-rotated credentials and verify revocation actually works.
