Accountability should sit with the application owner, the identity team, and the business function that approved the access. If the environment includes third-party SaaS, the vendor relationship owner must also be in scope. Offboarding is only complete when all effective access has been revoked and verified.
Why This Matters for Security Teams
When SaaS access survives offboarding, the question is not just whether a badge was collected or a payroll record was closed. The real risk is that application access, delegated OAuth grants, API tokens, and group memberships can remain effective long after employment has ended. NHIMG research shows this is not a corner case: in the 2025 State of NHIs and Secrets in Cybersecurity, 91% of former employee tokens remained active after offboarding.
That creates a shared accountability problem. The application owner owns the business risk of continued access, the identity team owns the technical controls, and the approving business function owns the decision that granted access in the first place. In third-party SaaS, the vendor relationship owner also matters because revocation can depend on contract terms, admin privileges, and support workflows. The OWASP Non-Human Identity Top 10 treats lifecycle failure as a core identity risk, not an administrative nuisance.
In practice, many security teams discover lingering SaaS entitlements only after an audit, an incident, or a termination dispute has already exposed the gap.
How It Works in Practice
Accountability works best when offboarding is treated as a control chain, not a single ticket. The business function confirms the person or contractor no longer has a need for access. The application owner validates which SaaS tenants, roles, and shared workspaces must be revoked. The identity team executes the technical deprovisioning and verifies that directory groups, SSO assignments, SCIM links, and OAuth consents are removed. If a vendor admin console or support channel is required, the vendor relationship owner ensures the SaaS provider action is actually completed.
This is where lifecycle discipline matters. NHIMG’s NHI Lifecycle Management Guide and the Ultimate Guide to NHIs both point to the same operational truth: access is not fully removed until effective access has been verified across every system that can still authenticate the former user. That includes SaaS, downstream connected apps, token-based integrations, and any externally managed identity bridge.
- Define one accountable owner per SaaS application, with a named backup.
- Require identity team verification, not just a closure note from HR or IT.
- Check token revocation, group removal, delegated admin rights, and active sessions.
- Capture evidence for each revoke step so ownership is auditable.
This guidance breaks down most often in decentralized SaaS environments where application admins can grant direct access outside central identity workflows and no one system has the full revocation picture.
Common Variations and Edge Cases
Tighter offboarding control often increases operational overhead, requiring organisations to balance rapid employee exits against complete access verification. That tradeoff becomes harder in mergers, regulated workflows, and business-owned SaaS where local teams bought the tool outside central procurement. Current guidance suggests the accountable party still does not change, even if execution is distributed: ownership follows the application and the approval path, not the convenience of whichever team can click revoke first.
Edge cases also matter. Shared accounts complicate accountability because a single human departure may not remove the real operational dependency. Long-lived API keys and service accounts can outlast the person who requested them, so the identity team should coordinate with the application owner on whether a replacement credential, rotation, or redesign is required. For third-party SaaS, vendor support delays can leave residual access in place unless the vendor relationship owner escalates closure with the provider.
The best practice is evolving toward continuous verification, not one-time offboarding. NHIMG’s Top 10 NHI Issues frames lifecycle gaps as a recurring exposure pattern, and incidents such as the Salesloft OAuth token breach show how lingering non-human access can become a real business problem. These controls tend to break down when SaaS admins, identity engineers, and business approvers assume someone else already verified revocation.
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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Lifecycle failure is central to lingering SaaS access after offboarding. |
| NIST CSF 2.0 | PR.AC-4 | Offboarding requires prompt revocation of access permissions. |
| NIST AI RMF | GOVERN | Accountability assignments support governance over identity lifecycle risk. |
Assign owners for access approval, revocation, and verification, then track completion.
