The main failure is that deprovisioning only reaches the directory and core federated apps, while non-SCIM and locally managed SaaS accounts remain active. That creates orphaned access, lingering license costs, and audit gaps. The fix is not a better ticket process. It is explicit ownership of the app layer and evidence that every exception is closed.
What actually breaks when offboarding stops at the IdP boundary?
When offboarding ends at the identity provider, the directory may say the user is gone while the SaaS tenant still believes the account is valid. That split creates a lifecycle gap: access persists outside the control plane you are watching, so deletion becomes partial, not complete. The practical result is not just residue, but unmanaged access paths that can outlive the employment or contractor relationship.
The key failure is usually not the federated login itself. It is the long tail of SaaS applications that authenticate locally, are not SCIM-enabled, or keep their own admins, tokens, and account stores. Those systems do not automatically inherit the IdP offboarding event, so deprovisioning becomes inconsistent across the app estate.
That is why this problem is an ownership problem as much as a technical one. Someone has to own the application layer, know which services sit outside automated provisioning, and prove that exceptions are removed rather than merely noted.
Why orphaned SaaS access and hidden accounts persist
In a federated environment, the IdP is only one trust boundary. Many SaaS products still keep local users, break-glass admins, API tokens, delegated app roles, and legacy authentication paths that survive even after the central identity is disabled. If those paths are not explicitly inventoried, the offboarding process stops at the wrong layer.
This is especially common when applications were adopted before SCIM, when admin teams created local accounts for convenience, or when a vendor supports federation for login but not full lifecycle management. In those cases, disabling the primary login only removes one way in, not every way in.
NHIMG’s Ultimate Guide section on lifecycle processes for managing NHIs is useful here because it frames offboarding as a lifecycle event, not just a password reset or directory delete. The same pattern shows up in Joiner-Mover-Leaver (JML) Guide, where the real control objective is to revoke all access paths, not only the obvious one.
What good offboarding looks like in practice
Good offboarding treats the IdP as the start of revocation, not the finish. The app owner, security team, and identity team need a shared view of which SaaS tenants are federated, which remain locally managed, and which have exceptions such as service accounts or admin break-glass access. Without that inventory, you cannot prove that deprovisioning is complete.
Evidence matters as much as execution. Practitioners should expect closure records for exceptions, proof that local SaaS accounts were disabled or transferred, and a defined owner for apps that do not participate in automated lifecycle flows. If you cannot show that state, then offboarding is still a partial control.
For SaaS estates with mixed maturity, the right anchor is usually the app catalogue and the exception register, not the ticket queue. The most reliable remediation path is to pair account deactivation with periodic discovery of locally managed SaaS access, then reconcile what the directory says with what each app still allows.
Risk and Threat Considerations
Partial offboarding leaves access behind in places defenders are least likely to watch closely. That creates a straightforward exposure: an ex-employee, contractor, or compromised account can retain reach to business data, admin functions, or billing-linked resources long after the IdP record has been closed.
Failure mechanism: The central identity is disabled, but non-federated SaaS users, app-specific roles, and local tokens remain active because lifecycle ownership stops at the directory boundary.
Impact: You get orphaned access, lingering license spend, audit gaps, and a larger blast radius if old access is abused or never removed.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers revoking and managing credentials that can survive offboarding. |
| AC-2 — Account Management | Directly governs account disablement, removal and ongoing account inventory. | |
| AU-6 — Audit Review, Analysis, and Reporting | Supports evidence that offboarding closed access and exceptions were resolved. | |
| Recommendation — Revoke and rotate lingering SaaS credentials and tokens when the user leaves. Remove or disable every SaaS account and reconcile remaining exceptions. Review logs and closure evidence to confirm offboarding completion. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Addresses identity lifecycle ownership across systems and SaaS tenants. |
| A.5.18 — Access rights | Covers removing access rights when staff or contractors leave. | |
| Recommendation — Define ownership for each SaaS identity and lifecycle exception. Withdraw SaaS access rights as part of the leaver process. | ||
Practitioner Guidance
What to prioritise: Start with the SaaS applications that can still authenticate locally or have no SCIM-based deprovisioning path. Those are the systems most likely to retain access after the IdP event is complete.
What to verify: Confirm that every leaver action has an owning application or platform owner, and that exceptions have a closure trail. If the only evidence is an IdP disablement record, the control is incomplete.
Common mistake: Treating federation as lifecycle automation. Federation simplifies login, but it does not automatically remove local accounts, delegated access, or app-native privileges.
Practitioner takeaway: Offboarding is only real when you can prove that every reachable SaaS account, token, and exception has been removed or transferred, not merely that the central identity disappeared.