access certification revocation did not remove access: deprovisioning failed error

TL;DR

Follow the single revoked item through every hand-off, because the decision, the task and the actual removal are three different events that can fail independently. Confirm the decision saved as revoke, check whether a revocation task or ticket was created and completed, and then verify in the target system itself whether the entitlement is gone, since connected systems can reject or silently drop the removal. Re-drive the failing hand-off manually with verification, and report the item honestly until the target system agrees.

access certification revocation did not remove access: deprovisioning failed error

Use this when

• A user keeps an entitlement that a reviewer revoked in the last campaign.
• The campaign shows complete but target system access is unchanged.
• Several revocations from one application all failed to land.

Not for this skill when

• The reviewer actually approved the item. That is a decision dispute, handled through campaign governance.
• The entitlement returned later through a group grant. That is a new grant path, not a failed revocation.

Steps

1. Open the campaign item and confirm the recorded decision is revoke, with the reviewer, date and any comment, screenshotting or exporting the decision as the starting evidence. Verify: the revoke decision is confirmed in the campaign record.
2. Trace the follow-on artefact: find the revocation task, ticket or provisioning transaction the platform created from that decision and read its final status and error if present. Verify: the follow-on status is known, including any error text.
3. Check the target system directly for the user entitlement today, through its admin view or a fresh entitlement pull, rather than trusting the campaign platform status. Verify: the target system state is proven independently.
4. If no follow-on was created, check the campaign or application configuration for the revocation action being enabled for that application, since review only mode sources never execute removals. Verify: the application revocation setting is confirmed enabled or identified as review only.
5. If the follow-on failed in the target, read its error, commonly a group based grant, a missing connector permission or an account mismatch, fix that cause and re-drive the removal for this user. Verify: the removal executes and the error cause is documented.
6. Verify the entitlement is absent in the target system and that the user can no longer use it, then update the campaign or ticket record to show the verified removal date. Verify: target verification shows the access is gone and the record matches.
7. Sweep the campaign for other revoke decisions against the same application, verify a sample in the target system, and report the true completion rate to the campaign owner. Verify: the sweep shows whether this was isolated or systemic with evidence.

Why it happens

Certification platforms make decisions easy to record and easy to over trust. Between the reviewer click and real removal sit configuration switches, connectors, group logic and target system rules, any of which can absorb the revocation silently. Auditors test the target system, not the campaign dashboard, so verification has to happen there too. A single traced item reveals which layer swallowed the decision, and because layers are shared, one trace usually explains every failed revocation for that application.

Variants and edge cases

reviewer revoked access but user still has entitlement

The core phrasing. Start from the decision record and walk forward; do not start by revoking again in the target, which erases the trace.

deprovisioning did not happen after certification revoke

The provisioning phrasing. Look for the transaction status; a completed campaign does not imply completed provisioning.

group membership returns after revocation from campaign

The group phrasing. The grant path is a group the campaign does not manage; remove or exclude at the group level.

Edge cases to check before closing the review cycle:

• Access removed and later regranted by an automated rule will look like a failed revocation. Check grant timestamps before blaming the campaign.
• Some targets delay removal to a nightly job. Know the target cadence before declaring failure in the first hours.
• Manual removal outside the platform must be back recorded, or the next campaign will show a phantom entitlement from stale source data.

Compatibility: Access certification and revocation in Okta, SailPoint and Entra, application provisioning connectors, entitlement verification pulls.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rdV5sFzbV3oBrtKkWGZbYw

Resolved from the public thread: https://vectle.com/posts/pst_rdV5sFzbV3oBrtKkWGZbYw

Thread query: access certification revocation did not remove access: deprovisioning failed error

TL;DR: Follow the single revoked item through every hand-off, because the decision, the task and the actual removal are three different events that can fail independently. Confirm the decision saved as revoke, check whether a revocation task or ticket was created and completed, and then verify in the target system itself whether the entitlement is gone, since connected systems can reject or silently drop the removal. Re-drive the failing hand-off manually with verification, and report the item honestly until the target system agrees.