Accountability should sit with the app owner, the identity team, and the offboarding process owner together, with one named authority for the final revocation decision. The key is that exit handling must be repeatable, documented, and tied to the employment change or role change. Otherwise access tends to persist after the business need ends.
Why This Matters for Security Teams
SaaS deprovisioning is not just an HR exit task. It is an access revocation control that sits across identity, application ownership, and operational process, which is why accountability often slips between teams. If no single authority owns the final revocation decision, dormant access, shared tokens, and delegated permissions can survive long after employment ends. NIST Cybersecurity Framework 2.0 treats identity governance as a core protection activity, not a one-time admin task.
That matters because SaaS access is frequently spread across direct logins, SSO assignments, API tokens, service connections, and vendor-managed roles. The result is that “offboarding complete” on paper may still leave active paths into critical data. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs shows how lifecycle handling, including offboarding, must be explicit to reduce persistent access risk. In practice, many security teams discover missed deprovisioning only after an audit or an incident reveals access that should have been removed weeks earlier.
How It Works in Practice
The cleanest operating model is shared accountability with one named decision owner. The app owner confirms what access exists and what must be removed. The identity team executes the technical revocation. The offboarding process owner ensures the trigger, timeline, and evidence collection happen consistently. That division avoids the common failure mode where everyone assumes someone else closed the account.
For SaaS, deprovisioning should cover more than disabling the primary login. It should include:
- SSO and directory assignment removal
- Native application roles and group memberships
- API keys, OAuth grants, refresh tokens, and app passwords
- Shared inboxes, delegated admin rights, and emergency access paths
- Connected integrations that were authorized by the departing user
Current guidance suggests the process should be tied to the employment event itself, not to a monthly cleanup cycle. That means the deprovisioning trigger should come from HR or a formal role-change workflow, then flow into identity systems and the SaaS owner’s control checks. NIST Cybersecurity Framework 2.0 reinforces this kind of repeatable access governance, while NHI Management Group’s NHI Lifecycle Management Guide is useful for translating lifecycle discipline into practical revocation steps. For high-risk platforms, teams should also retain evidence of who approved the revocation, when it was executed, and whether residual tokens were invalidated. These controls tend to break down when SaaS admins operate outside centralized identity governance because native app permissions and third-party integrations are easy to overlook.
Common Variations and Edge Cases
Tighter deprovisioning controls often increase coordination overhead, requiring organisations to balance speed against completeness. That tradeoff becomes visible in edge cases where access is shared, delegated, or tied to business continuity. For example, contractors may need a different offboarding SLA than employees, and a departing administrator may require immediate revocation plus break-glass replacement before the business can safely continue.
There is no universal standard for this yet, but best practice is evolving toward ownership by system risk rather than by org chart alone. A low-risk collaboration tool may tolerate a simpler workflow, while finance, customer data, or production-support SaaS should require stronger evidence and faster revocation. If a user owns integrations or automation accounts, the offboarding process must also reassign or retire those non-human connections, not just the human login. That is where many programs fail: the person is gone, but the application token or delegated consent still works. NHI Management Group’s Top 10 NHI Issues is a useful reminder that persistent credentials and weak lifecycle control remain common. Teams that rely on manual tickets alone usually miss exceptions when exits happen quickly, across multiple systems, or during incident-driven terminations.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Deprovisioning is identity and access removal, a core access control activity. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Offboarding must revoke lingering secrets, tokens, and app credentials. |
| NIST SP 800-63 | IAL2 | Identity proofing and lifecycle controls support trustworthy account changes. |
Tie account deactivation to verified HR-driven lifecycle events and authoritative identity data.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
