IT Offboarding Checklist 2026: Forgotten App Access, OAuth Grants and API Keys (Free Template)

When someone leaves, the HR checklist covers the laptop, the badge and the last payslip. IT disables the email account and calls it done. What usually survives is everything that was never a password: the OAuth grant a person approved for a reporting tool, the API key pasted into a script, the personal access token in a CI pipeline, the Zapier automation running under their name, and the shared admin passwords they read a hundred times.

This checklist focuses on that forgotten layer. You can download the template and use it as-is for every departure.

The short answer

A complete IT offboarding checklist has three layers: the identity (SSO account, sessions, MFA), the delegated access (OAuth grants, API keys, tokens, integrations), and the shared secrets (passwords the person could see). Most teams handle only the first. The second and third are where former employees, or attackers who stole their credentials, keep access for months.

Why "disable the account" is not enough: the October 2026 ConnectWise case

On 16 October 2026, ConnectWise published an advisory about unauthorized access to application identities connected to its Cloud Backup service (formerly SkyKick). The company disabled seven application identities at 07:00 UTC on 17 October and revoked certificates for the affected connections. Even then, its own advisory warned that "previously issued access tokens may remain usable until they expire or are otherwise invalidated."

That sentence is the whole problem of offboarding in one line. Locking the front door does not collect the keys already handed out. ConnectWise's recommended customer actions read like an offboarding checklist: review application credentials and federation trusts, consent grants and recent policy changes, check for unauthorized mailbox forwarding and inbox rules, review sign-ins from the start of the incident window, and do not delete the application as the first response, so configuration and evidence are preserved.

A departing employee is the same situation on a smaller scale: one identity, with delegated access spread across tools you may not even know about. (ConnectWise trust advisories, read on 18 October 2026.)

Download the free template

The template is a CSV file that opens directly in Excel, Google Sheets, LibreOffice or Numbers. Each row is one action, with the phase, an owner, a deadline relative to the last day, how to verify it, and columns to tick and date it.

Download the IT offboarding checklist template (CSV)

How to use it: duplicate the file for each departure, delete the rows for tools you do not use, add a row for each tool listed in your app inventory, and keep the completed file with the HR record. A completed and dated checklist is also what an auditor will ask to see.

The checklist, phase by phase

Before the last day: build the inventory

You cannot revoke what you have not listed. Start this as soon as the departure is known.

• List every app the person uses. Your SSO portal shows the apps connected to the identity provider. Add the tools outside SSO: billing, the social media accounts, the domain registrar, vendor portals, anything signed up for with a work email.
• List what they own, not only what they use. Shared drives and files, automations (Zapier, Make, Power Automate), scheduled scripts, bots, webhooks, DNS and domain records, cloud resources. Ownership is what breaks when the account is deleted.
• List the secrets they know. Every shared password, Wi-Fi key, alarm or door code, and break-glass account they had access to.
• Identify admin rights. An admin leaving is a different risk level: they may have created API keys, app registrations or service accounts nobody else knows about.

Last day: close the identity

• Disable (suspend) the SSO or directory account at the agreed time, rather than deleting it.
• Revoke active sessions. In Microsoft Entra ID, the user page has a "Revoke sessions" action; in Google Workspace, the user page in the Admin console lets you sign the user out of active sessions. Disabling alone does not always end a session that is already open.
• Remove registered MFA methods and passkeys, and reset the password so a cached password cannot be reused if the account is ever re-enabled.
• Remove from groups and distribution lists, VPN and remote access, and mobile device management so company data can be wiped from personal phones.
• Recover devices and hardware security keys.

Applications and OAuth grants: the delegated access

OAuth is how a user lets one app act in another ("Allow this tool to read your Google Drive"). Those grants are not passwords, so a password reset does not necessarily touch them. Revoke them explicitly.

• Google Workspace: on the user's page in the Admin console, the security section lists connected applications with the access each was granted. Remove them. The domain-wide view is under Security, API controls.
• Microsoft 365 / Entra ID: check Enterprise applications for consents the user granted, and App registrations for any application the user owns. An app registration owned by a leaver often holds a client secret they could still use.
• Slack, Teams, Notion and similar tools: review apps, bots and webhooks the person installed, and reassign or reinstall the ones you keep under a team-owned account.
• Mailbox: check forwarding rules, inbox rules and delegated access. A forwarding rule to a personal address is one of the most common ways data keeps leaving after a departure.

API keys, tokens and SSH keys

These are the credentials that survive the longest because they are designed to work without anyone logging in.

• Cloud providers: in AWS IAM, list the user's access keys, deactivate them, check that nothing breaks, then delete them. The IAM credential report shows when each key was last used. Apply the same logic to service account keys elsewhere.
• GitHub and GitLab: remove the person from the organization, and review deploy keys and CI secrets on the repositories they maintained. Deploy keys and repository secrets belong to the repository, not to the person, so they stay valid after the person is removed.
• SaaS API keys: many tools (payment, email sending, analytics, CRM) let users create API keys in their settings. Find the ones the leaver created, rotate them, and recreate them under a service account.
• Secrets the person knew: any key, token or connection string they could read in a config file, a ticket or a chat message has to be rotated, even if it is technically owned by the company.

Shared passwords and the password vault

This is the layer nobody can revoke: you can remove someone from a shared vault, but not from their memory or from an export they made.

• Remove the person from shared vaults and collections in your password manager, and transfer ownership of items they created.
• Rotate the shared credentials they could read, starting with the most sensitive: admin consoles, finance and banking, domain and DNS, social media accounts, break-glass accounts.
• Use activity logs to narrow the list. If your password manager records which items each member opened, you rotate what they actually viewed instead of every shared password. Without logs, assume they saw everything they had access to. Our guide to sharing passwords securely explains why chat and email are the worst places for these secrets.

After the departure: the 30-day review

• Review sign-in logs of the disabled account and of the shared accounts for at least 30 days. Successful sign-ins after the last day are a red flag.
• Check that integrations still work after keys were rotated: a broken nightly sync is better found on day 2 than on day 30.
• Delete the account only after ownership transfers are confirmed and your retention period has passed.
• Update the inventory with anything you discovered during this departure, so the next one is faster.

Where to look: forgotten access by platform

Common mistakes

• Deleting the account on day one. Files, flows and integrations owned by the account can disappear or stop with it, and the logs you need go too. Suspend first.
• Treating the password reset as the end. OAuth grants, API keys and personal tokens do not depend on the password in many tools.
• Forgetting the tools outside SSO. Social media, the registrar and small SaaS tools signed up for with a credit card are rarely in the identity provider.
• Rotating nothing because "we trust them". Offboarding is not about trust: the former employee's personal devices and accounts can be compromised later, and every secret they still know becomes the attacker's.
• No owner for the checklist. HR, IT and the manager each assume another one did it. Put a name on every row.

Choosing tools that make offboarding faster

The fastest offboarding is the one where access was centralized from the start: apps behind SSO, provisioning through SCIM so that disabling the identity removes the user everywhere, and shared credentials kept in a business password manager rather than in a spreadsheet or chat history. If you are comparing options, our best password manager for business guide covers admin features and pricing, and the Bitwarden SCIM provisioning guide shows what automated deprovisioning looks like in practice. For the identity layer itself, see what single sign-on is and where it stops.