IAM should own the lifecycle logic for access removal, while SaaS operations should supply the usage and contract context that proves whether access is still needed. When those functions stay separate, offboarding becomes inconsistent and accounts survive because no single team sees the full picture.
How IAM and SaaS split responsibility for app offboarding
The cleanest split is functional, not organisational. IAM owns the deprovisioning rules, account lifecycle, and access governance, while SaaS operations supplies the usage signals, contract status, and application-specific context needed to confirm whether access should be removed. That separation reduces orphaned access, but only if both teams share a single offboarding trigger and a clear handoff point.
What each team must own to avoid orphaned access
IAM should control the policy path: who can be removed, when access expires, what evidence is required, and how revocation is recorded. SaaS operations should own the app facts that IAM cannot infer safely on its own, such as whether a tenant is still active, whether an integration is still needed, and whether the account represents a human, service, or shared operational function.
The practical test is whether the removal decision can be executed without guessing. If IAM only sees an account object, it can remove access too early or leave access in place too long. If SaaS only sees usage, it may miss entitlement scope, privileged roles, or hidden dependencies that keep access alive after the business process ended.
That is why shared responsibility should be written as a workflow, not a meeting habit. One team should trigger the offboarding event, the other should validate the app state, and the final revocation should be deterministic rather than debated ad hoc.
Why offboarding fails when lifecycle, usage, and ownership are split
app offboarding fails most often when lifecycle ownership is fragmented. IAM may be able to disable an identity, but it cannot tell whether the application is still in production use. SaaS teams may know the contract or the tenant owner, but they may not own the entitlement model that determines which roles, tokens, or admin paths must be removed first. See IAM and IGA Basics for the separation between lifecycle control and access governance.
That split becomes more dangerous when access is tied to automation, shared accounts, or long-lived credentials. Offboarding then is not just deleting a user record; it is removing every authenticated path that can still reach the app. NHI lifecycle guidance is relevant here because the same failure pattern appears when tokens, service accounts, or integrations survive the human or business event that should have ended them. Ultimate Guide to NHIs, lifecycle processes shows how provisioning, rotation, and offboarding need to stay aligned.
When the process lacks ownership clarity, stale access survives because each team assumes the other has the last move. That is the real control gap: not a missing ticket, but a missing decision boundary.
How to structure handoff, evidence, and escalation
Use a simple rule: IAM owns the revocation action, SaaS owns the evidence that justifies keeping or removing access. The handoff should include the application owner, current contract or subscription status, active integrations, and any privileged exceptions. If those inputs are missing, the account should default to removal or short-term exception, not indefinite retention.
What to verify: Confirm that the offboarding trigger is tied to a source of record, not an email thread, and that SaaS can prove active need before access is retained. Verify that service and shared accounts are explicitly covered, because those are the paths most likely to survive human offboarding.
What good looks like: The account is removed on a predictable schedule, the exception path is time-bound, and both teams can show who approved retention and why. If the app is still needed, the access should be re-approved under the current business owner rather than inherited from the old one. Joiner-Mover-Leaver (JML) Guide is a useful model for making the leaver step explicit and auditable.
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 and CIS Controls v8 set 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 | App offboarding must retire credentials and tokens, not just users. |
| AC-2 — Account Management | Offboarding is fundamentally account lifecycle control across apps. | |
| Recommendation — Revoke and rotate authenticators when offboarding removes application access. Use account lifecycle controls to disable, remove, and review app access on exit. | ||
| CIS Controls v8 | CIS-5 — Account Management | Shared ownership of offboarding needs explicit account inventory and removal discipline. |
| Recommendation — Maintain account inventory and remove stale app accounts during offboarding. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity Management | Identity lifecycle ownership must be defined between IAM and SaaS operations. |
| A.5.18 — Access Rights | Retaining or removing access during offboarding is an access-rights decision. | |
| Recommendation — Define identity ownership and lifecycle responsibilities for application offboarding. Review and revoke application access rights when the business need ends. | ||
Practitioner Guidance
Decision rule: If IAM can revoke the access but cannot confirm whether the app is still in use, treat the case as a cross-functional offboarding event, not a pure identity task. If SaaS cannot supply current usage and ownership evidence, do not let the account persist by default.
What to prioritise: Prioritise the applications with admin access, shared credentials, API integrations, or contractual churn, because they create the highest chance of silent access persistence. A broader lifecycle view is essential for those cases, and the same discipline appears in lifecycle management for NHIs where stale access is often operationally invisible.
Common mistake: Treating SaaS as merely a requester and IAM as merely an executor. That model leaves no one accountable for the evidence that access should end, which is why dormant accounts and forgotten integrations survive long after the business reason has disappeared.
Practitioner takeaway: The most reliable offboarding model is one where IAM removes access and SaaS proves whether the business still needs it, because lifecycle control without application context, or context without revocation authority, both leave residual access behind.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org