What happens when unmanaged accounts are not removed during offboarding?

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.

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?