How should security teams replace calendar-based access recertification?

Why This Matters for Security Teams

Calendar-based recertification creates a predictable gap between actual risk and review activity. In fast-moving environments, access can drift long before the next quarterly or annual campaign, especially when people change roles, privileges expand, or identities go dormant. That is why current guidance is shifting toward event-driven attestation, where the trigger is a material identity change rather than the passage of time.

This matters because access reviews are only useful if they reflect current reality. For non-human identities, that reality changes even faster: keys rotate badly, service accounts accumulate privileges, and secret sprawl persists in code and pipelines. NHI Management Group notes that 71% of NHIs are not rotated within recommended time frames in the Ultimate Guide to NHIs, which shows how easily stale access becomes normalised. The same logic applies to human access where a role change or MFA reset can invalidate a previous certification almost immediately. In practice, many security teams discover access drift only after an audit exception or incident has already exposed it.

How It Works in Practice

The practical replacement for calendar-only review is a hybrid model: keep periodic certification for baseline governance, but add event-driven recertification for changes that materially alter risk. The review should fire when an identity is terminated, transferred, promoted, granted elevated access, loses MFA, has a dormant period, or receives new entitlements through a privileged workflow. That approach aligns better with the control intent described in NIST SP 800-53 Rev 5 Security and Privacy Controls, where access control and account management are continuous responsibilities, not one-time events.

Operationally, teams should define identity events as policy inputs, route them into IAM or GRC workflows, and require a reviewer decision within a short SLA. The review should ask whether the current access remains justified for the new context, not whether the access was once approved. For NHI-heavy environments, the trigger set should also include secret issuance, token scope expansion, failed rotation, and ownership changes. The OWASP Non-Human Identity Top 10 reinforces why this matters: static entitlements and weak lifecycle controls create a long tail of exposure that periodic checks do not reliably catch.

• Use periodic recertification for baseline completeness and audit evidence.
• Use event-driven recertification for any identity or privilege change that alters exposure.
• Define review SLAs so material changes are challenged while access is still relevant.
• Pair attestation with automatic deprovisioning or step-up approval where risk is high.

Many teams also link recertification to detective signals such as unusual login location, dormant account reactivation, or privilege escalation, but current guidance suggests these should supplement, not replace, a formal approval path. These controls tend to break down when identity events are not reliably captured from all source systems because the review queue then reflects incomplete telemetry rather than actual access state.

Common Variations and Edge Cases

Tighter event-driven review often increases workflow volume, requiring organisations to balance faster risk response against reviewer fatigue. That tradeoff is real, so best practice is evolving toward tiered triggers instead of treating every change as equal. A low-risk attribute update may only require logging, while a privileged role change, token scope expansion, or dormant account reactivation should require immediate attestation.

For some environments, continuous authorization is more effective than repeated recertification. That is especially true for machine identities, service accounts, and API keys, where the better control is often automated expiry, scoped permissions, and owner-based rotation rather than a human approval cycle. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks highlights how excessive privileges and weak visibility compound quickly when access is left untouched for long periods. In those cases, review should be tied to lifecycle events such as secret issuance, ownership transfer, or failed rotation, not just account age.

There is no universal standard for attestation frequency yet, so organisations should document which events trigger review, who approves exceptions, and when access is removed automatically. The point is to shorten the time between change and decision, not to eliminate governance. In practice, teams that keep calendar reviews as the only control usually find the worst drift in the accounts that were assumed to be low risk.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• What is the difference between role-based access and API key governance for NHI security?
• How should security teams govern API keys used for generative AI access?