Identity
Offboarding is a security control, not an HR task
Why the leaver process belongs to security, what makes it genuinely hard, and what it looks like when you treat it as a control instead of housekeeping.
When someone leaves, the leaver ticket usually lands in a queue as an errand. Disable the mailbox, reclaim the laptop, tick the box. It sits with HR or a service desk, gets done when someone gets to it, and nobody thinks of it as security work. That framing is the whole vulnerability.
An enabled account after its owner has gone is a live credential with nobody behind it. It still has valid access, it still passes every authentication check, and there is no longer a person who would notice it being used. It is the exact account nobody disabled that turns up in the write-up of almost every incident. Slow or partial offboarding is not an administrative loose end. It is a standing hole in the estate that widens with every leaver.
Why it is harder than "disable the account"
Offboarding looks like one action and is really many. A person's access sprawls well past their login: the Entra account, the Microsoft 365 licences, the group memberships, the ERP and finance roles, the SharePoint sites, the shared mailboxes, the app-level permissions, and the security groups that grant things indirectly. Disabling the account is not the same as removing what that account could reach. Kill the login and leave the group memberships, and you have closed the front door while leaving a set of keys in circulation.
It also crosses boundaries. The access lives in systems owned by different teams, provisioned in different regions, each with its own idea of how urgent this is. The failure mode is not usually a dramatic one. It is the account that was disabled in one system and quietly left active in another.
What it looks like as a control
Treating offboarding as a security control, rather than a chore, changes how it is built:
- It fires on approval, not on memory. The moment a leaver is approved, the process runs. Nothing waits for someone to remember, because "someone will get to it" is exactly how the gap opens.
- It is complete and cross-system. One motion disables the account across Entra, Microsoft 365 and the ERP, and surfaces the indirect access, the group memberships that would otherwise outlive the account, so they can be dealt with rather than forgotten.
- It is auditable. Every action is logged and attributed to the verified approver, never to a name pulled from a form. If you cannot say who offboarded whom and when, the audit trail can be rewritten to blame anyone.
- Destructive steps are deliberate. They default to off and are opted into per region, because "revoke everything everywhere, instantly" has its own failure modes: shared resources that break, workflows the leaver happened to own. Fast is not the same as safe.
- There is a safety net. A catch-up pass re-checks approved leavers whose automation never actually ran, because the dangerous case is not the offboard that failed loudly. It is the one that silently did not happen.
HR owns the decision that someone is leaving. Security owns what that decision means for access. Those are not the same job, and the gap between them is where the standing credentials live.
The reframe
When offboarding is a pipeline that triggers on approval and closes every door in one motion, "who still has access, and why" stops being a question you have to remember to ask. The answer becomes a property of the system rather than a task on a list. This is the same failure as the endpoint nobody put a check on, seen from the other side: access that outlives the reason it was granted. The fix is the same shape too. Make the safe thing automatic, make the destructive thing deliberate, and never trust that a human will remember the step that matters most.