Offboarding is where IT security gets sloppy. Not because teams don't care, but because the process is always owned by HR, always reactive, and always slightly too slow. The employee's last day arrives before IT has revoked a single credential. The laptop sits in a box in a cupboard for two months. The Salesforce account is still active six weeks after departure. This is not a rare edge case. It is the norm.
According to a 2024 report by Beyond Identity, 83% of former employees retain access to at least one company application after leaving. Nearly a third still have active credentials 30 days post-departure. These aren't hypotheticals. They're open doors.
Why offboarding is a security event, not an HR event
When an employee resigns, the risk profile of their credentials changes immediately. A frustrated departing employee with access to customer data, source code, or financial systems is a threat vector. Even a completely amicable departure creates risk: forwarded emails, synced files, cached credentials on personal devices, and shared accounts that nobody knew about.
The problem is compounded by the typical timeline. HR notifies IT on the last day, or occasionally the day before. IT has a few hours to work through an unwritten process across a dozen different systems. Something gets missed. Usually several things.
The window between notice and departure, typically two to four weeks, is also the highest-risk period. This is when data exfiltration is most likely to occur. Large file downloads, emails to personal accounts, sharing of documents that weren't previously shared. If you're not monitoring for this, you won't see it until after the fact, if you see it at all.
"83% of former employees retain access to at least one company application after leaving. That's not a security posture. That's an open door with a welcome mat."
The IT offboarding checklist
This is the sequence that matters. Order is important: identity first, then data, then hardware, then audit.
- Receive formal notification from HR as soon as resignation is accepted, not on last day
- Set access revocation date in identity provider for end of last working day
- Disable SSO account simultaneously across all connected apps (not sequentially)
- Revoke MFA tokens and hardware security keys
- Transfer email ownership and set up auto-reply, do not keep account active
- Review and revoke all OAuth tokens and API keys associated with the account
- Remove from all Slack workspaces, GitHub organizations, and collaboration tools
- Revoke VPN certificates and remote access credentials
- Disable any service accounts the employee owned personally
- Recover company hardware: laptop, phone, accessories, security keys
- Wipe device remotely via MDM if physical return is delayed
- Check for personal device enrollment in MDM and remove company profiles
- Review cloud storage for large recent exports or unusual sharing activity
- Transfer data ownership of shared drives, documents, and repositories
- Update asset register to reflect hardware return and status
- Document completion of each step with timestamp for audit trail
How to automate the offboarding workflow
The manual version of this list requires someone to log in to every system, one by one, and make changes in the right order. That takes hours, and under time pressure it gets cut short. The automated version triggers from a single event: the HR system marks the employee as departing.
From that trigger, the IT platform queues the revocation sequence, schedules it for the correct datetime, and executes it automatically. Apps connected via SSO are deprovisioned simultaneously. The MDM marks the device for remote wipe if it isn't returned by the required date. A completion report is generated and stored for audit purposes.
The IT team still needs to handle the physical hardware recovery and review the activity logs. But the fifteen-tab sprint through every SaaS tool at 5pm on someone's last day? That's gone. The process runs on schedule, without gaps, regardless of how chaotic the week is.
Companies that treat offboarding as a security event, rather than a paperwork exercise, build it into the same platform that handles onboarding. The same identity infrastructure that provisions access on day one should revoke it on the last day. That's not complicated. It's just a decision to take it seriously.