TL;DR: Partially offboarded users leave active access behind in cloud apps, internal tools, and shared resources, creating unauthorized access, insider risk, and audit exposure when offboarding is incomplete, according to Linx Security. In practice, the problem is less about leavers than about lifecycle control that stops short of full deprovisioning.
At a glance
What this is: This article examines how partial offboarding leaves former users with active access in cloud apps, internal tools, and shared resources, creating security and governance exposure.
Why it matters: It matters because IAM, IGA, and PAM teams need full lifecycle revocation across every connected system, not just a completed HR exit workflow.
Context
Partially offboarded users are former employees whose access was removed in some systems but not all. The identity governance gap appears when deprovisioning stops at the primary directory while cloud applications, internal tools, or shared resources still trust the account.
In practical IAM terms, the problem is incomplete lifecycle closure. When access removal is fragmented across apps and teams, the organisation loses confidence in who can still reach sensitive systems, which increases both security risk and compliance exposure.
This pattern is common in environments with SaaS sprawl and decentralised application ownership, where offboarding depends on manual follow-up rather than enforced control. The article frames that state as a governance failure rather than a single missed ticket.
Key questions
Q: What breaks when users are only partially offboarded?
A: Partial offboarding leaves some access active after employment ends, which means former users can still reach data, applications, or shared resources. The breakdown is governance as much as security: the organisation believes access is removed, but the systems still trust the identity. That creates lingering exposure, insider misuse risk, and compliance gaps.
Q: Why does incomplete vendor offboarding create compliance risk?
A: Because the organisation may still hold personal, contractual, or regulated data in systems the vendor can reach, while also lacking proof that access was revoked and data was deleted. Regulators and auditors care about closure evidence, not intent. If you cannot demonstrate who removed access and when, you cannot show control.
Q: How do security teams find accounts that were missed during offboarding?
A: Compare the leaver list against live application entitlements, then look for accounts that remain active in SaaS tools, shared workspaces, and delegated admin systems. Prioritise systems with local access management because they are the most likely to drift away from central governance.
Q: How do organisations know offboarding is actually complete?
A: They know offboarding is complete when the revocation checklist is built from current entitlements, not from an old spreadsheet or onboarding record. Completion should be confirmed against live access data across apps, directories, and privileged systems. If the workflow cannot prove removal, the account is not fully offboarded.
Technical breakdown
Why partial offboarding leaves access behind
Partial offboarding happens when one or more systems retain an account after the person has left. In identity terms, revocation is not complete until the last dependent application, shared resource, and delegated permission has been removed. The technical failure is often not authentication itself but lifecycle synchronisation across directories, SaaS platforms, and privileged access paths. If those systems are not tied to the same deprovisioning event, access lingers even though the employment relationship has ended. That creates orphaned access states that are difficult to spot from a central console alone.
Practical implication: treat offboarding as a multi-system revocation workflow, not a single directory disablement event.
How lingering credentials become a security path
When credentials remain active after offboarding, the account can still authenticate to email, file storage, CRM, or shared workspaces. That opens two pathways: the former user may misuse access directly, or an attacker may compromise the dormant account and operate with a believable identity. Because the account once belonged to a real employee, the activity can blend into normal access patterns unless revocation and monitoring are tightly linked. The risk is amplified in environments where each SaaS application maintains its own local authorisation state.
Practical implication: monitor dormant but still-valid accounts as active attack paths until every linked credential is revoked.
Why governance breaks when offboarding is not centralised
Governance breaks when no single process can prove that access removal reached every application and resource. Central identity control is only effective if downstream systems consume it consistently, and many SaaS estates do not. That creates policy enforcement failures, audit gaps, and shadow IT exposure because teams cannot easily show who still has what. The broader problem is lifecycle drift: the identity record says the user is gone, but the ecosystem still behaves as if they exist. That mismatch is the essence of partial offboarding.
Practical implication: reconcile deprovisioning evidence across all connected systems before closing the leaver case.
Threat narrative
Attacker objective: The attacker or ex-employee seeks continued access to sensitive data and systems after the organisation believes the identity has been removed.
- Entry occurs when a former employee retains active credentials or application access after departure, often because offboarding was only partially completed.
- Escalation follows when those still-valid accounts are used to reach sensitive systems such as email, file storage, CRM data, or shared resources.
- Impact occurs through unauthorised access, insider misuse, or compromise of dormant credentials by an external attacker who finds the account still trusted.
Breaches seen in the wild
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
- Ledger Connect Kit npm compromise 2023: Attackers phished a former Ledger employee with unrevoked npm access and published a wallet-draining Connect Kit, stealing about $600k on 14 Dec 2023.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Partial offboarding is a lifecycle control failure, not a leaver administrative issue. The identity record may show the employee is gone, but governance has not actually ended until every dependent system has revoked access. That distinction matters because security teams often measure completion at the directory layer, while the real exposure sits in cloud apps and shared resources. Practitioners should treat offboarding as a closed-loop control, not a paperwork milestone.
Standing access after departure creates identity blast radius. The risk is not just that one account remains active, but that its trust extends into multiple services that each maintain their own authorisation state. Once that account survives the exit process, it can be used directly by the former user or indirectly by anyone who compromises the dormant credentials. For IAM teams, the practical conclusion is that revocation must be measured by residual reach, not by HR status.
Partial offboarding exposes a governance assumption that access removal is naturally complete once the primary identity store is updated. That assumption was designed for environments where a single control plane defined entitlement truth. It fails when SaaS sprawl, delegated administration, and shared resources allow local access states to persist after central deactivation. The implication is that lifecycle governance must be proven across the edge of the estate, not assumed from the core.
Risk-based access review becomes a compensating control only when offboarding is already imperfect. Reviews can catch missed accounts, but they do not fix the structural problem that deprovisioning did not reach every system. The better governance signal is whether teams can demonstrate complete revocation evidence across apps, not whether they rely on periodic inspection to find leftovers. That shifts the programme from detection of leakage to proof of closure.
Audit exposure is a symptom of the same control gap that leaves security exposure behind. Regulatory frameworks care about demonstrable control over access, not just policy language. When partially offboarded users still exist, the organisation cannot show that removal, review, and accountability all converged on the same endpoint. Practitioners should read this as a lifecycle assurance problem that spans IAM, IGA, and compliance evidence.
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: Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs
What this signals
Identity blast radius: the hidden risk in partial offboarding is not the leaver event itself but the number of systems that continue to trust the account after central HR closure. IAM teams need evidence that revocation propagated to every downstream app, because any surviving entitlement is still a live control failure.
Access reviews can catch some missed accounts, but they cannot compensate for a deprovisioning process that stops short of the edge systems where access actually persists. The more SaaS and delegated administration an estate has, the more offboarding has to be treated as a verified closure process rather than a manual checklist.
According to the Ultimate Guide to NHIs, only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. The same governance weakness shows up in human offboarding when organisations assume removal is complete before every downstream system has been checked.
For practitioners
- Map offboarding to every downstream system Build the leaver workflow so directory disablement triggers removal in cloud apps, internal tools, shared drives, and privileged platforms. Do not close the case until each connected system returns a revocation confirmation.
- Reconcile residual access before sign-off Require a post-offboarding check that compares the employee record against live entitlements, especially for SaaS applications that manage their own local permissions.
- Inventory orphaned accounts and local entitlements Identify systems where application administrators can create or retain access outside the central identity process, then flag those accounts for special revocation monitoring.
- Use risk-based reviews for missed revocations Schedule targeted access reviews for accounts likely to be missed during the exit process, such as shared resources, external collaboration tools, and low-visibility SaaS apps.
Key takeaways
- Partial offboarding leaves former users with active access in places the primary identity system no longer sees.
- The main evidence of risk is lingering trust in cloud apps, internal tools, and shared resources after departure.
- Complete offboarding requires confirmed revocation across all connected systems, not just a disabled core account.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article is about access that remains after a user leaves, which is the core offboarding failure. |
| NHI-05 — Overprivileged NHI | Residual access after departure leaves accounts with more privilege than the business needs. | |
| Recommendation — Audit leaver workflows for NHI-01 and verify every downstream account is actually revoked. Reduce surviving entitlements to the minimum and remove any privilege that outlives the user’s role. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | AC-2 directly governs account lifecycle closure and termination after role changes or departure. |
| Recommendation — Apply AC-2 to ensure account termination is confirmed across all connected systems. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The post centers on whether permissions and entitlements are removed everywhere they exist. |
| Recommendation — Use PR.AA-05 to validate that entitlements are removed, not just marked inactive centrally. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account management is the control domain for preventing orphaned access after offboarding. |
| Recommendation — Use CIS-5 to enforce timely account removal and review orphaned access paths. | ||
Key terms
- Offboarding: Offboarding is the controlled retirement of a workload, service account, token, certificate, or other non-human identity when it is no longer needed. It includes revoking credentials, removing permissions, and verifying that no residual trust path remains available to attackers.
- Orphaned Account: An orphaned account is an identity that remains active without a clear owner or business purpose. These accounts are dangerous because they often escape review, retain unnecessary access, and provide attackers with low-friction entry points into otherwise governed environments.
- Session revocation: The ability to invalidate active sessions so access ends immediately instead of waiting for tokens or browser state to expire. For identity governance, this is the control that determines whether authentication still matters after a compromise is detected.
- Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 5, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org