Should organisations move from periodic certification to continuous access governance?

Why This Matters for Security Teams

Periodic certification was built for a world where access changed slowly and reviews could be grouped into quarterly or annual cycles. That model is weaker now because non-human identities, service accounts, API keys, and other secrets change far more often than human roles. In NHI security, stale access is not a paperwork issue; it is a live exposure path that can persist long after the business need has ended. NHI governance guidance in the Top 10 NHI Issues and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both point to lifecycle control, not calendar timing, as the real security lever. Current practice should also align with NIST Cybersecurity Framework 2.0, which emphasizes ongoing risk management rather than one-time assurance. A useful data point reinforces the point: according to The State of Non-Human Identity Security by Astrix Security and CSA, 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks. That is exactly the kind of failure periodic certification misses when access changes between review windows. In practice, many security teams encounter harmful overexposure only after a service is cloned, a secret is copied, or an integration is retired without a follow-up review.

How It Works in Practice

Continuous access governance does not mean abandoning certification; it means moving the trigger from a fixed schedule to an event-driven model. The access decision is re-evaluated when an application changes owner, when a secret is rotated, when a workload is redeployed, when a vendor integration is added, or when a privileged token is issued. That is a better fit for NHI environments because the identity is often tied to a workload, pipeline, or tool rather than a named person. The practical goal is to reduce the window in which an entitlement exists without an active business reason. A workable pattern usually includes three layers:

• Event capture from IAM, CI/CD, PAM, cloud, and SaaS systems so entitlement changes are visible quickly.
• Policy checks that compare actual access to approved purpose, ownership, and expiry, rather than to an old role description.
• Rapid review or automatic revocation when a secret, token, or certificate no longer matches the current workload state.

This approach fits with the lifecycle and audit guidance in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives, and it is consistent with the control focus in the OWASP Non-Human Identity Top 10. For organisations using a continuous model, certification becomes a sample-based assurance layer for exceptions and high-risk access, not the only control that matters. These controls tend to break down when entitlement sources are fragmented across cloud, SaaS, and CI/CD tools because no single team sees the full access graph.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, requiring organisations to balance faster revocation against review fatigue and automation risk. That tradeoff is real, especially where engineering teams deploy frequently or where shared service identities support critical production paths. Best practice is evolving, but there is no universal standard for how much should be automated versus manually approved. Some environments still justify periodic certification as the primary control for low-risk, low-change access, particularly where systems are stable and identity churn is minimal. Even there, the review scope should be narrow enough to avoid blanket recertification of unchanged access. For higher-risk systems, continuous governance should be paired with short-lived credentials, intent-based approval, and stronger lifecycle controls. That means using the current business purpose as the decision point, not the fact that an entitlement once passed review. Organisations should also distinguish between human access reviews and NHI governance. A person can explain why access exists; a workload often cannot. That is why continuous assurance matters more for NHIs than for ordinary user accounts. The 52 NHI Breaches Analysis and the Sisense breach are reminders that exposed machine identities often become incident paths long before the next certification cycle arrives.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• Should organisations prioritise external exposure or internal credential governance first?
• When should organisations move from static login controls to continuous access decisions?
• What is the difference between periodic access reviews and continuous identity governance?