Employee Offboarding Is Where Access Control Actually Fails
Most access control programs are built around getting people in. New starters get a laptop, an identity, a set of groups and a list of applications on day one, usually through a checklist that HR and IT have tuned for years. Getting people out gets far less attention. The result is predictable: former employees, contractors and interns who still have working access weeks or months after they left, to systems nobody remembered they had.
This isn’t a rare failure. Ask any IT team doing an access review for the first time how many active accounts belong to people no longer on the payroll, and the honest answer is usually uncomfortable. Each one is an unmonitored door. Some are harmless. Some belong to people who left angry. And all of them are useful to an attacker who has bought or phished a password, because nobody notices strange activity on an account nobody is supposed to be using.
Why it breaks
The core problem is that the trigger for offboarding often never reaches IT in time. HR records a leaving date, but the ticket goes to the service desk late, or not at all, especially for contractors who were never in the HR system in the first place. Managers forget. Leavers on garden leave keep access by design and then nobody turns it off when the notice period ends.
The second problem is that the identity provider isn’t the whole picture. Disabling the directory account and the single sign-on login covers the applications connected to it. It doesn’t cover the SaaS tools a department bought on a card and set up with local logins, shared admin accounts on network gear, personal access tokens and API keys created by developers, SSH keys on servers, accounts in third-party portals for suppliers and banks, or mailbox delegation and file shares that still forward data to someone. The SaaS sprawl that finance can’t see is the same sprawl that offboarding misses.
The third problem is devices. A laptop that doesn’t come back still holds cached credentials, synced files and possibly a working VPN profile. A phone enrolled under a BYOD policy may keep corporate mail until someone wipes the work profile.
What a working process looks like
Make HR the source of truth and automate from it. When a leaving date is entered, the identity system should schedule account disablement for the end of the last working day, without waiting for a ticket. Contractors need the same treatment, which means they need records with end dates in some system that drives access, even if it isn’t the HR platform.
Disable first, delete later. Disabled accounts preserve mailboxes, files and audit history for handover and legal holds, and can be deleted on a retention schedule. Deleting on day one loses data and invites the scramble to restore it.
Revoke sessions, not just passwords. Disabling an account doesn’t always end active sessions and refresh tokens in cloud applications. Most identity providers have a sign-out-everywhere action; make it part of the runbook. Rotate any shared credentials the leaver knew, starting with privileged and break-glass accounts.
Keep an application inventory with owners, and include the apps that aren’t behind single sign-on. For each one, record who can remove a user and how. The offboarding checklist then becomes a list of named actions with named owners, not a hope that IT remembers. A hardware asset register does the same job for devices, so the service desk knows what to collect.
Run access reviews on a schedule. Quarterly reviews of privileged access and twice-yearly reviews of everything else catch what the process missed. Compare active accounts in each important system against the current staff and contractor list. Any account without a match gets disabled until an owner claims it.
Measuring it
Two numbers tell you whether offboarding works. The first is time to disable: hours between the last working day and the account being disabled across the main systems. The target is same day. The second is the orphan count found in each access review. If that number isn’t falling, the process is leaking somewhere, usually in the apps outside single sign-on or in contractor records. Fix the trigger before buying another tool. Zero trust starts with knowing who should still be trusted at all.