What is the difference between access certification and access revocation?

Access certification is the decision to keep or remove access, while revocation is the technical action that removes it. A programme that stops at certification has only completed half the control. Mature IAM processes connect the two so an approval or denial is automatically reflected in the target system.

Why This Matters for Security Teams

access certification and access revocation are often spoken about together, but they solve different problems. Certification is a governance decision: should access remain? Revocation is an enforcement outcome: is that access actually gone? The gap matters because an approved review that never reaches the target system leaves standing risk, especially for NHIs where access is machine-speed and often widely distributed. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which makes review without removal especially dangerous.

That distinction is also reflected in the broader NHI threat model described in the Ultimate Guide to NHIs — Key Challenges and Risks and reinforced by the OWASP Non-Human Identity Top 10. If a workflow only records decisions, it does not reduce exposure; it only documents intent. For security teams, the practical question is whether the control closes the loop from review to deprovisioning across IAM, PAM, secrets managers, CI/CD, and cloud control planes. In practice, many security teams encounter “clean” access review reports only after the stale tokens and service accounts have already been abused.

How It Works in Practice

In a mature process, access certification triggers a downstream revocation action when access is denied, expired, or no longer justified. That action should remove the entitlement in the source system, invalidate credentials or tokens where possible, and confirm the change in the authoritative record. For NHIs, that often means more than deleting a role assignment. It can involve rotating a secret, disabling a service account, revoking an API key, or closing a federation trust. The security principle is simple: certification decides, revocation executes.

Best practice is to connect governance and enforcement through automation, because manual handoffs are where drift appears. That is especially important for secrets and workload identities, where access may exist in multiple layers at once. The 52 NHI Breaches Analysis shows how often compromised machine identities become the entry point for lateral movement, while the OWASP Non-Human Identity Top 10 highlights weak lifecycle control as a recurring failure pattern.

• Certification should produce an auditable decision with an owner, a timestamp, and a reason code.
• Revocation should call the authoritative control plane, not rely on ticket closure or spreadsheet updates.
• Short-lived credentials, token invalidation, and secret rotation should be used together when the target system supports them.
• Post-action verification should confirm that the entitlement no longer works in practice, not only in the IAM record.

This is where Zero Trust thinking helps: trust should be continuously re-evaluated, and access should disappear as soon as the business justification ends. These controls tend to break down in distributed cloud environments with legacy apps, cached tokens, or disconnected SaaS connectors because the revocation event does not propagate everywhere at the same speed.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, requiring organisations to balance faster risk reduction against system compatibility and user disruption. That tradeoff is especially visible when service accounts support production jobs, customer integrations, or cross-account automation. In those environments, an immediate hard cut can break workflows, so some programmes use staged revocation, expiration windows, or JIT replacement credentials instead of blunt removal.

There is no universal standard for this yet in every platform. Current guidance suggests that certification should be linked to the shortest practical access duration, but the enforcement method depends on the identity type. For humans, revocation may mean disabling accounts and sessions. For NHIs, it may mean deactivating certificates, rotating secrets, or destroying ephemeral tokens. For agentic systems, this becomes more dynamic because access may be granted task by task rather than by static role. The right control is the one that removes the agent’s ability to act once the approved intent is complete, not merely the one that updates the register.

Another edge case is third-party or delegated access, where the owning organisation cannot always revoke directly. In those cases, certification findings should trigger vendor-facing remediation, compensating controls, and heightened monitoring until revocation is confirmed. The Sisense breach is a reminder that exposed machine identities can create broad downstream impact when lifecycle control is incomplete. The operational rule is straightforward: if access cannot be revoked, it is still live risk. In practice, many failures appear only when an incident forces a manual inventory of which systems still trust the identity.

Related resources from NHI Mgmt Group

• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between protecting applications and protecting access?
• What is the difference between static RBAC and dynamic access control?