How to Offboard an Employee Immediately in Google Workspace

By Patronum

November 05, 2026

Read Time: 6 mins

How to Offboard an Employee Immediately in Google Workspace image

Act now, monitor next, hand over later
Why does the order matter?
The containment steps
Requested, pending or completed?
What comes after containment?
How does Emergency Offboard work in Patronum?
Verification checklist
Sources

To offboard an employee immediately in Google Workspace, start containment straight away: end any third-party SSO session, reset their password and sign-in cookies, revoke app passwords, connected apps and recovery details, request a wipe of the work account on their devices, then suspend the account. Session termination and device wipes can remain pending after these admin actions, so record what you requested and check later what has completed. Moving files, groups and mail comes after containment.

This page is for an involuntary or high-risk exit. For planned departures, see our Google Workspace offboarding process. If you use Patronum, its Emergency Offboard action is covered below.

Act now, monitor next, hand over later

Act now (back to back)	Monitor next	Hand over later
End the IdP session, reset password and sign-in cookies, revoke app passwords, connected apps, security keys and recovery details, replace backup codes, request device wipes, suspend	Wipes still showing Approved or Wiping, open Gmail sessions, the mail route, the preservation decision	Drive, calendars and groups, auto-reply, end state of the account, license

Don’t hold up containment for a mail decision or a wipe to finish.

Why does the order matter?

Resetting sign-in cookies “does not sign them out of apps, such as Gmail and Google Drive for desktop” (Google). Removing a connected app’s access “doesn’t prevent a user from using the app in the future,” and access returns once they sign in again (Google). And a third-party SSO session “may still allow access to their Google Account after resetting their sign-in cookies.” So start at your identity provider and work inward.

The containment steps

Work from the user’s page in the Admin console: Menu > Directory > Users, then click the person’s name. Most steps live under Security on that page.

End the SSO session at your identity provider. If people sign in to Google through Okta, Microsoft Entra ID or another IdP, end the session and block the user there first. Google says to “terminate their SSO session before resetting their Google sign-in cookies.” If Google is your only sign-in, skip this step.
Reset the password and sign-in cookies. Use Reset password and let Google generate a random one; Google notes this “also revokes some OAuth 2.0 tokens,” though not all (Google). Then Security > Sign-in cookies > Reset to sign the user out of browsers and mobile devices.
Revoke what the password reset misses. Revoke app passwords, remove each app under Connected applications and revoke security keys. Remove the recovery email and phone so the person can’t use them to recover the account.
Replace the 2-Step Verification backup codes. Generate a new set: “The old set of backup codes automatically become inactive.” Don’t hand the new set to anyone.
Request a wipe of the work account. Open Managed devices, then More > Wipe Account for a personal phone, or Wipe Device for a lost company device (Google). Wipe Account isn’t always partial: on company-owned Android devices, personal Android devices set to work-only and supervised company-owned iOS devices, it resets the device and removes personal data too. For computers using Fundamental management or GCPW, sign the user out under Devices > Overview > Endpoints. Don’t wait for the wipe to finish.
Suspend the account. Open More options on the user and choose Suspend user. Data is kept, “New email and calendar invitations are blocked” (Google), and suspending “automatically resets their sign-in cookies” (Google).
Reroute incoming mail if you need to. If customers or suppliers still email this person, add a recipient address map that redirects their mail to a colleague or a dedicated account. Google says “Changes can take up to 24 hours” (Google).
Confirm whether data must be preserved. Ask the legal or records owner for the case whether a hold is required. If it is, and the user has a Vault license, add the account to a hold in a Vault matter. Holds “never expire,” and an admin can’t delete an account while its data is on hold (Google). A hold also blocks Google’s admin Drive transfer tool, which needs a source user “Not on litigation hold for any service” (Google), so tell whoever plans the handover.

Record the time of each request; several complete later.

Requested, pending or completed?

A button press is a request. Track each action as requested, pending or completed, and give every pending item an owner.

Action	Completed when	Can stay pending because	What it doesn’t cover
Reset sign-in cookies	Sessions end: “up to an hour” for open Gmail sessions; “other applications can vary”	Open app sessions	Gmail and Drive for desktop apps; a live third-party SSO session
Reset password	At once for new sign-ins	n/a	Only “some” OAuth tokens are revoked
Remove a connected app	At once for that app’s data access	n/a	Access returns if the user signs in to the app again
Wipe Account or Wipe Device	Status shows Wiped or Account Wiped; usually a few minutes, “up to 3 hours for some devices”	An offline device shows “Approved or Wiping” until it next syncs	Mirrored Drive for desktop content stays on the computer
Suspend	The account shows Suspended	Existing sessions: someone already in a Google Chat conversation can continue until that session ends	Suspension is not proof that every session has ended; billing continues, suspended accounts “are still charged”
Recipient address map	Mail arrives at the new recipient	“up to 24 hours”	Mail already delivered to the old mailbox

An offline phone is wiped when it next connects; until then it’s pending, not done. For Drive for desktop, “Mirrored content remains on the device,” so get company laptops back.

What comes after containment?

Everything that moves data rather than blocks access: Drive files, calendars, group ownership, the Archived User or deletion decision and the license. Don’t delete the account now. A deleted account can only be restored “for up to 20 days,” and Vault data “can’t be recovered even if you restore the user” (Google).

Don’t promise senders an auto-reply from the suspended mailbox. Suspension blocks new mail, so a reply needs an arrangement that can receive and answer messages, such as a redirect to an account that replies; see out-of-office for an employee who left.

Continue with the full offboarding process and email and data retention when an employee leaves.

How does Emergency Offboard work in Patronum?

Emergency Offboard runs a preconfigured offboarding policy against one user, “without it having to match the WORKFLOW criteria of a policy” (Patronum). Setup is three steps:

Create and activate an offboarding policy, usually your general company offboarding policy.
In Settings, select that policy for Emergency Offboarding and save.
On the day, open the user’s actions menu and choose Emergency Offboard.

Patronum console, demo environment (November 2026). A user’s actions menu with Emergency Offboard next to Suspend and Data transfer.

What the run includes depends on the selected policy. Patronum documents offboarding actions that change the password, delete app-specific passwords, remove the recovery email, remove connected apps, delete 2-Step Verification and suspend the user, plus wiping mobile devices or removing the account from them (Patronum). Patronum’s pricing page lists offboarding and shows the Business plan at $8 per user per year, but doesn’t say which plan includes each capability, so confirm Emergency Offboarding is in your plan before you depend on it.

Patronum’s documented actions don’t include ending a session at your identity provider, so do that in your IdP first. The execution log shows when each policy ran and whether it succeeded or failed (Patronum); a successful run doesn’t prove every app session has ended or every offline device is wiped, so still track those as pending.

Verification checklist

Mark each item requested, pending or completed:

IdP session ended and the user blocked in your identity provider (if you use one)
Password reset to a random value; sign-in cookies reset, with the time recorded
App passwords, connected apps and security keys revoked; recovery email and phone removed
New 2-Step Verification backup codes generated and not shared
Each managed device listed as Wiped or Account Wiped, or as pending with a named owner for follow-up
Company laptop requested back, if Drive for desktop was in use
Account suspended
Incoming mail rerouted, or a decision recorded that it isn’t needed
Preservation decision recorded: hold applied, or no hold required, with who decided
Handover scheduled in your offboarding process