When should organisations prefer revocation over blanket certification?

Why This Matters for Security Teams

Revocation versus blanket certification is really a question of whether an organisation can prove access is still needed, not whether it has a spreadsheet entry for it. Blanket recertification often becomes a rubber stamp when owners are unclear, service accounts are shared, or teams do not know which systems still depend on an entitlement. That creates hidden exposure, especially when NHIs outnumber human identities by 25x to 50x, as documented in the Ultimate Guide to NHIs — What are Non-Human Identities.

The security goal is different depending on the control. Certification asks, "Should this access remain?" Revocation asks, "Can this access be removed now without breaking the business?" That distinction matters because modern identity governance is under pressure to do both access hygiene and operational continuity. Current guidance from the NIST Cybersecurity Framework 2.0 aligns more closely with continuous risk management than with periodic checkbox review. In practice, many security teams discover weak ownership only after an entitlement survives an incident, not through a well-run certification cycle.

How It Works in Practice

Most organisations should prefer revocation when the entitlement is clearly stale, duplicated, over-scoped, or tied to an NHI that can be reissued safely. That is especially true for API keys, service accounts, certificates, and automation tokens that should be short-lived by design. A practical revocation workflow starts with identifying the workload, confirming downstream dependencies, reducing access in a staged way, and verifying that the workload can fail over, re-authenticate, or reissue credentials without manual intervention. This is where NHI lifecycle discipline matters more than annual attestation.

Useful signals for revocation include:

• No known owner or an owner who cannot explain current usage.
• Privileges that exceed the workload’s documented purpose.
• Duplicate secrets, stale tokens, or credentials embedded outside a secrets manager.
• An entitlement that can be replaced with better NHI lifecycle controls such as rotation, scoped tokens, or JIT issuance.

Revocation is strongest when paired with telemetry. If a team can watch failed authentications, downstream job failures, and fallback behaviour, it can remove access with far less guesswork. That is more reliable than broad certification, which often preserves access because no one wants to own an outage. In a mature model, certification still has a role for exceptions and business-critical dependencies, but it should not be the default answer when the real issue is likely dead access or unmanaged privilege. Security programmes should also tie the decision to the access review cadence described in the NIST CSF identity and access management outcomes. These controls tend to break down when legacy batch jobs, shared service accounts, or vendor-managed integrations cannot tolerate even brief credential interruption because the dependency graph is undocumented.

Common Variations and Edge Cases

Tighter revocation usually increases short-term operational risk, requiring organisations to balance entitlement hygiene against service continuity. That tradeoff is real, especially in production environments with brittle integrations or limited observability. Current guidance suggests revocation first for low-friction NHIs, while keeping certification for high-blast-radius workloads until dependency testing improves. There is no universal standard for this yet, so policy teams should be explicit about which systems qualify for fast removal and which require staged decommissioning.

One useful pattern is to treat certification as an exception-management tool, not a primary cleanup mechanism. For example, if a certificate, token, or service account is still required but ownership is murky, the better outcome is often to narrow scope, shorten TTL, and establish a clear revalidation date rather than approve indefinite retention. The Sisense breach is a reminder that exposed or overretained secrets can turn into broad compromise when their lifecycle is not actively controlled. Organisations that insist on blanket certification for everything often preserve risk because they are optimising review completion, not entitlement reduction.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?