IT offboarding gaps leave former employee access alive

At a glance

What this is: This checklist argues that effective IT offboarding requires removing application, SSO, remote access, and shared-account pathways in the right order.

Why it matters: IAM and security teams need to treat leaver access as a lifecycle and identity governance problem because incomplete deprovisioning leaves data, licenses, and privileged access exposed.

By the numbers:

• 20% of businesses have experienced data breaches connected to former employees.
• 70% of IT decision-makers surveyed said it could take up to an hour to deprovision all of a single former employee’s corporate application accounts.

👉 Read Zluri’s seven-step checklist for secure IT offboarding

Context

IT offboarding is the lifecycle process of removing a leaver’s access, transferring ownership, and closing out any remaining identity and application dependencies. In practice, the failure is usually not the final disablement itself but the order in which teams remove access across apps, identity providers, remote access, and shared credentials.

For IAM, IGA, PAM, and NHI programmes, offboarding is a control point, not an administrative finish line. If application access, ownership, and session state are not handled before SSO is disabled, the organisation can strand accounts, preserve active sessions, or lose control of licences and data.

Key questions

Q: What breaks when offboarding removes SSO access before application access?

A: Teams can strand active application sessions, preserve app-level admin rights, and lose the ability to transfer ownership cleanly. The directory may look disabled while the application still allows access or retains important data. Bottom-up deprovisioning avoids this by clearing downstream access first and only then closing the identity provider entry.

Q: Why do former employees remain a security risk after their accounts are disabled?

A: Because disabling one identity layer does not always revoke all downstream access, sessions, tokens, or remote entry methods. A leaver can still affect data, licences, or shared accounts if those controls were not removed in sequence. The real risk is residual authority that outlives employment and is not immediately visible.

Q: How can security teams tell whether offboarding actually worked?

A: They should confirm that app access, shared credentials, remote login paths, ownership records, and logs all show the same removed state. If any one of those systems still shows activity, offboarding is incomplete. Effective validation looks for consistency across control planes, not just a disabled account in the identity provider.

Q: Who is accountable when a leaver still has access after departure?

A: Accountability usually sits with the identity, IT, and application owners together because offboarding spans multiple systems and process handoffs. The organisation needs a clear owner for deprovisioning completion, not just account closure. If no one is responsible for verifying each step, residual access is almost guaranteed to recur.

Technical breakdown

Why bottom-up deprovisioning matters in offboarding

Bottom-up deprovisioning means removing access at the application layer before disabling the identity provider. That order matters because many applications keep their own sessions, tokens, admin grants, and audit data even after SSO is cut off. If the identity provider is disabled first, security teams can lose the ability to revoke app-specific rights, transfer ownership, or clean up dormant administrative entitlements. The operational issue is not just access removal, but control retention during the transition. Offboarding therefore needs to preserve enough identity authority to clear every downstream dependency before the account is finally retired.

Practical implication: deprovision app access before disabling SSO so you do not strand unreconciled accounts.

Shared accounts, tokens, and session persistence

Shared accounts create a different offboarding problem because the departing user may still hold the password, token, or session context used by others. Even if the employee leaves, the credentials can remain valid in email, collaboration tools, or SaaS platforms until they are rotated. Session persistence is the quiet failure mode here: the account may look inactive at the directory level while access survives in the application itself. For security teams, the real control boundary is not the human departure date but the last credential reset and token revocation point.

Practical implication: rotate shared credentials and invalidate sessions as part of every leaver workflow.

Why log scrutiny still matters after removal

Offboarding is never complete until post-removal activity is checked. Some applications retain a deletion buffer, and some remote access methods or cached sessions continue to generate events after the identity has been marked for removal. Log scrutiny helps confirm that the account really disappeared from the environment and that no residual access path was left behind. This is especially important where ownership transfer, licence removal, and access revocation happen across different systems with different processing times. The technical lesson is simple: deprovisioning is a multi-system state change, not a single button click.

Practical implication: validate post-offboarding logs to confirm the account, not just the directory entry, is gone.

NHI Mgmt Group analysis

Patchy offboarding is a lifecycle governance failure, not an HR cleanup issue. The article shows that access removal, ownership transfer, remote login revocation, and shared credential rotation all need to happen as one governed sequence. When teams handle them as separate admin tasks, former employee access outlives employment and the control plane loses sight of who can still act. Practitioners should treat leaver processing as a high-risk identity lifecycle event.

Former employee access is a standing privilege problem with a delayed discovery window. The article’s 20% breach figure shows that residual leaver access is not theoretical. Once access persists after departure, the environment carries an unowned privilege state that can be abused, audited too late, or missed entirely if teams rely on spreadsheets. That is a classic governance blind spot, and the implication is that revocation timing must become as important as entitlement scope.

Shared-account offboarding exposes a credential custody gap that most IAM programmes still under-model. The departing user often leaves with credentials, tokens, or session continuity that the organisation does not recover fast enough. That failure mode is different from ordinary orphaned account risk because the account may remain socially or operationally shared even after the owner leaves. The implication is that account ownership and credential custody cannot be treated as the same control.

NHI lifecycle controls and human leaver processes are converging on the same discipline. Although the article is about employees, the same governance pattern applies to service accounts, API keys, and other non-human identities that outlive their intended purpose. The relevant framework lens is lifecycle management, not just access management. Practitioners should design one offboarding standard that can be adapted across human and non-human identities.

Identity ownership transfer is part of security, not just continuity. The article correctly shows that leaving documents, licenses, and admin rights with a departed user creates both operational and security debt. If no successor receives control before the leaver is removed, teams can neither verify use nor correct exposure. The implication is that offboarding must include explicit ownership reassignment for the accounts and assets tied to the identity.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That lifecycle gap makes the NHI Lifecycle Management Guide the next resource for teams standardising provisioning, rotation, and offboarding.

What this signals

Offboarding maturity is becoming a broader identity governance signal, not a narrow HR process measure. Teams that still rely on manual spreadsheets will continue to leave access behind, especially where application ownership, shared credentials, and remote access are managed in separate systems. The control question is whether removal is validated end to end, not whether a leaver ticket was closed.

Ownership-transfer debt: the hidden failure mode is not only access that remains active, but data and licences that remain stranded after the user departs. That state produces both security exposure and operational drag because no one can reliably manage the assets the identity left behind.

For identity programmes that also govern service accounts and other NHIs, the lesson is to align human offboarding with the same lifecycle discipline applied to machine credentials. The broad pattern is identical: identify every place an identity is still trusted, then prove that trust has been removed.

For practitioners

• Sequence deprovisioning bottom-up Remove access from applications first, then revoke identity provider access, so you can still transfer ownership and clear app-specific admin rights before the directory account is closed.
• Rotate every shared credential at exit Change passwords, invalidate tokens, and terminate sessions for any shared account the departing user could still reach, especially collaboration and utility tools that are often overlooked.
• Transfer ownership before access removal Reassign documents, subscriptions, and administrative responsibility to a successor before the leaver is fully disabled, or you risk losing the ability to manage the asset later.
• Verify remote access and logs after deprovisioning Check VPN, remote desktop, and application logs after removal to confirm there is no residual login path or delayed account state still allowing activity.

Key takeaways

• Offboarding fails when teams remove identity access before they remove application, shared-account, and remote-access dependencies.
• Residual leaver access is not rare, and it creates breach exposure, compliance risk, and avoidable licence waste.
• The control that changes outcomes is a disciplined lifecycle sequence with ownership transfer, credential rotation, and post-removal verification.

Key terms

• Offboarding: Offboarding is the process of removing a departing user’s access, reassigning their responsibilities, and closing every downstream trust relationship tied to the identity. In identity governance, it must cover applications, remote access, shared credentials, licences, and ownership transfer, not only the directory account.
• Bottom-up deprovisioning: Bottom-up deprovisioning is the sequence of removing access from applications and dependent systems before disabling the identity provider. The method preserves administrative reach long enough to clean up entitlements, rotate credentials, and transfer ownership without stranding active access.
• Shared account: A shared account is an identity used by more than one person or process, often with a common password, token, or session context. These accounts are difficult to offboard because departure of one user does not end the trust relationship, so every shared credential must be rotated or revoked separately.
• Ownership transfer: Ownership transfer is the reassignment of documents, subscriptions, admin rights, and operational responsibility from a departing user to a successor. It prevents security and continuity gaps by ensuring that access removal does not also remove the organisation’s ability to manage the asset.

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: Lifecycle Management Secure IT Offboarding Checklist. Read the original.