User offboarding failures expose the real IAM lifecycle gap

At a glance

What this is: This is a user offboarding best-practices post focused on revoking access, transferring data, and auditing residual entitlements.

Why it matters: It matters because weak offboarding leaves human and non-human access paths open, which can undermine IAM, PAM, and broader identity lifecycle controls.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Zluri's guide to improving user offboarding and access revocation

Context

User offboarding is the point where identity governance either proves it can remove access cleanly or reveals that revocation still depends on manual follow-up. In practice, the problem is not just deactivating a person’s login, but closing every downstream entitlement tied to SaaS apps, SSO, device access, and shared data.

That matters across IAM and lifecycle management because offboarding is a control moment, not an administrative task. When organisations miss accounts, licenses, or application-level permissions, they leave open access paths that can be abused after employment ends, whether by mistake, misuse, or deliberate insider action.

Key questions

Q: What breaks when user offboarding only disables SSO?

A: Disabling SSO alone leaves any direct application grants, cached sessions, or delegated permissions intact. That means the departed user may still reach SaaS platforms even after the directory account is closed. Effective offboarding has to remove access at the application layer, confirm session invalidation, and verify that downstream entitlements are gone.

Q: Why do organisations need a formal offboarding process for access revocation?

A: Because access rarely disappears automatically when employment ends. A formal process ensures that identities, licenses, shared resources, and data custody are reconciled in the right order, reducing the chance of residual access, data leakage, and compliance failure. Without that structure, revocation becomes inconsistent and easy to miss.

Q: How do security teams know if offboarding actually worked?

A: They check for evidence that the user has no remaining active sessions, application privileges, shared resource access, or admin links after termination. If any of those remain, the offboarding is incomplete. The right measure is not whether HR processed the exit, but whether every reachable system shows a revoked state.

Q: Who is accountable when a former employee still has access after offboarding?

A: Accountability usually spans HR, IAM, application owners, and the security team because offboarding crosses system boundaries. The organisation owns the control failure if no one is responsible for verifying revocation end to end. Frameworks like the NIST Cybersecurity Framework 2.0 support that shared governance model.

Technical breakdown

Why offboarding fails when access lives outside the SSO boundary

Single sign-on often creates a false sense of closure because it covers only one part of the access chain. Many applications still hold direct entitlements, cached sessions, or delegated permissions that survive after the identity provider account is disabled. Offboarding therefore has to reconcile identity state across the directory, the SaaS app, and any secondary access grants. The failure mode is not one control missing, but multiple control planes disagreeing about whether the user is still trusted. Practical implication: map every application that can outlive SSO deactivation and revoke at the app layer, not just the directory layer.

Practical implication: revoke access at the application layer, not just the directory layer.

How secure data transfer should work during user offboarding

A clean offboarding process separates access removal from data preservation. The organisation has to back up or reassign business data before final revocation, otherwise important work product disappears with the account or remains trapped in a personal workspace. Secure transfer also needs to respect retention, privacy, and legal requirements so that the handoff preserves integrity without expanding exposure. The technical risk is that teams treat offboarding as a deletion exercise when it is really a controlled custody transfer. Practical implication: build a documented data handoff step that runs before final account closure.

Practical implication: build a documented data handoff step before final account closure.

Why post-offboarding audits are a control, not a cleanup task

Post-departure audits are the only way to verify whether revocation actually reached every system, mailbox, share, and cloud repository tied to the user. These reviews expose dormant privileges, lingering group memberships, and overlooked service connections that normal HR or helpdesk workflows do not capture. In identity terms, the audit is a reconciliation step between the intended offboarded state and the real state across systems. Without it, organisations assume removal happened when they only partially executed it. Practical implication: treat offboarding audits as a mandatory validation gate with evidence, not an optional follow-up.

Practical implication: treat offboarding audits as a mandatory validation gate with evidence.

Threat narrative

Attacker objective: The objective is to keep access alive long enough to read, copy, modify, or misuse corporate data after the user relationship has ended.

1. Entry occurs when a departed employee retains valid SaaS, SSO, or device access after offboarding, creating a persistent path into internal systems.
2. Escalation follows when dormant entitlements, shared permissions, or unrevoked application access are used to reach additional data stores and workspaces.
3. Impact is unauthorized data access, leakage, sabotage, or compliance exposure after the organisation assumed the user had been fully removed.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Offboarding is lifecycle enforcement, not account deletion. The article treats offboarding as a sequence of revocation, data transfer, and audit, which is the correct model. Too many IAM programmes still treat departure as a helpdesk event, then rely on the assumption that disabling one account ends access everywhere. In practice, SaaS entitlements, device access, and delegated permissions can survive the primary cut-off. Practitioner conclusion: offboarding must be governed as a cross-system lifecycle control.

Third-party offboarding is where access governance becomes visible. The strongest value in this topic is not the employee leaving, but the fact that downstream applications often hold their own truth about access. That creates a gap between HR-triggered identity closure and actual entitlement removal. This is where NIST Cybersecurity Framework 2.0 access governance and NHI lifecycle thinking converge: the organisation needs proof that every control plane reached the same decision. Practitioner conclusion: reconcile identity state across directory, SaaS, and device layers before the leaver is considered closed.

Access review cadences do not rescue a broken offboarding model. The point of offboarding is immediate revocation, while access reviews are periodic validation. If a user can remain active between those moments, the programme has already failed its lifecycle obligation. This is a governance timing problem, not a visibility problem alone, and it affects human identities as much as machine credentials. Practitioner conclusion: close the revocation gap first, then use reviews to catch residual drift.

Identity blast radius is the real offboarding metric. A departed user can still touch email, files, SaaS apps, and shared admin functions if those permissions were never reconciled. That is not just access creep, it is post-separation exposure that widens the blast radius of one missed control. The article implicitly shows that the organisation’s real control boundary is larger than the HR termination event. Practitioner conclusion: measure how many systems remain reachable after the primary account is disabled.

Offboarding maturity now spans human and non-human lifecycle discipline. The same governance failure that leaves a former employee active also leaves API keys, service accounts, and delegated tokens behind. This is why lifecycle management cannot be siloed by identity type. The practitioner lesson is to build one closure standard across humans, NHIs, and, where relevant, autonomous access paths. Practitioner conclusion: align offboarding governance across all identity classes, not just employee exits.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• NHI Lifecycle Management Guide shows how to close provisioning, rotation, and offboarding gaps before access outlives ownership.

What this signals

Identity lifecycle discipline is now the differentiator. Offboarding failures are rarely isolated to one user, because the same weak closure logic often exists across service accounts and API tokens. That makes lifecycle management a cross-domain control problem, not a human-leaver checklist. Teams that want fewer residual-access findings should align termination workflows with the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

Residual access should be measured as exposure, not as process completion. If deprovisioning is complete on paper but still leaves reachable data, the programme has not reduced risk. The practical signal to watch is the gap between account closure and actual entitlement removal across SaaS, collaboration, and cloud systems.

Offboarding maturity will increasingly be judged by evidence trails. Organisations will need to prove that access was removed, data was reassigned, and exceptions were resolved. That aligns cleanly with the NIST Cybersecurity Framework 2.0 govern and protect functions, which depend on auditable control execution rather than policy intent.

For practitioners

• Reconcile every downstream entitlement before closure Build an offboarding checklist that covers directory accounts, SaaS app entitlements, device sessions, shared folders, and delegated permissions. Do not mark the departure complete until each control plane returns a confirmed revoked state.
• Separate data custody from access removal Transfer business data to an authorised owner before final account disablement, and verify retention requirements for mailboxes, drives, and app exports. The goal is continuity without leaving the departing user’s identity active.
• Audit for residual access after the primary cutoff Run a post-offboarding review that checks active sessions, orphaned app grants, and stale group memberships. Use the audit as evidence that the offboarding workflow reached every relevant platform.
• Treat SSO disablement as one step in a larger revocation chain Map which applications accept direct authentication, cached tokens, or separate role assignment so you can revoke them independently of the SSO switch-off. That prevents one disabled login from creating a false closure signal.
• Track offboarding exceptions as lifecycle defects Log every missed revocation, delayed transfer, or unresolved application dependency as a governance defect for follow-up. Repeated exceptions indicate that the offboarding process is not operating as a reliable lifecycle control.

Key takeaways

• User offboarding is a control verification problem, not just an HR process.
• Leaving access behind after departure expands the organisation’s real attack surface across SaaS, SSO, and shared data.
• The strongest offboarding programmes reconcile access, custody, and audit evidence before they consider the identity closed.

Key terms

• User Offboarding: User offboarding is the controlled process of removing a departing person’s access, reclaiming assets, and preserving business data. In identity terms, it is a lifecycle control that must reach every directory, application, and session, not just the primary login account.
• Residual Access: Residual access is any remaining entitlement, session, or permission that survives after a user is supposed to be offboarded. It often appears when application-level grants, shared folders, or cached credentials are not reconciled with the final identity state.
• Identity Lifecycle: Identity lifecycle is the end-to-end management of an identity from creation through use, review, offboarding, and retirement. For offboarding, the key challenge is proving that access removal, data handoff, and audit evidence all occurred in the correct sequence.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Best Practices Top 4 Ways to Enhance User Offboarding Process. Read the original.