What happens when organisations do not deactivate IAM accounts as users change roles or leave?

When deactivation is missed, the organisation keeps paying for access it no longer needs and leaves residual credentials in place. That weakens governance, increases the number of accounts security teams must monitor, and expands the opportunity for misuse. Over time, unmanaged dormant access makes IAM operations harder to control and more expensive to remediate.

Why Unremoved IAM Accounts Become a Governance Problem

When role changes or departures are not reflected in IAM, access stops matching business need. The account may still authenticate, but the organisation has lost a reliable link between identity, employment status, and current privilege. That creates avoidable exposure: access reviews become noisier, exceptions multiply, and control owners can no longer tell which accounts are active by design versus active by neglect.

This is not only an administrative issue. Dormant or misaligned IAM accounts can preserve pathways into production systems, data stores, and administrative tools long after the original business justification has expired. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how often lifecycle control lags behind operational reality. In practice, many security teams discover these accounts only after audits, incidents, or a failed access review, rather than through deliberate offboarding.

How It Works in Practice

Effective IAM lifecycle control depends on timely deprovisioning, role-based re-scoping, and periodic recertification. When someone changes jobs, the correct response is not just adding new entitlements; it is also removing access that no longer fits the new role. When someone leaves, the organisation should treat account deactivation as part of the termination workflow, not as a later cleanup task. If those steps do not happen, old entitlements continue to accumulate and the identity record becomes an unreliable source of truth.

That failure shows up differently across environments. In cloud services, stale accounts may still hold console access or API privileges. In internal applications, they may remain enabled because downstream systems were never tied to HR or ticketing events. In privileged environments, the issue is more severe because an account that was once appropriate for an administrator or operator can remain a high-impact access path even after the person’s responsibilities have changed.

Access reviews lose value when they confirm accounts are still active without verifying whether they are still needed.
Joiner-mover-leaver processes break when movers are handled like joiners and leavers are handled manually.
Privilege creep grows when old permissions are retained “just in case” and never revisited.
Detection becomes harder because dormant accounts blend into ordinary identity inventory.

For this reason, lifecycle governance should be tied to authoritative business events, not to periodic memory or informal manager requests. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it treats account management, access enforcement, and review as controllable processes rather than ad hoc cleanup. NHI Mgmt Group’s research on the Ultimate Guide to NHIs also highlights how identity sprawl and weak offboarding practices create durable exposure that survives the original user relationship.

These controls tend to break down when account creation is automated but deactivation still depends on manual follow-up across disconnected systems.

Common Variations and Edge Cases

Tighter deactivation controls often increase operational friction, so organisations have to balance speed against certainty. Contractors, shared service accounts, break-glass access, and regulated administrator roles all create edge cases where immediate removal is not always the right action, but leaving access intact without a review deadline is still a governance failure.

Best practice is evolving toward time-bounded exceptions and stronger evidence for why an account must remain enabled. For movers, the important question is whether the old role should be removed immediately or temporarily retained under change control. For leavers, there is usually little justification for delay unless the account is tied to an active service or legal hold. The key is to distinguish human departure from non-human dependence, because a service account may need reassignment rather than deactivation.

Where organisations get this wrong is assuming that inactivity equals safety. Dormant does not mean harmless. A forgotten account can still be reactivated, inherited, or abused if credentials remain valid. The real control objective is not just disabling accounts faster, but proving that every retained identity still has a current business owner and a valid reason to exist.

Risk and Threat Considerations

Residual IAM accounts create a persistent access-control weakness. The risk is not limited to former employees using old credentials; stale accounts also create a ready-made target for attackers who obtain passwords, tokens, or session paths that were never revoked after a role change or departure.

Failure mechanism: When deactivation is delayed, the organisation keeps trust active after the business relationship has changed. That weakens least privilege, undermines joiner-mover-leaver controls, and leaves valid authentication paths in place for accounts that should no longer exist or should have been re-scoped.

Impact: The likely consequence is unauthorised access to applications, administrative consoles, or sensitive data, plus slower incident response because defenders must sort legitimate current access from legacy access that should have been removed much earlier.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	5.3 — Disable Dormant Accounts	Directly addresses removal of unused accounts after role changes or departure.
Recommendation — Disable dormant accounts promptly and verify deprovisioning after each role or employment change.
NIST CSF 2.0	PR.AA-01 — Identity and Access Management	IAM lifecycle failures weaken identity governance and access enforcement.
	PR.AA-05 — Access Permissions Management	Stale entitlements persist when permissions are not re-scoped during movers and leavers.
	PR.DS-01 — Data-at-Rest Protection	Residual accounts can still expose protected data if access is not revoked.
Recommendation — Enforce identity lifecycle controls that remove access when business need ends. Review and re-scopes permissions whenever roles change or access should expire. Remove unused account access paths before they can expose stored data.
MITRE ATT&CK	T1078 — Valid Accounts	Stale IAM accounts provide attackers with legitimate credentials or reusable access paths.
Recommendation — Hunt for and revoke stale valid accounts before adversaries reuse them.

Practitioner Guidance

What to prioritise: Treat leaver deactivation and mover privilege removal as separate control events. A role change should trigger entitlement review immediately, while departure should trigger account disablement, credential revocation, and ownership reassignment before the identity is considered closed.

What to verify: Confirm that every enabled account has a current owner, a current business purpose, and an expiration or review date where appropriate. If an account cannot be mapped to a named owner and a valid justification, it should be treated as an exception, not as a normal production identity.

Decision rule: If the account can reach production data, admin functions, or external services, remove or re-scope access before relying on later periodic reviews. If the account is truly a service identity, manage it under a different lifecycle than human IAM and document that distinction explicitly.

Practitioner takeaway: The main control question is not whether an account still works, but whether its continued existence is still defensible under current business authority.