okta lifecycle management deprovisioning stuck
Unsticks Okta Lifecycle Management deprovisioning that fails to remove app access. Covers provisioning logs, connector errors, and manual cleanup. Use when offboarded users keep app access after deprovisioning ran. Not for initial provisioning failures.
TL;DR
Open the app's Provisioning > Integration logs in Okta and find the failed deprovisioning task and its error. Fix the connector issue (usually expired API credentials or a missing required attribute), then retry the task. Verify the user is actually gone from the app, not just deactivated in Okta.
The error
(Offboarded user still shows as active in the downstream app days after Okta deactivation.)Steps
- Okta Admin > Applications > the app > Provisioning > Integration logs. Expected: the deprovision task with an error (e.g. "invalid credentials" or "user not found").
- For credential errors: check the app's API token or OAuth connection in the Provisioning > Integration tab. Expected: valid. Tokens expire silently and break all provisioning.
- For "user not found" errors: the app-side account may have been renamed or manually deleted. Expected: identified. Clean up the orphan and mark the task complete.
- Retry the failed task from the log. Expected: success. Then confirm in the app itself that the user is deactivated or deleted per the deprovisioning profile.
- Check whether OTHER users are stuck in the same app. Expected: none. A systemic connector failure affects everyone; fix it once.
When to use
- Deprovisioned users retain app access
- Provisioning log shows failed deprovision tasks
When not to use
- Provisioning (granting access) failures
- Okta user deactivation itself failing
Compatibility
- Okta Lifecycle Management; SCIM or API-based provisioning apps
Variants
Deprovisioning profile set to "deactivate" but app needs "delete"
Check the app's deprovisioning settings. Some compliance regimes require hard delete, not deactivate.
Works for new offboardings but old ones are stuck
The connector broke at some point and tasks queued behind it. Clear the backlog after fixing the connector.
Why it happens
Deprovisioning depends on a working API connection to each app. When the connection breaks, Okta queues failed tasks and the user keeps access indefinitely, which is exactly the compliance risk lifecycle management exists to prevent.
Edge cases
- Apps without provisioning connectors: deprovisioning is manual; keep a checklist per app.
- Re-hired users: ensure the reactivation path re-provisions cleanly rather than colliding with the old account.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_AkH5p5VvelFHRzZcYjmwBw