Because deprovisioning only removes access the governance system originally knows about. If a user gained access through a manual channel, that entitlement can survive offboarding unless another process brings it back into scope and removes it explicitly.
Why disconnected applications turn offboarding into a control problem
Disconnected applications create termination risk because the leaver process can only revoke what it can see. If access was granted outside the governed workflow, the entitlement may never be tied back to the authoritative record, so offboarding completes on paper while an active path into the application remains open.
That gap is not just administrative. It turns termination into a reconciliation problem, where security depends on whether someone discovers the hidden access before the account, token, or shared credential is abused, reused, or forgotten.
Where the risk comes from in practice
The risk usually starts with fragmentation: one system provisions and deprovisions the official account, while another channel creates manual access, local roles, shared credentials, or one-off exceptions. When applications are not integrated, the control plane loses visibility into those alternate pathways.
Once that happens, offboarding no longer guarantees effective revocation. A terminated worker, contractor, or other leaver can retain access through a stale entitlement, a local account, a manually assigned role, or a credential that was never brought under the governance process in the first place. The more disconnected the environment, the more likely that access review and removal drift apart.
Identity governance works best when the authoritative source, the application record, and the actual access path stay aligned. NHIMG’s IGA Buyer’s Guide is useful here because it frames disconnected applications as a governance and connector problem, not just an account administration issue.
Why offboarding misses can persist after termination
Disconnected applications create several ways for access to survive termination. A manual entitlement may never appear in the normal removal workflow, a local administrator may not receive the leaver event, or a shared operational account may stay active because nobody owns its revocation. In other cases, the access is technically removable but not discoverable without inventory, ownership, or recertification.
This is why lifecycle control matters as much as provisioning. A leaver process that only disables the primary directory account can still leave application-specific access intact, especially where the business accepted exceptions, bypassed federation, or onboarded the app before integration was available. NHIMG’s NHI Lifecycle Management Guide and Joiner-Mover-Leaver (JML) Guide both reinforce the same operational point: deprovisioning only works when all access paths are mapped, owned, and removed, not merely when the primary account is closed.
That is also why a broad access governance view is better than a ticket-by-ticket approach. NHIMG’s IAM and IGA Basics is a good reference for the difference between authentication, authorization, provisioning, and entitlement governance, which is exactly where disconnected applications tend to fail.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Disconnected app access must be inventoried and removed at termination. |
| IA-5 — Authenticator Management | Terminated users may retain tokens, keys, or other authenticators outside the main workflow. | |
| AC-6 — Least Privilege | Overbroad or manual entitlements increase residual access after termination. | |
| Recommendation — Map every app account to AC-2 and verify deprovisioning reaches local and exception paths. Apply IA-5 to rotate or revoke credentials that can outlive offboarding. Use AC-6 to minimize standing access that disconnected apps can preserve. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Offboarding risk is an identity and access control failure across disconnected apps. |
| Recommendation — Enforce PR.AA-05 so termination events revoke every access path, not only the primary account. | ||
| CIS Controls v8 | CIS-5 — Account Management | Termination risk stems from incomplete account and entitlement removal. |
| Recommendation — Use CIS-5 to track, disable, and remove all accounts tied to leavers. | ||
Practitioner Guidance
What to prioritise: Start with applications that can still grant access outside the authoritative identity workflow, especially systems with local admins, shared accounts, or manual approval paths. Those are the termination blind spots that most often survive normal offboarding.
What to verify: Confirm that every disconnected application has an owner, an inventory entry, and a tested removal path for leavers. If you cannot demonstrate that a termination event reaches the app, assume the app can retain access after offboarding.
What good looks like: Offboarding should remove direct, federated, local, and exceptional access paths to the same application within a defined time window, with evidence that the removal occurred in the target system, not just in the governance queue.
Common mistake: Treating “account disabled” as equivalent to “access removed.” In disconnected estates, those are different outcomes, and only the latter actually closes termination risk.
Practitioner takeaway: The real control objective is not to process leaver tickets faster, but to make sure every application that can grant access is within a revocation path you can prove, test, and audit.