What should teams do when recertification finds access that is no longer appropriate?

What recertification should trigger when access no longer fits

Recertification is not complete when a reviewer identifies bad access, it is complete when that decision is executed in the target system. If access is no longer justified, teams should revoke it, reduce it to the correct entitlement, and confirm the change before the next review cycle. A closed-loop process prevents “approved for removal” from becoming an orphaned control finding.

That distinction matters because recertification is often treated as evidence collection instead of access governance. The review is only the decision point; the control outcome is the entitlement change. When review findings do not flow into enforcement, the organisation keeps carrying the same exposure into the next cycle, and audit evidence becomes misleading.

Why pending tickets are not enough

A pending ticket can record intent, but it does not reduce privilege until the access change is actually made. The operational failure is common: a reviewer denies access, a workflow creates a case, and the case closes without proof that the entitlement was removed or downgraded. That leaves the original risk intact and turns recertification into a paper exercise rather than a control.

The practical standard is simple: the remediation state must match the review decision. If the outcome is deny, the identity should lose access; if the outcome is modify, the entitlement scope should change; if the outcome is retain, the decision should be justified and traceable. In each case, the evidence needs to show completion, not just assignment.

What good closure looks like in practice

Good closure means the review item is tied to a concrete downstream change and a verifiable completion signal. Teams should be able to show the entitlement before and after, the system of record that changed, and the timestamp proving the fix happened before the next review begins. That is especially important where access is managed across multiple platforms, because one unresolved entitlement can survive even when the ticket is marked closed.

For governance teams, the useful question is not whether a reviewer found the issue, but whether the organisation can demonstrate that the issue was removed from the live access model. Access Reviews and Certification Guide describes the closed-loop pattern, and Ultimate Guide to NHIs — Regulatory and Audit Perspectives reinforces why audit trails and completion evidence matter when access decisions have compliance implications.

Where teams need a broader operating model, IAM and IGA Basics frames recertification as part of entitlement governance, not a standalone admin task, while Joiner-Mover-Leaver (JML) Guide shows why the corrective action has to flow through the lifecycle process that owns the access in the first place.

Risk and Threat Considerations

When revoked access remains active after recertification, the organisation keeps an unnecessary attack path open. Excess privilege, stale entitlements, and delayed remediation all increase the chance that a compromised account, insider action, or simple operational mistake can still reach systems that should have been closed off.

Failure mechanism: the control fails when review outcomes are logged but not enforced, so the live entitlement set stays unchanged even though governance records say the issue was handled.

Impact: the same excessive access can persist across review cycles, widen blast radius after compromise, and create audit evidence that overstates the actual security posture.

Practitioner Guidance

What to prioritise: treat every recertification denial as a change request against the authoritative access source, not as a comment on a report. If the access cannot be removed automatically, assign a named owner and require proof of completion before the case is considered closed.

What to verify: confirm the entitlement has disappeared or been downgraded in the production system, not just in the workflow tool. The reviewer should be able to see a before-and-after access state, plus an immutable audit entry that links the decision to the execution.

Common mistake: closing the ticket when the control objective is still outstanding. That creates false confidence and usually shows up later as repeat findings, stale access, or inconsistent audit evidence.

Practitioner takeaway: recertification only has value when denial changes the real access state, because governance without enforcement simply preserves the 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?
• How should security teams govern API keys used for generative AI access?
• How should security teams prioritise NHI remediation in cloud environments?