Offboarding access to SaaS tools: closing the accounts, tokens and ownership gaps when people leave

Why offboarding breaks in SaaS-heavy companies

Ten years ago, a leaver’s access largely lived in a directory and on a laptop. Today it is spread across email and collaboration suites, CRM and marketing platforms, design tools, project management, code repositories, cloud consoles, analytics, advertising accounts, social media, website hosting and domain registrars.

Many of these tools were adopted by teams directly, signed up with a work email and a password, sometimes paid with a company card. Others were connected through personal accounts, such as an agency partner’s access to an ad account or a freelancer who owns the Google Analytics property. When people leave, access that was never recorded is never removed.

The risks are practical: a former employee still receiving customer data, a disgruntled contractor with admin rights to the website, an integration that stops working because the token belonged to the leaver, or a company locked out of its own social media or domain.

Single sign-on and automatic deprovisioning

The strongest foundation is central identity management. When tools use single sign-on through the company’s identity provider, disabling the user there prevents new logins to those tools. Where tools support automated provisioning standards such as SCIM, deactivating the user can also deactivate or remove their account in each application.

Single sign-on has limits. Existing sessions may remain active until they expire, some tools allow local passwords alongside SSO, and not every tool supports SCIM, sometimes only on higher pricing tiers. Offboarding should include revoking active sessions and checking tools where local accounts remain possible.

The access that is easy to forget

A good offboarding checklist looks beyond named user accounts. The most dangerous leftovers are credentials that keep working without a person logging in.

API tokens and keys

Personal access tokens, API keys and service credentials created by the leaver for integrations or scripts.

OAuth grants

Third-party apps authorised with the leaver’s account, which may keep syncing data.

Shared accounts

Logins used by several people, such as a social media account or supplier portal, whose passwords the leaver knew.

Admin and owner roles

Ownership of workspaces, repositories, ad accounts, analytics properties, domains and app store accounts.

Delegations and forwarding

Mailbox delegation, calendar access and email forwarding rules to personal addresses.

MFA devices

Authenticator apps or phones registered to shared or admin accounts.

Password manager vaults

Shared vault access and credentials stored only in personal vaults.

Ownership before deletion

Deleting a leaver’s account can delete the data they own. Files in cloud storage, documents, dashboards, automations, recordings and design files may belong to the user rather than the organisation. Many suites provide tools to transfer ownership to another user before deletion; others require manual export.

Integrations deserve particular care. If the leaver created the connection between the website form tool and the CRM, or between the shop and the accounting system, revoking their access can silently break data flows. Integrations should be moved to service accounts owned by the organisation, not individuals.

Legal and regulatory requirements may require retaining some data, such as email for litigation holds or records for statutory retention. Offboarding should follow a defined decision about what is transferred, retained and deleted.

Marketing and external accounts

Marketing teams often hold the most scattered access: advertising accounts, social media business managers, analytics and tag manager properties, email platforms, review sites, marketplaces, domain registrars and website hosting. Agencies and freelancers are frequently involved.

The organisation should own each account through a company-controlled business account, with individuals and agencies added as users with appropriate roles. When someone leaves, their user access is removed without affecting ownership. Where a former employee or agency is the only owner, recovering the account can take weeks and sometimes fails.

Making offboarding repeatable

Maintain an inventory of SaaS applications with owners, the authentication method, admin users, integrations and whether SSO and SCIM are used. Update it when tools are adopted, including tools bought on company cards.

Trigger offboarding from HR or contract end dates, not only from a manager remembering. Use a checklist per role, and have tool owners confirm removal. For higher-risk roles, schedule offboarding for the moment access ends and rotate shared credentials the same day.

Review access regularly, not only when people leave. Periodic reviews of admin roles, active tokens and external users catch leftovers from previous departures and role changes.

Where this sits in what we do

This article covers one decision inside a wider engagement. The solution page sets out how that engagement runs, what it includes and what it costs to find out.

• Complete Digital Transformation — The whole stack, sequenced — brand, web, marketing, CRM, automation, reporting and infrastructure — with benefits measured afterwards rather than projected and forgotten.
• Quote to cash without re-keying: where the handoffs break
• Product data is the e-commerce growth lever nobody budgets for
• Energy ratings in property adverts: what agents across Europe must show
• The EU Data Act: connected product data, cloud switching and the dates that matter
• All insight articles