Secure Offboarding Process: 8 Steps to Close Every Access Gap

Offboarding is where security quietly breaks. Nobody notices the account that stayed open, the shared password that never changed, or the API token still running under a former employee's name, until something goes wrong or an auditor asks.

Collecting a laptop and a badge is the easy part. The harder part is removing one person from every app, token, and shared password they used, including accounts IT never provisioned.

This guide walks through a secure offboarding process step by step: what to revoke, in what order, who owns each part, and how to automate employee offboarding so nothing depends on someone remembering.

What is a secure offboarding process?

A secure offboarding process is a repeatable set of steps that removes a departing person's access to every system, account, credential, and device by their last day, transfers the data they own, and leaves an audit record proving each step happened.

General HR offboarding covers the exit interview, final pay, and benefits. Secure offboarding covers access, data, credentials, and devices. It applies to employees and contractors, and to the non-human identities they created along the way: service accounts, integrations, bots, and API keys that keep running after the person is gone.

Why offboarding is a security risk

With SSO in place, it's tempting to assume that disabling one account closes everything. It doesn't. The gaps show up in the same places:

• Apps outside SSO. Teams sign up for tools with a work email or a company card. Those accounts never pass through your identity provider, so disabling the IdP account leaves them open.
• Shared passwords. Social media logins, vendor portals, and team accounts often share one credential. If nobody rotates it, the former employee still knows it.
• OAuth grants and API tokens. Integrations a person authorized and tokens they generated are tied to that person, not to the team. Some keep working after the account is disabled.
• Admin rights. An admin can create accounts, change settings, and export data. A missed admin account is far more dangerous than a missed standard seat.
• Data copied before departure. Files synced to a personal device or shared through external links don't disappear when the account closes.

Compliance raises the stakes. SOC 2 and ISO 27001 auditors check that terminated users lose access promptly, and they ask for evidence. A ticket marked "done" with no proof for each app is a likely audit finding.

IT leaders know this. In a Torii survey, 76% of IT leaders agreed or strongly agreed that employee offboarding is a significant security threat, and 67% said accidental breaches, not malicious ones, were the bigger concern.

Source: Torii survey report, Offboarding Security for a Remote Workforce (December 2021).

That second finding shapes the process. The typical risk is a forgotten login or token, so the fix is a thorough, verified checklist.

The scale makes manual cleanup hard. Employees typically use at least 30 SaaS accounts, and every one of them should be closed when the person leaves.

Source: Torii internal data, as reported in the IT checklist for employee offboarding (2023).

The secure offboarding process, step by step

These eight steps are ordered to close the biggest gaps first. Use them as a template, then adjust ownership and timing to fit your stack.

Step 1: Start every offboarding from one trigger

Use your HR system as the trigger. When BambooHR, Workday, or HiBob records a termination date, that record is the source of truth for IT, Security, and app owners. Slack messages and hallway mentions get missed, so they shouldn't start anything.

Treat planned and involuntary exits differently. For a resignation with notice, schedule revocation for the end of the last working day, so the person can finish handover work and lose access when they're done. For an involuntary exit, revoke access before or during the conversation, never after.

Decide in advance who gets notified and when: the manager, IT, Security, and any app owners who manage accounts IT can't reach. For a broader view of ownership and timing, see the SaaS offboarding process playbook.

Step 2: Inventory every app the person used

You can't revoke access you don't know about. Before the last day, list every app and account the person used. Start with their assignments in Okta, Microsoft Entra ID, or Google Workspace, then look beyond them.

Look for apps outside SSO: tools signed up for with a work email, free tiers, browser-based utilities, and AI tools such as chat assistants and meeting note-takers that may hold transcripts or customer data. Check expense reports and corporate card statements for subscriptions the person paid for directly. These are classic shadow IT, and they're the accounts most likely to survive an offboarding.

For each app, note whether the person is an admin, whether they own shared workspaces or records, and who the app owner is. Every later step works from this list.

Step 3: Cut identity access first

Disabling the account in your identity provider closes the most doors in a single action. Then finish the job:

• End active sessions and revoke refresh tokens in Okta, Entra ID, or Google Workspace.
• Reset or remove registered MFA devices, so a retained phone or security key can't be used.
• Remove the user from groups, roles, and email distribution lists.
• Block sign-in to email and remove mobile mail profiles.

One detail catches teams out: disabling SSO doesn't end sessions already open inside each app, and it does nothing for apps where the person also has a local username and password. Steps 4 and 5 cover those.

Step 4: Deprovision app-native accounts and reclaim licenses

Many apps keep their own user directory, even with SSO enabled. Design tools, analytics platforms, finance systems, and developer tools often allow local logins or keep accounts active after SSO access is removed. Each one needs to be deprovisioned in its own admin console, or through SCIM where it's configured.

Before you delete anything, transfer ownership. Reassign records, dashboards, workspaces, projects, and scheduled reports to the manager or a named successor. Deleting first can wipe data the team still needs, and some apps make recovery hard or impossible.

Once ownership has moved, remove the account and reclaim the license. A deactivated user often still holds a paid seat until someone removes it, so reclaiming it closes the access gap and the cost leak at once. The full list of per-app tasks is in our guide to employee offboarding tasks for SaaS.

Step 5: Rotate shared credentials, API keys, and OAuth grants

Credentials that aren't tied to a personal login are the easiest to forget. Review anything the departing person knew or created:

• Shared passwords. Rotate every credential in the shared vaults they could open in 1Password or a similar password manager, then remove them from those vaults.
• API keys and personal access tokens. Revoke keys they generated in cloud consoles, code repositories, and SaaS admin panels, and reissue them under a service owner.
• OAuth grants. Review third-party apps they authorized against company data, then revoke or reassign those grants.
• Service accounts and integrations. Find automations, bots, and integrations running under their identity and move them to an owned service account.

These non-human identities often outlive the employee who set them up. If an integration breaks when you revoke a token, it was tied to the wrong identity.

Step 6: Transfer and preserve data

Access ends on the last day, but the business still needs the person's data. Plan the handoff before anything is deleted:

• Set up mailbox forwarding or delegate access to the manager for a defined period, then convert or archive the mailbox.
• Transfer ownership of Google Drive or OneDrive files and shared folders to the manager or successor.
• Apply a legal hold where your retention policy or a pending dispute requires it.
• Revoke external sharing links the person created, so files shared with personal accounts or outside parties stop being reachable.

External links are easy to miss. A file shared with "anyone with the link" stays reachable after ownership moves, unless you revoke the link or tighten its sharing settings.

Step 7: Recover devices and close remote access

Use your MDM, such as Jamf for Macs or Microsoft Intune for Windows and mobile, to lock company devices on the last day, then wipe them once they're returned (or remotely, if they don't come back). For remote employees, send a prepaid return kit and set a deadline.

Next, close every remote path into the network: VPN accounts, remote desktop tools, jump hosts, and Wi-Fi certificates. Deactivate physical badges and building access, including any visitor or parking systems that run separately.

If the person used a personal phone or laptop for work email or chat, remove company data through your MDM's app protection policies or work profile, and sign them out of company apps.

Step 8: Verify, document, and audit

A ticked checklist proves little on its own. For each app on the step 2 inventory, confirm the account is deactivated or deleted, not just marked complete in a ticket.

Check your IdP and app sign-in logs for activity after the termination date. A sign-in from a former employee points to a missed account or an unrotated shared credential. Follow up on either.

Keep an audit trail per app: who removed access, when, and how. Auditors ask for exactly this record. Thirty days later, review a sample of recent offboardings to catch slow app owners, re-enabled accounts, and licenses that were never reclaimed.

Offboarding security protocols for high-risk exits

Some departures need stricter handling. Agree on these protocols in advance so sensitive exits are handled the same way every time.

Involuntary terminations

HR, IT, and Security coordinate timing so access is revoked before or during the conversation. Prepare the app inventory ahead of time, queue the revocations, and limit who knows the timing. Collect devices on the spot where possible, or lock them remotely.

Admins and privileged users

Privileged exits get extra review. Rotate break-glass and emergency access accounts they knew. Remove admin roles in every SaaS admin console, not only in the IdP. Revoke access to code repositories such as GitHub or GitLab, and to cloud consoles in AWS, Azure, or Google Cloud, including access keys and SSH keys. Check for accounts they may have created for themselves.

Contractors and agencies

Contractors often sit outside the HR system, so there's no automatic trigger. Give every contractor account an end date when it's created, track contractors in one place, and require the sponsoring manager to confirm the offboarding. Rotate an agency's shared logins when the engagement ends, or when any agency staff member who knew them moves on.

Employees leaving for a competitor

When someone resigns to join a competitor, bring in Security and Legal early. Review recent large downloads, exports, new email forwarding rules, and files shared to personal accounts. Consider removing access to sensitive systems at the start of the notice period rather than the end. Document what you reviewed, even if you find nothing.

How to automatically revoke app access during offboarding

Manual offboarding breaks in familiar ways. The checklist lives in a spreadsheet. Requests go out as Slack pings that get buried. App owners finish their part days later, or never. Apps nobody knew about never make the list, so they never get closed.

Automation removes the steps that depend on someone remembering. Here's how Torii handles it.

Discover the apps and accounts. Torii discovers the apps and accounts in use across your company, including shadow IT, through integrations, SSO, and its browser extension. That gives you the step 2 inventory without building it by hand.

Trigger offboarding from a source of truth. You pick a source of truth that marks each user as current or past: an HR system such as BambooHR or HiBob, or an identity provider such as Google Workspace, Okta, or Entra ID. When a user is marked as past, a "User left" trigger starts the offboarding workflow automatically. You can also schedule offboarding for the last working day, for example at 5 PM.

Real-time offboarding is available for Google Workspace, Okta, and BambooHR (BambooHR is in beta). For other sources, workflows start after the source-of-truth sync. Read more about real-time offboarding for Okta and Google Workspace.

Choose a method for each app.

• Automatic offboarding for integrated apps, or a custom HTTP action for any app with an API.
• Delegate offboarding through an email or Slack request to the app owner, or a Jira ticket whose status Torii monitors.
• Ignore for apps your IdP already deprovisions, so they don't create duplicate work.

Torii automates removal where an integration or API exists and routes the rest to the app owner as a tracked task. Every offboarding also has an audit log per app on the user's page, which gives you the evidence step 8 calls for.

To see it in practice, explore Torii's identity lifecycle automation, or start with the IT checklist for employee offboarding.