What happens when an employee leaves but keeps access to company systems?

Why Offboarding Failures Turn Into Ongoing Access

The core issue is not the departure itself, it is the gap between employment status and access status. If an account, token, certificate, VPN route, or physical badge remains active after an exit, the organisation still trusts a person who no longer has a business need to be trusted. That creates an avoidable window where former staff can act with valid access while controls and monitoring may still treat them as legitimate.

Once departure is confirmed, access removal should be treated as a coordinated identity event, not a ticket for one team to complete later. The Physical Security Guide for Security Teams is useful here because the same offboarding logic applies across badges, system access and other entry paths, not just one control plane.

In practice, the risk increases when access is fragmented across HR, IT, security, facilities and application owners. A user can lose one login and still retain another, especially in SaaS tools, legacy admin consoles, shared admin paths or long-lived machine credentials. The practical question is not whether the person is still employed, but whether any working path remains into sensitive systems.

Trusted removal also includes linked credentials and secrets. If a former employee can still authenticate with a password, API key, certificate, refresh token or device-based credential, then a disabled directory account alone does not close the exposure. That is why offboarding needs to cover every material access path, not just the primary login.

What Can Still Be Reached After Departure?

Residual access often shows up first as data exposure, but the consequences can extend further. An ex-employee may be able to read records, export customer or employee data, approve changes, trigger administrative actions, or reach operational systems that should no longer recognise them. The same problem applies when standing access is left in place for privileged roles, break-glass paths, service portals or remote access tools.

The most important boundary is whether the leftover access can still perform real work. Read-only access can still expose confidential information, and write access can still alter records or workflows. If the account has privileged entitlements, the impact can move from simple disclosure to sabotage, persistence or lateral movement. The Databricks Service Principals and Token Security Guide illustrates the same principle in a system context: token and role cleanup matters because dormant access remains dangerous even when the human relationship has ended.

Access that survives departure can also create hidden dependency risk. Shared accounts, inherited group membership, forgotten application roles and unmanaged sessions are especially problematic because they are easy to overlook during a rushed offboarding process. Organisations should assume that any access path not explicitly removed remains usable until proven otherwise.

The cleanest way to think about it is blast radius. If the ex-employee can still reach production systems, sensitive files, admin consoles or remote sessions, the exposure is operational as well as confidential. The longer the access persists, the more time exists for abuse, accidental use or delayed discovery.

How to Verify the Access Is Really Gone

Verification is more important than the deprovisioning request itself. A completed ticket does not prove that every account, session and credential has been removed, especially when the user had multiple tools, federated logins, delegated permissions or non-human access paths associated with their role.

Good verification asks a simple but demanding question: can the former employee still authenticate anywhere, and if so, where? That means checking directory accounts, SSO connections, application-native accounts, VPN access, privileged access platforms, device trust, API tokens, certificates, service accounts, shared mailbox access and any externally managed vendor portals tied to the role. The Social platform app tokens guide is a reminder that token revocation and expiry validation matter because a credential is only removed when it no longer works.

It is also worth checking for session persistence. Some systems do not stop access when the account is disabled if existing sessions, refresh tokens or cached authorisations remain valid. Where possible, organisations should confirm that sessions are terminated, tokens revoked, certificates invalidated and recovery paths updated at the same time.

Physical access should be checked in parallel. If building entry, badge issuance or visitor access is left active, the former employee may still be able to reach devices, secure areas or systems that are only protected by location. The Tailgating and Piggybacking Guide reinforces the broader point that offboarding failures are not just logical access failures, they are access-control failures across the full environment.

Risk and Threat Considerations

Residual access after departure creates a live insider threat condition. The danger is not hypothetical: a former employee may act intentionally, may retain access accidentally, or may be able to reuse old credentials before anyone notices the offboarding gap. The longer the access remains, the easier it is for misuse to blend into ordinary activity.

Failure mechanism: Access removal is partial, delayed or inconsistent, so one or more active credentials, sessions, badges or privileged entitlements survive the exit process and remain trusted by downstream systems.

Impact: Sensitive data exposure, unauthorised administrative action, disruption of operations, persistence after termination and harder incident attribution become more likely, especially where privileged or remote access was not fully revoked.

Practitioner Guidance

What to prioritise: Treat offboarding as a single access-revocation event, not a sequence of loosely related tasks. The first priority is to remove anything that can still authenticate or authorise action, then confirm that no alternate path remains open.

What to verify: Check for directory accounts, application-native logins, MFA factors, sessions, certificates, API keys, remote access entitlements and physical access rights. If the person had elevated privileges, verify that delegated roles, break-glass paths and shared credentials were also removed or reassigned.

Practitioner takeaway: The real test of offboarding is not whether HR recorded a departure, but whether every path that could still be used to act as that person has been cut off and proven dead.

Related resources from NHI Mgmt Group

• What happens when attackers use valid employee credentials to access internal systems?
• What happens when an employee leaves but privileged access is not removed immediately?
• What happens when a departing employee or compromised user keeps active access to cloud applications?
• What happens when access is not revoked promptly after an employee leaves or changes roles?