Why does relying on SSO or VPN shutdown alone leave offboarding risk in place?

SSO or VPN shutdown is not enough because technical staff often hold direct access to databases, servers, Kubernetes, shared folders, and sensitive credentials outside those entry points. If those permissions remain active, former employees or bad actors may still delete files, change configurations, or steal data. Offboarding must cover every system where access exists, not just the front door.

Why SSO or VPN Shutdown Does Not Equal Offboarding

Shutting down SSO or VPN access closes common entry points, but offboarding risk remains when the person still has direct permissions elsewhere. Databases, servers, cloud consoles, shared drives, service accounts, API keys, and privileged groups can continue to work independently of the login the organisation remembered to disable. That means the real question is not whether one account was disabled, but whether every path that can still reach data or infrastructure has been removed.

For NHI Management Group, this is a classic offboarding failure mode: access is treated as a front-door problem even though the blast radius often lives in back-end systems. Current guidance on lifecycle control is strongest where teams inventory all access-bearing identities, not just interactive logins. The NHI Lifecycle Management Guide is useful here because it frames access removal as an end-to-end process rather than a single toggle.

In practice, many organisations discover the gap only after a former employee account has already changed a configuration, accessed data, or triggered a service through an unrevoked credential.

How Offboarding Actually Has to Work

Effective offboarding starts with the assumption that identity is distributed across systems. A person may authenticate through SSO, but still possess direct database credentials, SSH keys, Kubernetes role bindings, shared mailbox access, SaaS admin roles, or embedded secrets in scripts and pipelines. If each of those permissions is not revoked, the employee can remain operationally present even after the primary directory session is gone.

The practical sequence is to disable interactive access, then remove entitlements, then rotate or revoke any credentials that were ever exposed to the departing user. That includes human credentials and non-human credentials tied to their work, such as tokens, keys, and certificates that may persist in automation. The goal is not just account closure; it is to eliminate all surviving authentication paths and any trusted relationships that still resolve to the person’s former access.

Inventory direct system access outside the SSO or VPN layer before the offboarding date.
Revoke privileged group membership, local accounts, and application-specific roles separately from directory disablement.
Rotate secrets that the individual could have copied, stored, or used in automation.
Confirm that backup admin paths, break-glass accounts, and delegated access are not still available to that user.

That logic aligns with the broader control philosophy in the NIST Cybersecurity Framework 2.0, which treats access governance as a lifecycle activity rather than a single event. It also fits the operational emphasis of the Top 10 NHI Issues, because stale machine and service access often outlives the employee who created it.

These controls tend to break down in hybrid estates where local admin rights, ad hoc cloud roles, and long-lived secrets are scattered across teams because no single system has complete visibility.

Where the Offboarding Model Usually Breaks

Tighter offboarding often increases coordination overhead, because access must be removed across multiple owners, platforms, and identity types at once. The main tradeoff is speed versus completeness: fast shutdown reduces immediate exposure, but incomplete revocation leaves a usable back door behind.

One common edge case is shared or inherited access. If a departing employee used a team-owned credential, a service token, or a shared folder with weak ownership, disabling their directory account does not remove the underlying access path. Another is asynchronous revocation, where the front door is closed but downstream systems keep trusting cached sessions, replicated credentials, or stale authorisations for hours or days. Best practice is evolving toward explicit verification of each critical system rather than assuming central identity shutdown is authoritative everywhere.

Offboarding also changes when automation is involved. If a human user created secrets or delegated access for scripts, pipelines, or machine accounts, those non-human identities may continue operating after the person is gone. A useful reference point is The 2025 State of NHIs and Secrets in Cybersecurity, which reports that 91% of former employee tokens remain active after offboarding. That figure reinforces the operational reality that offboarding is usually incomplete when teams focus only on employee login shutdown.

Risk and Threat Considerations

The material risk is residual access. When offboarding stops at SSO or VPN shutdown, the former user may still have enough standing privilege to read, modify, delete, or export sensitive data through alternate paths. The same gap can also preserve access for an intruder who stole credentials before termination or who inherited a still-valid token after the employee left.

Failure mechanism: Organisations revoke the most visible authentication layer while leaving direct system credentials, role bindings, API keys, local accounts, and cached sessions untouched. Because these paths authenticate independently, the user or attacker can continue operating until each trust relationship is explicitly removed or rotated.

Impact: Sensitive files, production systems, cloud resources, and automation workflows remain exposed after the employment relationship ends. That can lead to unauthorised data access, destructive changes, service disruption, or delayed detection because the access still appears legitimate inside downstream systems.

Standards & Framework Alignment

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

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	5 — Account Management	Offboarding requires disabling and removing all user access, not just SSO or VPN.
	6 — Access Control Management	Residual permissions and direct access paths create offboarding exposure.
	3 — Data Protection	Stale access can expose sensitive files, secrets, and protected data after exit.
Recommendation — Revoke every account and entitlement tied to the departing user across all systems. Review and remove direct access paths, shared permissions, and privileged roles promptly. Rotate or protect sensitive data access paths that a former user could still reach.
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	Offboarding is a lifecycle access-control problem across identities and systems.
	PR.PS — Platform Security	Direct server, cloud, and admin access can persist outside SSO or VPN.
	DE.CM — Security Continuous Monitoring	Offboarding gaps are often only visible when logs show surviving access paths.
Recommendation — Remove access at each identity layer and verify no surviving authorisations remain. Harden and audit direct platform access so disabled SSO does not leave alternate entry points. Monitor for post-offboarding authentication and privileged activity across downstream systems.
NIST SP 800-63	5.2 — Lifecycle Management	Credential and authenticator lifecycle must end when the user leaves.
	7.2 — Reauthentication and Session Termination	Active sessions can remain usable after the main login is shut down.
	7.1 — Authenticator Binding	Access may remain through bound authenticators or tokens outside SSO.
Recommendation — Invalidate authenticators and associated credentials when access is no longer needed. Terminate sessions and require reauthentication where stale access could persist. Bind and revoke authenticators so departed users cannot reuse surviving credentials.

Practitioner Guidance

What to prioritise: Treat offboarding as an access inventory problem, not a single account-deletion task. The first systems to check are the ones that can directly change data or production state, because those create immediate harm even when SSO is already disabled.

What to verify: Confirm that every privileged path has a named owner, a revocation step, and a validation point. If you cannot prove that direct database access, cloud console roles, SSH keys, service tokens, and shared folders were removed, the offboarding is not complete.

Decision rule: If a departing person ever handled secrets, automation, or administrative access, require credential rotation and downstream access review even when the SSO record looks clean. Directory disablement is evidence of one control working, not evidence that exposure is gone.

Practitioner takeaway: Offboarding is only real when the former identity can no longer reach any system that still trusts it, including the non-obvious ones that never depended on SSO or VPN in the first place.