Employee offboarding software is really identity offboarding

At a glance

What this is: This is a Zluri article arguing that employee offboarding software should be understood as identity offboarding, with access revocation and review treated as the core control problem.

Why it matters: It matters because IAM and IGA teams must treat employee exits as a lifecycle enforcement problem, not a back-office process, or former-user access can persist after departure.

Context

Employee offboarding software is effectively a lifecycle control layer for access, not just a checklist for HR handover. In identity terms, the question is whether departing-user access is actually revoked across applications, data stores, and downstream permissions before the account becomes a residual risk.

The governance gap is simple to state and hard to close: many organisations can describe offboarding steps, but cannot prove consistent execution across systems. Zluri’s article centres on that gap by treating access removal, auditability, and post-departure review as the real outcome, not the administrative ceremony around an employee exit.

Key questions

Q: What breaks when non-employee access is not removed at offboarding?

A: When non-employee access is not removed at offboarding, the organisation loses control of who can still reach admin, customer, or communications systems. That stale access can be used for fraud, data theft, account abuse, or reputational damage. The failure is not just technical. It is a lifecycle governance gap that leaves business-critical permissions active after the relationship ends.

Q: Why do delayed offboarding processes create security risk?

A: Delayed offboarding creates security risk because access can remain active after the business relationship ends. Former users may still reach email, files, CRM, or admin tools, which expands the window for data theft or disruption. The issue is not the departure itself, but the period during which stale access still works.

Q: How do security teams know whether offboarding is actually working?

A: Security teams should measure completion, not process start. Confirm that accounts are disabled, tokens are revoked, privileged roles are removed, and recovery methods are no longer usable across every connected system. Sampling terminated identities is a practical way to prove whether revocation is real or only recorded.

Q: Who should be accountable for identity offboarding across HR, IT, and security?

A: Accountability should sit with the identity governance owner, with HR, IT, and security each owning the steps they control. HR initiates the departure, IT executes technical removal, and security verifies that access is actually gone. The control fails when ownership is split but no one is responsible for final revocation evidence.

Technical breakdown

Why offboarding workflows become identity controls

Offboarding workflows sit at the point where human lifecycle management meets IAM enforcement. A workflow may collect tasks, notify departments, and record completion, but the security value comes from whether it actually disables accounts, revokes app entitlements, and confirms that access is no longer usable. That makes offboarding closer to lifecycle governance than to an HR formality. In practice, the control surface spans SaaS apps, directory objects, licenses, and any delegated access that survives the employee relationship. If those layers are not tied together, the workflow creates visibility without revocation assurance.

Practical implication: Map offboarding to the systems that can still authenticate the departing user, not just to HR notifications.

What access revocation has to cover

Access revocation is not one action. It usually includes account disablement, app-level deprovisioning, licence recovery, and sometimes data transfer or deletion after the user leaves. The article also points to audit trails and run logs as evidence that the process completed, which matters because a successful workflow is only as strong as the records behind it. In identity governance terms, this is a JML problem at the leaver stage: the organisation must know which identities, entitlements, and dependencies have been removed and which remain in place. If revocation is partial, the former user can still reach systems through forgotten entitlements or shared pathways.

Practical implication: Verify that leaver processing revokes every active entitlement, not just the primary account.

Why post-offboarding review matters

Post-offboarding access review is the control that checks whether deprovisioning actually happened. It is especially important where integrations, manual exceptions, or delayed tasks leave residual access behind. The article’s emphasis on alerts, run logs, and audit trails shows that offboarding is not complete when a workflow is triggered; it is complete when the organisation can confirm that access is gone and remains gone. That is why offboarding sits squarely inside identity governance. The operational question is not whether a task ran, but whether the identity has any remaining path into company systems.

Practical implication: Use post-offboarding review to confirm that no active access path survived the employee exit.

Threat narrative

Attacker objective: The attacker objective is continued access to company systems and data after offboarding should have removed that access.

1. Entry occurs through the former employee’s still-active accounts or permissions after departure, typically because revocation did not complete everywhere.
2. Credential or access abuse follows when the ex-employee can still reach SaaS applications, shared resources, or data tied to the old identity.
3. Impact is realised as unauthorised access, data exposure, compliance failure, or misuse of company resources after the employee relationship has ended.

Breaches seen in the wild

• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity offboarding is the real control boundary, not the HR exit event. The article makes clear that the security problem begins after the departure notice, when access still has to be revoked across systems. That is why leaver governance belongs in IAM and IGA, not just in operations or HR handover. Practitioners should treat offboarding as a verifiable identity lifecycle state change.

Access revocation without evidence is only partial control. Zluri’s discussion of run logs, alerts, and audit trails points to a common governance flaw: teams assume deprovisioning happened because the workflow was triggered. In reality, a completed task list is not the same as proof that all downstream entitlements were removed. Practitioners should look for confirmation, not completion theatre.

Offboarding exposes the weakest point in lifecycle orchestration. When an employee leaves, the organisation has to coordinate app access, data handling, license recovery, and compliance evidence at the same time. That makes offboarding a stress test for lifecycle governance maturity. Practitioners should use leaver processing as the benchmark for whether identity lifecycle controls are actually integrated.

Residual access window: This article highlights the gap between employee departure and verified deprovisioning, which is where former-user access persists. That window exists because organisations often manage exit tasks as discrete tickets rather than as a single governed identity state. Practitioners should reframe offboarding around closing that window, not just ticking off tasks.

Top 10 NHI issues still matter here, even for human leavers. Although the article is about employee offboarding, the same lifecycle discipline applies to any identity that should stop being usable once ownership changes. The governance lesson is that access must be tied to a current, accountable identity state. Practitioners should align leaver controls with broader identity lifecycle management rather than isolated departmental workflows.

From our research library:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Residual access window: Offboarding is only secure when the organisation can close the gap between departure and verified revocation across every connected system. If that window stays open, former-user access becomes a governance defect rather than an isolated workflow miss.

For IAM and IGA teams, the practical shift is to measure leaver processing by proof of removal, not by task completion. That means tying account disablement, entitlement removal, and license recovery into one accountable identity lifecycle event.

The same lifecycle discipline now expected for NHIs also applies to employee exits. When identity state changes are not verified, access can persist beyond ownership, which is exactly the condition governance programmes are supposed to prevent.

For practitioners

• Define offboarding as a revocation SLA Set a measurable service-level expectation for disabling accounts, removing app entitlements, and reclaiming licenses after departure notice. Track completion by system, not by department, so the control is measurable rather than assumed.
• Reconcile leaver access against live entitlements Compare the departing employee’s known access list with current directory and SaaS permissions, then confirm that no residual access remains in connected apps, shared groups, or delegated admin paths.
• Require offboarding evidence before case closure Use run logs, audit trails, and completion records as the closure criteria for every leaver workflow. If evidence is missing for any application, keep the case open until the revocation path is verified.
• Automate post-departure access reviews Schedule a follow-up review for former-user access so delayed revocations, manual exceptions, and orphaned permissions are caught after the initial workflow runs.
• Recover and reassign unused licenses Include license reclamation in the offboarding process so departed-user subscriptions, seats, and entitlements are removed from active spend and cannot be reused without review.

Key takeaways

• Employee offboarding becomes a security control only when access removal is verifiable across systems, not merely initiated as a workflow.
• The core risk is residual access after departure, which can lead to misuse, exposure, and compliance failure if revocation is incomplete.
• Identity governance teams should treat leaver processing as a lifecycle enforcement problem and require evidence that access is gone before closing the case.

Key terms

• Vendor offboarding: Vendor offboarding is the controlled removal of a third party's access, data paths, and operational dependencies when the relationship ends or changes. It is a lifecycle control, not an administrative closeout, because any surviving credentials or integrations remain active security exposure.
• Leaver workflow: A leaver workflow is the sequence of actions used to remove access when a person leaves an organisation. It coordinates account disablement, session termination, asset recovery, data transfer and evidence logging so departure does not leave behind active or unowned access.
• Post-Offboarding Access Review: A post-offboarding access review checks whether any permissions survived the exit process. It is the confirmation step that validates deprovisioning across connected systems, especially where integrations, delays, or manual exceptions can leave residual access behind.

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 identity lifecycle management in your organisation, it is worth exploring.