Access can survive role changes and departures in applications that were never formally onboarded. That leaves former users, delegated admins, or shared accounts with lingering permissions that no one is actively certifying. Offboarding has to reach those informal systems or residual access becomes normalised.
What unmanaged accounts leave behind after offboarding
When an account is not removed, the problem is usually not immediate compromise, it is residual authority. Access that was granted for day-to-day work can outlive the person, the role, or the project, so former users, shared logins, and delegated admins may still reach systems nobody is reviewing. That turns offboarding into an incomplete control rather than a clean exit.
That residue matters most in informal or lightly governed applications, because they often sit outside standard provisioning workflows and access review cadence. A user can leave the organisation, or move teams, while permissions in those systems remain active and invisible to normal recertification.
In practice, unmanaged accounts become a form of access debt. Each account left behind preserves a path into data, workflows, or admin functions, and the longer it stays in place, the harder it is to prove who still owns it or whether it is still needed.
Why residual access is dangerous even when nobody is actively using it
Residual access increases the chance of privilege creep, unauthorized use, and accidental dependency on credentials that should have been retired. It also weakens accountability, because the organisation can no longer say with confidence who is responsible for the account, when it was last used, or whether the permissions still match the business need. NHIMG’s IAM and IGA Basics is useful here because access governance only works when offboarding, entitlement review, and ownership are tied together.
Unmanaged accounts also create hidden continuity after a role change. A person may no longer need access, but the system still recognises the account, so the old access path becomes normalised and eventually forgotten. That is how dormant access becomes routine rather than exceptional.
Where the account is shared, delegated, or used for administration, the risk is higher because one unresolved account can preserve broader access than a normal user account. The issue is not just whether the account exists, but whether it still has permissions that let it alter data, manage settings, or reach other systems.
What effective offboarding needs to remove, not just note
Offboarding has to remove the account from the systems that never entered the formal identity lifecycle in the first place. That means finding informal applications, shared credentials, delegated admin accounts, and service-linked access paths, then deciding whether each one should be disabled, rotated, transferred, or explicitly retained with an owner.
The strongest control is a joiner-mover-leaver process that treats deprovisioning as a verification step, not a ticket closure. NHIMG’s Joiner-Mover-Leaver (JML) Guide is relevant because it ties leaver processing to the removal of old-role access, not just HR departure data.
For accounts that were never properly onboarded, the practical question is ownership. If nobody can name the business owner, approve the access, or confirm the last legitimate use, the account should be treated as suspect until proven otherwise. NHIMG’s NHI Lifecycle Management Guide reinforces the broader point that lifecycle control depends on discovery, inventory, and offboarding discipline, even in systems that sit outside the formal stack.
Risk and Threat Considerations
Unremoved accounts extend the attack surface after a departure, because any forgotten credential, shared login, or delegated admin path can be reused long after the original business need is gone. They also increase the chance that a former user, contractor, or attacker who obtained the credential earlier can still reach sensitive systems without raising obvious alarms.
Failure mechanism: Offboarding fails when informal systems are not inventoried, so deprovisioning never reaches the account, or reaches it too late to matter. The surviving access path remains valid because the application, not the HR process, still treats the account as active.
Impact: The organisation inherits lingering permissions, weaker accountability, and a larger window for unauthorized access, privilege abuse, or lateral movement. In high-value systems, a single forgotten account can preserve access well beyond the departure event and undermine confidence in all downstream access reviews.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Offboarding must revoke or rotate credentials that still authenticate former users. |
| AC-2 — Account Management | This question is fundamentally about removing stale accounts and retained access. | |
| AC-6 — Least Privilege | Lingering permissions after offboarding are a least-privilege failure mode. | |
| Recommendation — Revoke, rotate, or expire authenticators when access is no longer needed. Remove or disable accounts promptly when users leave or roles end. Limit retained access to the minimum required and remove excess privileges. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Offboarding must ensure access rights are removed when no longer required. |
| A.5.16 — Identity management | Unmanaged accounts indicate weak identity ownership and lifecycle control. | |
| Recommendation — Review and revoke access rights when employment or need ends. Assign and maintain accountable identity records for all active accounts. | ||
Practitioner Guidance
What to verify: Confirm that offboarding checks the systems people actually use, not only the systems that sit in the official IAM workflow. If the account cannot be tied to a current owner and a current purpose, treat it as a deprovisioning candidate rather than an exception.
Decision rule: If an account can still authenticate after departure, classify the issue as access removal failure, not merely documentation debt. Rotate, disable, or transfer the access first, then investigate how long it remained active and whether any linked secrets or delegated permissions also need review.
Common mistake: Teams often close the offboarding task when HR says the user has left, even though the residual access sits in an informal application or a shared operational account. That leaves the highest-risk systems outside the control that was supposed to retire them.
Practitioner takeaway: Offboarding is complete only when residual access is either removed or re-owned with clear accountability; anything less leaves old authority alive and quietly reusable.
Related resources from NHI Mgmt Group
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- What do security teams get wrong about shared accounts during offboarding?
- What breaks when orphaned accounts are not removed after offboarding?
- Why do offboarding failures create security risk even when accounts are eventually removed?