What breaks when identity governance is still run on a calendar instead of on risk signals?

When governance runs on a calendar, risky access can persist for months before anyone notices. Orphaned accounts stay active, excessive privileges accumulate, and accountability becomes harder to prove during audits or incidents. The practical failure is simple: the programme appears compliant on paper while real access risk keeps growing in the background.

Why This Matters for Security Teams

Calendar-based governance assumes identity risk is mostly about elapsed time, but non-human identities do not behave like annual review paperwork. Service accounts, API keys, certificates, and automated workflows can accumulate privilege, drift from their original purpose, and keep working long after the business context has changed. That is why current guidance in the NIST Cybersecurity Framework 2.0 and NHI governance research points toward continuous visibility rather than periodic check-ins.

NHIMG research shows the scale of the problem: in the Ultimate Guide to NHIs, only 5.7% of organisations reported full visibility into service accounts, while 71% of NHIs were not rotated within recommended time frames. That combination is exactly what calendar-led programmes miss, because the review cycle is detached from actual exposure, usage, and privilege growth. In practice, teams often discover the failure only after a secrets leak, a misuse event, or an audit request that cannot be answered cleanly.

For security teams, the real issue is not whether a review happened on schedule, but whether the identity was still safe at the moment it was being used. In practice, many security teams encounter active compromise only after access has already been abused, rather than through intentional risk detection.

How It Works in Practice

Risk-signal-driven governance replaces fixed review dates with event-driven controls. Instead of waiting 90 days to re-certify access, the programme watches for indicators such as unusual authentication patterns, new privilege grants, stale credentials, failed rotations, excessive token lifetimes, unused accounts, and changes in system ownership. Those signals can trigger immediate action: step-up approval, temporary suspension, token revocation, or a forced revalidation of business need.

This is where identity governance becomes operational rather than administrative. A strong model combines inventory, ownership, and usage telemetry with policy enforcement at the point of access. The practical goal is to decide whether an identity should keep access now, not whether it passed a quarterly review. That aligns with the NIST control model for least privilege and access enforcement in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where account lifecycle, privileged access, and revocation need to be tied to actual risk conditions.

• Use ownership metadata so every NHI has a named accountable team.
• Track last use, last rotation, and privilege changes as live signals.
• Trigger reviews on anomalies, not just on calendar dates.
• Shorten credential TTLs so misuse windows are smaller.
• Automate revocation for stale, orphaned, or over-privileged identities.

NHIMG’s Lifecycle Processes for Managing NHIs guidance is especially relevant here because it frames rotation, offboarding, and visibility as continuous lifecycle controls rather than periodic administrative tasks. These controls tend to break down in highly automated CI/CD environments because identities are created and used faster than manual review cycles can observe them.

Common Variations and Edge Cases

Tighter risk-based governance often increases operational overhead, so organisations have to balance detection quality against false positives and response fatigue. That tradeoff becomes sharper when thousands of short-lived identities support pipelines, microservices, or third-party integrations. Best practice is evolving, but there is no universal standard for which signals must trigger revocation versus escalation, so policy design needs to match the environment’s tolerance for interruption.

Some identities should not be treated the same way as others. A long-lived break-glass account, a machine-to-machine integration token, and a vendor-managed API key may all require different review thresholds, different expiry rules, and different evidence for continued legitimacy. The Top 10 NHI Issues research shows why this matters: broad, one-size-fits-all governance frequently misses excessive privilege, weak rotation, and hidden ownership.

Calendar-based reviews also break down during mergers, rapid cloud migration, and incident response, when identity sprawl grows faster than policy teams can reconcile it. In those cases, the most useful control is usually not a perfect annual attestation, but a reliable signal that the identity is still active, still needed, and still bounded by least privilege. Where signals are incomplete, current guidance suggests treating uncertainty itself as a risk signal rather than assuming the old review date remains valid.

Related resources from NHI Mgmt Group

• What breaks when identity governance still relies on manual approvals and rule maintenance at scale?
• Why do context signals matter in access requests and certifications for identity governance?
• Why do identity security programmes need trust scoring and risk signals for non-human identities?
• What breaks when identity governance platforms do not reconcile accounts and entitlements regularly?