What should security teams do first when employee access is not being removed reliably?

Why unreliable removal creates a real access problem

When employee access is not being removed reliably, the issue is not just cleanup. It is a control failure that leaves accounts, sessions, and linked credentials available after the person no longer needs them. The first objective is to establish which access paths still exist, because dormant access often becomes the easiest route into sensitive systems and business data.

That means security teams should treat deprovisioning as a visibility problem before it is a tooling problem. A reliable view of identity records, account inventory, and connected systems makes it possible to see what still exists, what should have been removed, and where old access is still active.

What to verify before you try to remove access again

Start by reconciling people, accounts, and systems, then confirm which access was meant to end versus which access is still legitimately required. The practical goal is to find orphaned access, shared accounts tied to departed staff, and any accounts that were never linked back to an owner. A controlled review of directory data, SSO reports, and admin consoles is usually the fastest way to expose gaps.

Once you have that inventory, verify whether the account is still authenticated anywhere, whether the access is direct or inherited, and whether privileged access was copied into downstream tools. That matters because a removed employee can still retain access through a non-obvious path even after the primary account is disabled.

A useful way to improve repeatability is to anchor the review in Remote Access Identity Guide because remote entry points, dormant access, and third-party reach often outlive the original employment relationship.

How teams should remove access without leaving gaps

The first operational step is to disable the highest-risk paths first, especially anything that can still reach sensitive systems or external connectivity. Then remove or rotate the underlying credentials, tokens, certificates, and delegated access that could keep the account usable in a hidden way. If the account cannot be removed immediately, suspend it and document why it remains temporarily active.

Good practice is to make the process repeatable, not heroic. Use one authoritative access record, tie offboarding to a defined checklist, and confirm that the removal actually propagates to connected applications, remote access systems, and privileged tools. For broader control coverage, the access lifecycle should align with CIS Controls v8 and NIST SP 800-53 Rev 5 Security and Privacy Controls so account removal, access restriction, and auditability are treated as an operating requirement rather than an afterthought.

If the environment uses cloud, hosted, or federated access, the same logic applies to access records, roles, and authentication paths across all systems. That is why many teams also map deprovisioning to ISO/IEC 27001:2022 Information Security Management when they need a formal control structure for access removal and account governance.

Risk and Threat Considerations

Unremoved employee access creates a standing opportunity for misuse, especially when accounts retain remote entry, privileged permissions, or reusable credentials. The main risk is not only accidental access after departure, but also exploitation of stale accounts that no one is actively watching.

Failure mechanism: Incomplete offboarding leaves orphaned or inherited access alive across directories, applications, and remote entry points, so an old identity can still authenticate or reach sensitive resources after employment ends.

Impact: Attackers, insiders, or even former employees can use the leftover access for unauthorized data access, privilege abuse, lateral movement, or persistence, and teams may not notice until much later.

Practitioner Guidance

What to prioritise: Put accounts with privileged, remote, or third-party access at the front of the queue. Those paths create the largest blast radius if deprovisioning fails, so they deserve immediate review before low-risk accounts.

What to verify: Confirm not only that the primary user account is disabled, but that linked sessions, API tokens, shared credentials, and delegated entitlements were removed or invalidated. If a control only closes the login screen but leaves the underlying secret active, the access problem remains.

Common mistake: Treating HR departure as the end of the process. The real test is whether every reachable system can no longer authenticate that person or anything they controlled.

Practitioner takeaway: The fastest way to reduce exposure is to make orphaned access visible, then remove the remaining authentication and authorization paths in a controlled, repeatable sequence.

Related resources from NHI Mgmt Group

• What do security teams get wrong about first-day access for new hires?
• How should security teams govern agent access when identity controls must be API-first?
• How should security teams prepare access evidence for a first SOC 2 audit?
• How should security teams compare 2FA and MFA for employee access?