Employee departures are one of the most consistently mishandled IT events in small and midsize businesses. Not because anyone is negligent — but because offboarding is treated as an HR process that happens to have some IT components, rather than a security-critical IT process that HR needs to coordinate with.
The result: ex-employees routinely retain access to business systems, email, cloud applications, and shared credentials long after their last day. Sometimes for weeks. Sometimes indefinitely. Most businesses only discover this when something goes wrong.
What "Access" Actually Means in a Modern SMB Environment
When a business thinks about revoking an employee's access, they usually think about disabling the Active Directory account or the Microsoft 365 login. That's the right starting point — but it's a fraction of the actual access surface that needs to be addressed.
A typical employee at a 25-person professional services firm might have active credentials or sessions across:
- Microsoft 365 — email, Teams, SharePoint, OneDrive, shared mailboxes
- Line-of-business applications — practice management, CRM, accounting, project tools
- Cloud services — Dropbox, Google Drive, DocuSign, Adobe, Zoom
- Client-facing portals — secure document sharing, client communication platforms
- Remote access — VPN credentials, RDP, remote support tools
- Password managers — shared vaults with access to team credentials
- Social media and marketing accounts
- Third-party integrations — apps connected to M365 via OAuth
- Physical access systems — building key fobs, alarm codes
Disabling the M365 account stops some of these. It doesn't stop the ones that authenticated independently and cached a token. It doesn't revoke the OAuth apps that connected before the account was disabled. It doesn't remove the employee from shared password manager vaults. It doesn't change the alarm code they memorized.
The Microsoft 365 Access Problem Is Bigger Than You Think
Disabling an M365 account is necessary — but several things survive account disablement that most IT teams don't address:
Active sessions and refresh tokens
When a user authenticates to Microsoft 365, they receive an access token (short-lived, typically 1 hour) and a refresh token (long-lived, up to 90 days by default). Disabling the account invalidates new authentication attempts — but active sessions with valid refresh tokens may continue to function until those tokens expire.
If you disable an account and don't explicitly revoke all active sessions, a determined ex-employee with an active session on a personal device may retain access for hours or days. The fix is to disable the account AND revoke all refresh tokens via the Microsoft Entra admin center or PowerShell — both steps together, not just one.
Shared mailboxes and distribution lists
Many employees have access to shared mailboxes — info@, support@, billing@ — that are separate from their personal mailbox. Disabling their account doesn't automatically remove them from shared mailbox access. These need to be audited and removed explicitly.
OneDrive data retention
By default, when an M365 account is deleted, the associated OneDrive is retained for 30 days before permanent deletion. If the departing employee had business-critical files stored only in their personal OneDrive — not in SharePoint or Teams — those files need to be migrated before the account is fully removed.
OAuth-connected applications
Many third-party applications connect to Microsoft 365 via OAuth — granting them ongoing access to email, calendar, files, or contacts on the user's behalf. These OAuth grants persist after account disablement unless explicitly revoked. An audit of connected apps in the Microsoft Entra portal should be part of every offboarding.
The Shared Credential Problem
Shared credentials are the offboarding gap that creates the most long-term exposure — and the one that's hardest to close completely.
In most SMBs, some credentials are shared. The company Instagram password. The billing portal login. The vendor account that doesn't support individual user accounts. The admin login for the office printer. These credentials exist in someone's head, in a sticky note, in a personal password manager, or in a shared spreadsheet.
When an employee who knew those credentials leaves — especially under difficult circumstances — there is no technical control that prevents them from using credentials they already have memorized or saved. The only remedy is changing every shared credential the departing employee had access to. Every one. Before their last day if the departure is hostile, on the day if it's planned.
This is one of the strongest arguments for implementing a business password manager — tools like 1Password Teams or LastPass Business — where shared credentials live in vaults that are controlled by the business. When an employee is removed from the vault, their access to those credentials ends. You change the vault membership, not every individual password.
The SaaS Sprawl Problem
Most businesses are running more SaaS applications than they realize, and most of those applications have user accounts that were created independently of the Microsoft 365 identity system.
Disabling the M365 account does nothing to the user's account in Salesforce, HubSpot, Zoom, Slack, Asana, DocuSign, or any other application that has its own authentication system. These need to be deprovisioned individually — which requires knowing which applications the employee had access to in the first place.
This is where the absence of a SaaS inventory becomes a real problem. If you don't have a documented list of which applications your employees use and which accounts they have, offboarding becomes a guessing exercise. Huntress and Liongard — tools we use for managed clients — provide visibility into installed software and cloud application usage that makes this inventory possible.
What a Complete Offboarding Checklist Looks Like
An effective IT offboarding process addresses the following, in roughly this order:
Before the employee's last day (planned departures)
- Identify all systems and applications the employee has access to
- Identify all shared credentials the employee knows
- Migrate any business-critical data from personal storage (OneDrive, local drives) to shared locations
- Set up email forwarding or auto-reply as appropriate
- Notify relevant clients or vendors of the transition
On the last day
- Disable Microsoft 365 account AND revoke all active sessions and refresh tokens
- Remove from all shared mailboxes, distribution lists, and Teams channels
- Disable VPN access and revoke any remote access credentials
- Remove from shared password manager vaults
- Change all shared credentials the employee had access to
- Disable or reassign accounts in line-of-business applications
- Revoke physical access — key fobs, alarm codes, building access
- Recover company-owned devices
Within the following week
- Audit OAuth-connected apps on the disabled account and revoke
- Complete SaaS application deprovision across all identified platforms
- Transfer or archive email and files per your retention policy
- Remove from cyber insurance and vendor portals if applicable
- Confirm M365 license has been reassigned or deallocated
- Document the offboarding completion for your records
The Hostile Departure Scenario
Most offboardings are planned and professional. But some aren't — and the ones that aren't are the ones where incomplete offboarding creates the most acute risk.
A terminated employee who retains access to client data, email, or business systems is a material business risk. We've seen situations where a former employee continued reading company email for weeks after termination, accessed client files after leaving to take them to a competitor, and in one case, disabled security monitoring on systems they still had admin access to.
For hostile or involuntary terminations, the offboarding sequence needs to happen immediately — ideally before the conversation with the employee, or simultaneously. This requires having a documented process ready to execute on short notice, not figuring it out in the moment.
The Practical Takeaway
If you don't have a documented, tested IT offboarding checklist, the time to build one is before you need it — not during a termination where the priority is getting the employee out of the building. For managed clients, we run through this checklist on every departure. For businesses that want a starting point, the checklist above is a workable foundation — adapt it to your specific application stack and run through it on your next offboarding to find the gaps in your current process.