Accountability should sit with the application owner, the identity team, and the process owner for offboarding. If the workflow stops at record keeping and does not revoke the actual entitlement, the organisation has only documented the problem. Mature governance requires a clear owner for both decision and enforcement.
Why This Matters for Security Teams
When a SaaS app stays active after offboarding, the issue is not just a missed checkbox. It is a control failure across identity governance, application ownership, and the handoff between HR, IAM, and business process owners. NIST Cybersecurity Framework 2.0 treats identity lifecycle as part of governance and access control, which means “offboarded on paper” is not the same as “revoked in practice.” The risk is especially acute because SaaS access often persists through SSO entitlements, delegated admin roles, and linked API access long after the employee relationship ends. A useful benchmark from NHI Mgmt Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, showing how lifecycle gaps are usually operational, not theoretical. In practice, many security teams discover lingering access only after an audit, an incident, or a user complaint, rather than through intentional offboarding validation.
How It Works in Practice
Accountability should be split across three layers: the application owner owns the business need and approves the entitlement, the identity team enforces removal from the directory or SSO layer, and the process owner ensures the offboarding workflow actually triggers revocation in the SaaS tenant. That division matters because a completed HR ticket does not necessarily revoke an app session, API token, group membership, or delegated admin role. The control should be designed so that no one can claim success unless the entitlement is removed and verified.
A practical offboarding workflow usually includes:
- Identifying every access path, including SSO, local accounts, SCIM sync, API tokens, and service accounts.
- Requiring the app owner to confirm whether access is still needed for shared mailboxes, handover tasks, or ongoing operations.
- Using identity automation to remove group membership and disable accounts at the source of truth.
- Verifying revocation inside the SaaS app, not just in the identity provider.
- Logging the approval, execution, and validation steps for auditability.
This is where lifecycle guidance from NHI Lifecycle Management Guide becomes operationally useful, because the same discipline used for NHIs applies to SaaS entitlements: provision, validate, rotate, revoke, and confirm. NIST’s access-control guidance in the NIST Cybersecurity Framework 2.0 also supports this model by tying access outcomes to governance, not just record updates. Teams that want a real-world failure pattern can look at SaaS compromise cases such as the Salesloft OAuth token breach, where lingering trust paths and token handling amplified impact. These controls tend to break down in federated SaaS environments with weak SCIM coverage because identity records can be removed while in-app privileges and tokens remain active.
Common Variations and Edge Cases
Tighter offboarding controls often increase operational overhead, requiring organisations to balance speed of employee exit with verification of every downstream entitlement. That tradeoff becomes visible in matrix-managed environments, contractors with exception access, and SaaS tools that allow local admins to create shadow accounts outside the central identity platform. Current guidance suggests that the accountable owner should still be singular for each control step, but there is no universal standard for this yet across every enterprise structure.
Edge cases matter. If the app is business-critical, the application owner may request delayed revocation for knowledge transfer, but that exception should be time-bound and approved. If the identity team can disable SSO but cannot touch local SaaS accounts, the process owner must escalate until the in-app account is removed. If automation only removes directory access, the organisation has reduced exposure but not eliminated it. NHI Mgmt Group’s Top 10 NHI Issues highlights how lifecycle failures and privilege persistence are recurring governance problems, not isolated mistakes. For broader pattern recognition, the Snowflake breach is a reminder that access continuity and token misuse often become visible only after the environment has already been abused. The cleanest answer is not just who approves offboarding, but who proves the access is actually gone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Offboarding is an access removal and governance problem. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Lingering SaaS access mirrors identity lifecycle failures. |
| NIST AI RMF | Governance and accountability are central to controlled lifecycle operations. |
Map every SaaS entitlement to a revocation workflow and validate completion after offboarding.
