Why do manual offboarding processes leave Google Workspace access exposed?

Why manual offboarding leaves a gap in live Google Workspace access

Manual offboarding is often a two-step administrative task carried out as if it were one control. The directory entry may be disabled first, but active browser sessions, OAuth grants, app passwords, delegated access, and cached tokens can continue to work until they are explicitly revoked. That creates a residual access window that is easy to miss in a busy offboarding workflow.

In practice, the exposure comes from treating account removal and session invalidation as separate events. If one team suspends the account while another later clears sessions, or if session termination is omitted altogether, the user can keep accessing mail, Drive, Calendar, and connected apps after offboarding is assumed complete. The Joiner-Mover-Leaver guide and Workforce Identity Security Guide both reinforce that deprovisioning is only complete when the session and token layer is closed, not when the directory record changes.

Google Workspace is exposed here because its access model is layered. A suspended account may stop interactive sign-in, but previously issued sessions, refresh tokens, or delegated application access can remain valid long enough to preserve practical access. Manual processes tend to focus on the visible object, the account, rather than the live authorisation state behind it.

What actually stays open after the account is “removed”

The most common failure is a mismatch between identity lifecycle actions and runtime access controls. Directory deactivation, password reset, and group removal are important, but they do not automatically guarantee that every live session is dead. If the offboarding runbook does not include explicit session revocation and token cleanup, access can persist through the browser or through connected apps that already hold trust.

This is why manual offboarding tends to produce false confidence. Administrators see the user disappear from the admin console, but the control plane may still have valid artefacts elsewhere, including authorisation grants to third-party integrations and devices that have not yet rechecked state. The result is not a theoretical risk, it is a live residual privilege condition.

• Session tokens may remain usable until expiry or revocation.
• Connected apps may retain delegated access even after the account is disabled.
• Cached credentials and recovery paths can create a short-lived but material window.

IAM and IGA Basics is useful here because the control problem is really entitlement governance, not just account status. A clean offboarding process has to remove both the login path and the downstream access grants that make the login useful.

Why the residual-access gap keeps happening

Manual offboarding usually fails for process reasons, not because anyone misunderstands the theory. The work is fragmented across HR, IT, and security, so the account may be disabled in one system while tokens, sessions, and app connections remain untouched in another. The larger the estate, the more likely a human will miss one dependency or assume another team already handled it.

That is why one-off actions are not enough when the real object of control is a user’s effective access, not the directory row. NHI Lifecycle Management Guide and Top 10 NHI Issues both capture the broader lifecycle lesson well, because the same pattern appears whenever identity state and access state drift apart. Even though this page is about Google Workspace, the operational lesson is the same: offboarding must close the path, not only mark the record inactive.

Manual steps also struggle with timing. If a user is told they are offboarded but their active session remains valid for a while, the organisation has effectively left a short post-termination grace period. In benign cases that only creates confusion; in adversarial cases it creates opportunity.

Risk and Threat Considerations

Residual access after offboarding creates a direct exposure window for data theft, mailbox abuse, file exfiltration, and impersonation. The risk is highest when the departing user is hostile, under investigation, or simply careless with open browser sessions and synced devices.

Failure mechanism: The organisation disables the account but does not immediately revoke active sessions, refresh tokens, or delegated app access, so existing access continues after the user is presumed removed.

Impact: Sensitive mail, documents, calendar data, and connected applications may remain reachable long enough for deletion, exfiltration, or misuse, especially if the departure is intentional or contentious.

Practitioner Guidance

What to verify: Treat offboarding as incomplete until the account, all active sessions, and all downstream grants are revoked together. If the runbook does not explicitly call for session termination and token revocation, it does not actually close access.

Decision rule: If the user can still authenticate to any Google Workspace service through an existing session or delegated app, prioritise immediate session invalidation over administrative cleanup tasks that do not change effective access.

Practitioner takeaway: The control objective is not “disable the user”, it is “remove every practical path to continued access”, because that is what prevents residual exposure after offboarding.

Related resources from NHI Mgmt Group

• Why do manual offboarding checklists so often leave access behind?
• Why do SSO-based offboarding processes sometimes leave access behind?
• Why do Google Workspace offboarding processes fail in practice?
• Why do manual offboarding and quarterly reviews leave access risk behind?