Who is accountable when revoked access is not removed after certification?

Accountability sits with the access owner, the reviewer, and the governance process that failed to complete remediation. Certification only works when approval, removal, and evidence are tied together. If access stays active after a denial, the organisation has a control failure, not just a documentation gap.

Why This Matters for Security Teams

When revoked access is not removed after certification, the failure is not only procedural. It means an approved entitlement remained usable after the organisation had already decided it should not exist. That creates a live gap between governance intent and technical enforcement, which is especially dangerous for service accounts, API keys, and other NHIs that can act continuously without human intervention. This is why NHI Management Group treats lifecycle enforcement as a control outcome, not an audit afterthought, as discussed in the Ultimate Guide to NHIs.

Under the OWASP Non-Human Identity Top 10, over-permissioned and poorly governed NHIs are a recurring risk pattern. NHIMG also reports that 91.6% of secrets remain valid five days after notification, which shows how often removal workflows stall after the decision has already been made. In practice, many security teams encounter this only after a denied entitlement is still active during an incident review, rather than through intentional certification design.

How It Works in Practice

Accountability is usually shared across three layers: the access owner who approves or endorses the entitlement, the reviewer who is supposed to challenge it, and the operational team responsible for removing it from the target system. The key point is that certification does not complete until the revoke action is verified. A denied item that is not technically removed is a failed control, not a successful review.

Good practice is to bind the review record to an executable remediation workflow. That means the certification result should trigger ticketing, automated deprovisioning, or just-in-time revocation, with evidence of completion stored alongside the approval. NHIMG’s NHI Lifecycle Management Guide emphasizes that removal, rotation, and offboarding must be treated as a single lifecycle chain. For broader context, the Top 10 NHI Issues highlights why stale credentials and orphaned access remain among the most common failure modes.

• The reviewer approves the decision and must reject any entitlement that is no longer justified.
• The access owner confirms business need and accepts the residual risk of delay if removal cannot be immediate.
• The system owner or IAM operator executes and verifies removal in the source of truth and downstream systems.

In practice, this also requires measurable service levels for revocation, because a denial that lingers for days is functionally still access. These controls tend to break down when entitlements are replicated across multiple directories, cloud control planes, and embedded application permissions because removal is not propagated consistently.

Common Variations and Edge Cases

Tighter certification and revocation controls often increase operational overhead, requiring organisations to balance faster removal against approval friction and system integration cost. That tradeoff becomes more visible when access is shared, inherited, or provisioned through automated pipelines rather than a single IAM system. Current guidance suggests that exceptions should be time-bound, explicitly approved, and revalidated, but there is no universal standard for every exception model yet.

For NHIs, the edge cases are especially awkward. A revoked API key may still work until cache expiry, a token may remain valid until TTL ends, or a downstream service may continue trusting a copied credential even after the primary record is disabled. This is why static revocation checks are not enough for autonomous workloads. The Static vs Dynamic Secrets discussion in the Ultimate Guide to NHIs is relevant here, because lifecycle risk is often about how quickly revocation becomes effective, not just whether a form was approved.

In higher-risk environments, the accountable answer should still be clear: if access remains after a denial, the owner, reviewer, and control process share responsibility until the revoke is completed and verified. Where the environment has many downstream systems or delayed propagation, accountability becomes a remediation chain rather than a single person or ticket.

Related resources from NHI Mgmt Group

• Who is accountable when a hospital contractor keeps access after the work ends?
• Who is accountable when temporary workers retain access after the season ends?
• Who is accountable when access remains active after a leaver event?
• Who is accountable when revoked sessions keep working after access should end?