What should teams do when an application cannot support automated deprovisioning?

Why teams need a fallback when automated deprovisioning is not available

If an application cannot deprovision accounts automatically, the risk is not just slower cleanup. Access can linger after a user leaves, a contractor rolls off, or a role changes, which creates orphaned access and makes the removal of tokens, certificates, and directory entitlements dependent on human follow-up. The control objective shifts from perfect automation to reliable containment and documented exception handling.

That is why the fallback should be a compensating control, not an informal workaround. If the app cannot participate in lifecycle enforcement, teams need another control point that can still stop active use, reduce blast radius, and preserve an auditable trail for who owns the gap.

For teams managing joiner-mover-leaver processes, the practical question is whether the application has any upstream control that can cut access even when the app itself cannot. NHI Management Group’s Joiner-Mover-Leaver (JML) Guide is useful here because the underlying problem is lifecycle enforcement, not just one failed deprovisioning integration.

What compensating controls usually look like in practice

The most reliable fallback is to disable the account at the directory or SSO layer first, because that usually removes the strongest upstream path into the application. If that is not possible, remove group memberships, revoke sessions, and invalidate any tokens or certificates that can still authenticate the account. The key point is to remove the strongest access paths available, even if the application remains technically uncooperative.

Teams should also distinguish between account disablement and true entitlement removal. A dormant account inside the application may still hold permissions, shared secrets, or delegated access paths that become relevant again if the account is re-enabled. If the app uses tokens or certificates, revocation matters because access can persist outside the normal login flow.

When the environment depends on shared identity infrastructure, upstream controls are often the only dependable control plane. The SCIM and Automated Provisioning Guide explains the provisioning pattern, but the operational lesson is broader: where automated deprovisioning is unavailable, teams still need a deterministic removal path that acts at the identity layer rather than waiting on the application vendor.

How to manage the exception without losing governance

Every unsupported application should be tracked as an exception with a named owner, a manual offboarding step, and a review date. That record should show what control is being substituted, who executes it, and how quickly it must happen after a joiner-mover-leaver event. Without that ownership, the gap tends to become permanent.

The exception should be treated as a lifecycle risk, not a documentation task. If the application is business-critical or holds sensitive access, the manual process needs testing, because a theoretically documented offboarding step is not the same as a step that reliably happens during real turnover or incident response.

Where the gap also involves persistent keys or signing material, the remediation scope may need to extend beyond user access. The Coupang Signing Key Breach is a reminder that offboarding failures can leave valuable credentials active long after the person who created or used them has gone.

Risk and Threat Considerations

When deprovisioning is manual, the main risk is residual access. That can produce orphaned accounts, delayed revocation, and stale credentials that remain usable after employment ends or privileges change. If attackers gain access during that window, they benefit from a control gap that was created by process failure rather than by a direct technical vulnerability.

Failure mechanism: access removal depends on a person noticing the event, executing the step, and confirming completion, so delays or misses leave valid accounts, sessions, tokens, or certificates active longer than intended.

Impact: former users, contractors, or compromised accounts may retain application access, enabling unauthorized data access, privilege misuse, or continued authentication until the exception is resolved.

Practitioner Guidance

What to prioritise: Use the strongest upstream control that still works, usually directory or SSO disablement, then remove any memberships or credentials that can preserve access. If the application cannot enforce lifecycle events itself, the compensating control must be stronger than the application’s weakness.

What to verify: Confirm that the manual offboarding path is actually executable within your required time window, and that the owner can evidence completion. If the app uses certificates, tokens, or shared secrets, verify that the offboarding step includes revocation rather than only account status changes.

Common mistake: treating an exception record as sufficient control. A tracked gap is not a mitigated gap unless there is a dependable, tested removal process that works when people are busy, absent, or under incident pressure.

Practitioner takeaway: If automated deprovisioning is unavailable, the control objective is to remove access upstream, not to accept residual access and hope manual cleanup keeps pace.

Related resources from NHI Mgmt Group

• What should organisations do when an application cannot support automated access review?
• What breaks when provisioning and deprovisioning cannot be automated across app portfolios?
• What breaks when an enterprise application cannot support the login providers a customer already depends on?
• When should organisations prioritise automated deprovisioning over adding more application integrations?