Organisations should prioritise runtime governance when access can be created, used, and retired within a single task or session. In that model, recertification becomes too slow to prevent misuse or excess privilege. Runtime controls matter most when the business depends on autonomous execution, dynamic tokens, or machine-led decision loops.
Why runtime governance wins when access is ephemeral
runtime governance is the right priority when the real decision point is not who once had access, but what an identity, token, or agent can do right now. If a permission can be created and consumed inside a short-lived workflow, recertification only confirms yesterday’s state. Runtime controls must therefore sit closer to execution than periodic review.
That shift is especially important where entitlement is dynamic, transient, or delegated at execution time. The control objective changes from “was this access approved at some point?” to “is this action still authorised, bounded, and observable at the moment it happens?”
Runtime governance also fits situations where access is tied to workflow context, task scope, or a temporary trust grant. In those cases, a stale certification can look clean while the actual operating state has already drifted. The practical question is whether the business process itself can create excess privilege faster than a review cycle can remove it.
Where recertification still matters, and where it does not
Recertification still has value for standing access, role membership, and slower-moving governance decisions. It helps prove ownership, expose accumulated privilege, and challenge access that should no longer exist. But it is fundamentally a retrospective control, so it works best where access persists long enough for review to be meaningful.
For access reviews and certification, the key limitation is timing: the control removes access only after a review event, not during use. That makes it a poor primary safeguard for high-churn permissions, short-lived credentials, and automations that can act before a campaign closes.
Runtime governance becomes the front-line control when the access model is ephemeral by design. That includes workflows that issue temporary tokens, delegate actions to machines or agents, or create just-in-time privilege that expires faster than the next review window. In those environments, recertification is still useful as a backstop, but not as the main control plane.
What runtime governance should actually control
Good runtime governance focuses on the decision, not just the entitlement record. It checks whether the action is within scope, whether the caller is still trusted, whether the session is still valid, and whether the execution path matches the intended task. That often means tighter enforcement on token lifetime, step-up checks, session binding, policy evaluation, and real-time revocation.
Joiner-Mover-Leaver controls address lifecycle change, but runtime governance addresses live use. The difference matters when a credential or delegated privilege is created for a task and may be overpowered, misrouted, or reused before a lifecycle process can catch up. For practitioners, the question is whether access expires by policy or by administrative effort.
That is why visibility, enforcement, and revocation need to be part of the same control loop. If the system cannot see current usage, cannot stop an out-of-scope action, or cannot withdraw authority fast enough, the review process becomes ceremonial rather than preventive.
Risk and Threat Considerations
When access is short-lived or machine-executed, the main risk is not accumulation over months, it is misuse within minutes. A token, service credential, or delegated action path can be abused before a scheduled review ever runs, especially if the control only confirms approval rather than current behaviour.
Failure mechanism: Excess privilege persists during execution because the organisation relies on periodic recertification instead of live policy enforcement, session limits, and immediate revocation. That leaves a window for misuse, lateral movement, or unintended actions even when the access record looks clean.
Impact: The result can be data exposure, unauthorised transactions, privilege escalation, or unbounded autonomous activity. In practice, the blast radius is defined by what the runtime path can do before governance catches up, not by what the last certification said.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Runtime governance depends on controlling short-lived credentials and token lifecycle. |
| AC-2 — Account Management | Ephemeral access still needs lifecycle control for creation, use, and deprovisioning. | |
| AC-6 — Least Privilege | Runtime governance enforces least privilege at the moment of action, not just at review time. | |
| Recommendation — Limit token lifetime, rotate authenticators quickly, and revoke them immediately when task scope ends. Automate account and entitlement removal when a workflow or session ends. Constrain live permissions to the minimum required for the current task. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | The question centers on why short-lived runtime control beats slow review when secrets outlive their purpose. |
| NHI-05 — Overprivileged NHI | Runtime governance is needed to prevent excessive machine or agent privilege during execution. | |
| NHI-01 — Improper Offboarding | Ephemeral access still requires immediate shutdown when the workflow or session ends. | |
| Recommendation — Reduce secret lifetime and require runtime revocation when a task completes. Apply live policy checks to keep machine and agent permissions tightly scoped. Revoke non-human access paths as soon as they are no longer needed. | ||
| CIS Controls v8 | CIS-5 — Account Management | CIS emphasises controlling account and access lifecycle, which underpins runtime restraint. |
| CIS-6 — Access Control Management | Runtime governance is fundamentally about enforcing access decisions during active use. | |
| Recommendation — Continuously manage accounts and remove access that is no longer required. Enforce live access restrictions and remove excessive permissions promptly. | ||
Practitioner Guidance
What to prioritise: Treat runtime governance as the primary control when access is ephemeral, delegated, or agent-led. Reserve recertification for slower-moving standing access, exception tracking, and accountability review.
What to verify: Confirm that the control can answer three live questions, who is acting, what they can do right now, and whether the action is still within the approved task boundary. If it cannot enforce or revoke in-session, it is not sufficient on its own.
Decision rule: If privilege can be created and consumed faster than the review cycle, prioritise runtime controls first and use recertification as supporting governance, not as the main preventative control.
Practitioner takeaway: The more dynamic the access, the less useful a retrospective review becomes as the primary safeguard; governance has to move from periodic approval to real-time restraint.
Related resources from NHI Mgmt Group
- Should organisations prioritise external exposure or internal credential governance first?
- When should organisations prioritise runtime privacy controls over governance documentation?
- Should organisations prioritise runtime attestation over faster token rotation?
- When should organisations prioritise AI identity governance over new AI deployments?