Problems & fixes · Identity and access

Why former employees keep access and how to close the gaps

Last updated 25 October 2026 · 2 sources listed · Reading time about 3 minutes

Short answer

Orphaned access usually survives because accounts are created outside central identity, ownership is unclear, and offboarding depends on manual steps across many tools. Fix it with a single authoritative trigger from HR, central sign-in for as many apps as possible, regular access reviews, and a reconciled list of accounts that bypass single sign-on, such as shared logins, API keys and personal-email registrations.

Who this is for: An IT or HR operations lead who has found that departed staff or contractors still have working accounts, or who wants to prevent that.

What to evaluate

Authoritative leaver trigger
Offboarding fails when notification of departures is late or informal.
How to check: Connect HR records to the identity system so a status change starts the process automatically.
Application inventory
You cannot remove access from tools you do not know exist.
How to check: Compare expense records, single sign-on logs and network data to find unmanaged applications.
Local accounts and shared credentials
These survive when the central account is disabled.
How to check: List applications with separate passwords, shared logins and API tokens, and assign owners.
Contractor and vendor accounts
Non-employees often sit outside the HR process.
How to check: Require a sponsor and an end date for every external account.
Data and device recovery
Access removal is incomplete if devices and data remain with the individual.
How to check: Include device return, mailbox and file ownership transfer in the checklist.
Periodic access reviews
Reviews catch what automation misses.
How to check: Ask managers to confirm access lists on a regular schedule and track completion.

Comparison

Gaps that leave access open
Gap	How it happens	Fix
Unmanaged application	Team signs up with a work email outside IT	Discovery and single sign-on enforcement
Shared password	Credential known to former staff	Vault, rotate and move to named accounts
Contractor without end date	No HR record	Sponsor and expiry for all external accounts
Active API token	Created by departed developer	Token inventory and owner reassignment
Delayed notification	HR informs IT late	Automated trigger from HR system

Decision worksheet

Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.

1. Have you checked each criterion?

Authoritative leaver trigger — Connect HR records to the identity system so a status change starts the process automatically.
Application inventory — Compare expense records, single sign-on logs and network data to find unmanaged applications.
Local accounts and shared credentials — List applications with separate passwords, shared logins and API tokens, and assign owners.
Contractor and vendor accounts — Require a sponsor and an end date for every external account.
Data and device recovery — Include device return, mailbox and file ownership transfer in the checklist.
Periodic access reviews — Ask managers to confirm access lists on a regular schedule and track completion.

0 of 6 criteria checked.

2. Compare options (0 = fails or unknown, 3 = meets it well)

Criterion	Option 1 name	Option 2 name	Option 3 name
Authoritative leaver trigger	Authoritative leaver trigger score for Option A	Authoritative leaver trigger score for Option B	Authoritative leaver trigger score for Option C
Application inventory	Application inventory score for Option A	Application inventory score for Option B	Application inventory score for Option C
Local accounts and shared credentials	Local accounts and shared credentials score for Option A	Local accounts and shared credentials score for Option B	Local accounts and shared credentials score for Option C
Contractor and vendor accounts	Contractor and vendor accounts score for Option A	Contractor and vendor accounts score for Option B	Contractor and vendor accounts score for Option C
Data and device recovery	Data and device recovery score for Option A	Data and device recovery score for Option B	Data and device recovery score for Option C
Periodic access reviews	Periodic access reviews score for Option A	Periodic access reviews score for Option B	Periodic access reviews score for Option C
Total (max 18)	0	0	0

Questions to ask before you commit

What event starts offboarding and who is notified automatically?
Which applications do not connect to central sign-in?
How are shared accounts and service credentials rotated at departures?
Who owns the departing person mailbox, files and delegated permissions?
How do we handle contractors whose contracts simply expire?
How quickly must access be removed for sensitive roles?
How do we verify that removal actually happened?

Typical trade-offs

Immediate disablement versus graceful transition

Upside: Immediate removal limits risk.
Downside: May lose business continuity if data ownership is not transferred first.

Automation versus manual checklist

Upside: Automation is consistent and fast.
Downside: Needs integration work and still misses unmanaged tools.

Deleting accounts versus suspending

Upside: Deletion removes liability and cost.
Downside: Suspension preserves data for legal and operational needs.

Common mistakes

Relying on a manager email to start offboarding; trigger from the HR system instead.
Disabling only the primary login; also revoke sessions, tokens and mobile device access.
Forgetting forwarding rules and delegated mailbox access; review and remove them.
Leaving former staff as owners of shared documents and automations; reassign ownership first.

Related questions

How quickly should access be removed?

For sensitive roles or involuntary departures, access should be revoked at or before the moment the person is told. For routine departures, align removal with the last working day, and plan any handover of data before then. Define timeframes by risk level and measure how often you meet them, so exceptions are visible. Whatever you decide, write the reasoning down, name who is accountable for the follow-up, and revisit the choice after a realistic trial period so that early assumptions are tested against what actually happens in practice.

How can we find applications nobody told IT about?

Combine several sources: single sign-on logs showing external logins, finance records for subscriptions, browser or network telemetry, and email sign-up confirmations. Ask departments to attest to the tools they use. Discovery is never perfect, so pair it with policies that require business use of company email domains to be routed through central identity. Whatever you decide, write the reasoning down, name who is accountable for the follow-up, and revisit the choice after a realistic trial period so that early assumptions are tested against what actually happens in practice.

What about former staff who still know shared passwords?

Rotate those credentials at departure, and better, replace shared logins with named accounts that can be individually revoked. Where sharing is unavoidable, store secrets in a vault, record who retrieves them and rotate automatically after use. Treat unrotated shared passwords as outstanding access even if the person account is closed. Whatever you decide, write the reasoning down, name who is accountable for the follow-up, and revisit the choice after a realistic trial period so that early assumptions are tested against what actually happens in practice.

Do access reviews really help?

Yes, when they are focused. Reviews of privileged and sensitive application access, performed by managers who actually understand the roles, tend to uncover accounts that automation missed. Keep lists short, show recent activity to help decisions, and follow up on non-responses so that reviews do not become rubber stamps. Whatever you decide, write the reasoning down, name who is accountable for the follow-up, and revisit the choice after a realistic trial period so that early assumptions are tested against what actually happens in practice.

Sources and further reading

These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.

10 Steps to Cyber Security — National Cyber Security Centre, retrieved 27 October 2026
Identity and Access Management — NIST, retrieved 27 October 2026

How to choose · Identity and access

How to choose a single sign-on and identity provider

Choose an identity provider by checking which of your applications support standard federation, how provisioning and deprovisioning work, what authentication methods and policies are available, and how the provider behaves when it fails. The directory you already run, the number of unsupported legacy apps, and your admin capacity shape the best fit more than feature lists do.

Comparison · Identity and access

Passkeys, authenticator apps, hardware keys and text message codes compared

Methods differ mainly in how resistant they are to phishing and in how easy they are to deploy and recover. Passkeys and hardware security keys bind sign-in to the genuine site and resist phishing. Authenticator app codes are a solid, widely supported middle option. Text message codes are better than a password alone but are exposed to interception and number takeover, so reserve them as a fallback.

Suitability · Identity and access

Does your organisation need privileged access management

Privileged access management becomes worthwhile when powerful accounts are numerous, shared, long-lived or poorly audited. It vaults credentials, issues time-limited access, and records sessions. Smaller environments may achieve much of the benefit with separate admin accounts, strong authentication and just-in-time role activation built into existing platforms before buying a dedicated product.

Problems & fixes · Cloud security

Common cloud misconfigurations and how to fix them

Most cloud exposure comes from a short list of recurring mistakes: publicly reachable storage, overly broad permissions, long-lived access keys, disabled logging, open administrative ports and unprotected secrets in code. Fix them by inventorying accounts, restricting identities, enabling audit logs, then using templates and guardrails so the same errors cannot return.

Requirements · Artificial intelligence

Security and governance requirements for workflow automation

Treat the platform as a privileged system. Require single sign-on and role separation, scoped service connections instead of personal logins, secret storage you can audit, restrictions on which data may flow through it, run-log retention limits, change review for important flows, and an inventory with named owners. Without these, automations become unmanaged paths around your normal controls.

Comparison · Network security

Traditional VPN vs zero trust network access for remote staff

A traditional remote-access VPN places a user's device on the internal network, so a compromised laptop can reach much more than it needs. Zero trust network access verifies user and device for each application and grants only that access. The second model limits lateral movement but needs good identity, device inventory and application mapping, so many organisations adopt it in stages.

Comparison · B2B software

Buy off-the-shelf software or build a custom tool

Buy when the process is common across companies, a mature product covers most of it, and speed matters. Build when the process is a source of competitive difference, existing products force awkward workarounds, and you can sustain engineering ownership over years. Hidden costs on both sides, integration and customisation for bought tools, maintenance and security for built ones, usually decide the outcome.

All Identity and access guides · All Cybersecurity and IT