Why does one-time certification fail in practice?

Why This Matters for Security Teams

One-time certification fails because it treats access as a static event, while real environments change continuously. A user can be approved on Monday and be over-entitled by Friday after a role change, a project handoff, a vendor offboarding miss, or a new API connection. That gap is especially dangerous for secrets, service accounts, and other NHIs because they do not self-report when their use drifts from the original approval.

This is why periodic review alone is not enough. The NIST Cybersecurity Framework 2.0 emphasises continuous governance outcomes, not one-and-done signoff. NHIMG research shows the same pattern in incidents involving exposed credentials and AI misuse, including the DeepSeek breach, where credential sprawl and exposed data created attacker-ready conditions. In practice, many security teams discover certification failures only after access has already been abused, not through the review process itself.

How It Works in Practice

Effective certification has to be tied to the lifecycle of the identity, not just the calendar. That means the review should validate who owns the access, what workload or business function depends on it, whether the access is still needed, and whether the credential has been used outside expected patterns. For NHIs, the question is often not "should this account exist" but "does this workload still need this permission in this context?"

Current guidance suggests combining certification with continuous signals from inventory, usage telemetry, and policy enforcement. For example, teams can compare actual access logs against declared ownership, flag dormant or never-used privileges, and revoke secrets that have outlived the job they were created for. This aligns with NHIMG guidance on Non-Human Identities, which frames NHIs as operational identities that require ownership, lifecycle control, and prompt revocation. The practical controls are straightforward:

• Link each entitlement to a named business or technical owner.
• Review actual usage, not just assigned permissions.
• Expire access that is time-bound, project-bound, or environment-bound.
• Require re-approval when scope, system, or data classification changes.

One-time certification works best as a checkpoint, not as a control by itself. These controls tend to break down in fast-changing cloud, CI/CD, and agentic AI environments because access can be created and consumed between review cycles.

Common Variations and Edge Cases

Tighter certification often increases operational overhead, requiring organisations to balance review depth against speed and business continuity. That tradeoff is real, especially where engineers need temporary elevated access or where service accounts support production systems around the clock.

Best practice is evolving for exceptions. For example, standing access for break-glass accounts may be justified, but it should be heavily monitored, tightly scoped, and tested regularly. Long-lived machine credentials are another edge case: if the account must persist, the entitlement should still be revalidated through usage thresholds, secret rotation, and ownership attestation rather than a yearly checkbox.

The Sisense breach illustrates how credential and access failures can cascade when oversight does not keep pace with operational reality. For security teams, the useful question is not whether certification happened, but whether it could have caught drift before exposure. There is no universal standard for this yet, but current practice increasingly combines certification with continuous access review, JIT approvals, and automated revocation to reduce stale privilege.

Related resources from NHI Mgmt Group

• When do NHI access reviews create more value than a one-time cleanup?
• How do organisations reduce the dwell time of exposed credentials at scale?
• Why do one-time consent screens fail for AI agents?
• Why do Duo OTPs and similar one-time codes still fail against phishing?