Ghost Admin Access: The SaaS Accounts Nobody Owns After Your Founder Leaves

You offboarded your CTO six weeks ago. You removed them from Google Workspace, deactivated their Slack, and checked the box on your offboarding checklist. Then last Tuesday, your new lead engineer tried to add a billing contact in Stripe — and couldn't, because your former CTO is still the account Owner and you have no way to remove them without their cooperation.

This is orphaned admin access. It's not a theoretical risk. It's a Tuesday problem. And it happens at almost every startup because standard offboarding — disabling accounts, revoking SSO, deprovisioning from IdP — doesn't touch the in-app admin layer where the real power sits.

Disclosure: this is the Optserv blog. We cover access lifecycle because it's what we build for startups.

Why This Hits Startups Hardest

Enterprise companies have IT teams and SaaS governance platforms that track admin roles across hundreds of tools. Startups have a shared doc and good intentions.

The numbers are bleak: 63% of businesses have former employees still actively accessing SaaS apps after offboarding. 91% of ex-employee OAuth tokens remain live after a standard IdP deprovisioning. And 50% of companies have discovered former employees accessing their systems months after departure — usually when something breaks and they go looking.

For a 15-person startup, a single orphaned admin account on Stripe, AWS, or Cloudflare isn't just an embarrassment. It's a potential billing hijack, a DNS takeover, or a data breach tied to a credential you thought you already closed.

What "Orphaned Admin Access" Actually Means

Most SaaS tools have two separate permission layers:

Layer 1 — Identity Provider (IdP): Your Google Workspace, Okta, or JumpCloud controls who can log in. When you disable someone in your IdP, they lose SSO access.

Layer 2 — In-app admin roles: Each SaaS tool has its own internal role system. Owner, Super Admin, Billing Admin, Org Owner — these are set inside the app itself. Many of them were granted to the founder or first employee who signed up, long before your company had a directory or an IT process.

These two layers are not linked by default. Disabling someone in your IdP removes their ability to log in via SSO. It does not remove their in-app admin role. In many tools, it does not invalidate their existing API keys or personal access tokens either.

That gap — between "they can't log in" and "they don't have admin rights anymore" — is where orphaned admin accounts live. The person is gone. Their credentials are expired. But inside nine specific SaaS tools, their admin role is still sitting there, attached to a personal email or an API key that was never rotated.

The Nine Tools With the Hardest Orphaned Admin Problem

Stripe

The account Owner cannot remove themselves from Stripe. Ownership must be formally transferred to another user before the original owner can leave — and if they're already gone, Stripe's process requires contacting support, verifying business ownership, and waiting. Meanwhile, any API keys that developer tied to their personal Stripe account continue working until manually rotated.

GitHub

GitHub cannot remove the last organization Owner by design. If your CTO was the only org owner and they left, you cannot remove their membership until you've promoted another member to Owner. Their personal access tokens (PATs) also survive account deactivation and do not expire unless the keys themselves are deleted or rotated.

AWS

The AWS root user is permanently tied to the email address used to create the account. IAM admin roles can be revoked, but the root credential — with unrestricted access to billing, account closure, and all resources — lives at the email level. If a co-founder created the account with their personal email and no one has changed that, the root user is still theirs.

Cloudflare

Cloudflare Super Administrators cannot leave an account without first appointing a replacement. If they leave without doing that, you are locked out of DNS management and firewall controls. The only recovery path is Cloudflare support, which requires domain ownership verification and can take days.

Vercel

Vercel team Owners cannot be removed until another member is promoted. Integration tokens tied to a personal Vercel account — common when a developer sets up CI/CD pipelines — break when that person is removed, but the admin role itself doesn't disappear automatically.

Google Workspace

Super Admin roles in Google Workspace can be assigned to personal Google accounts (outside your managed domain). Disabling the user in your SSO does not remove the Super Admin role if the account was created with a personal Gmail. That role grants full control over mail routing, domain settings, and user management.

Figma

Figma has three independent permission layers: workspace admin, team owner, and file owner. Each must be manually transferred. Removing someone from the workspace doesn't transfer their file ownership. Designs they owned remain in their control until you audit each layer separately.

Notion

Workspace owners in Notion can be personal email accounts. Removing someone from your SSO directory does not remove their Notion workspace ownership. They retain the ability to export all workspace content, manage billing, and delete pages — including pages they originally created.

HubSpot

HubSpot Super Admin roles are set per-user inside HubSpot itself, not controlled by your IdP. A former employee who held Super Admin in HubSpot keeps that role until someone manually revokes it from within HubSpot's user management panel. SSO deactivation prevents login but does not demote the role.

Why Your Offboarding Checklist Didn't Catch This

Standard offboarding covers the IdP layer: disable the account, revoke SSO, remove from email groups, wipe the laptop. If you're organized, you also revoke app-level memberships in the tools you actively manage. But most startups don't have a complete map of which apps each person had admin rights in — especially the apps they set up in year one before any governance existed.

Three specific patterns create the gap:

First-user privilege. The person who creates the SaaS account almost always gets the highest permission level automatically. If your CTO signed up for Cloudflare in 2023, they're the Super Administrator. That was never written in a document.

Personal email accounts. Early-stage startup tools often get set up with personal Gmail addresses or founder emails outside the managed domain. These accounts aren't in your IdP at all, so offboarding your IdP user does nothing.

Token persistence. API keys and OAuth tokens issued to a user don't expire when the user's SSO is revoked. A developer who had CI/CD access via a GitHub personal access token still has that token in their local environment until you rotate the keys. See our guide on shadow IT at offboarding for how to surface these before someone leaves.

How to Audit for Ghost Admin Accounts Today

If someone has left in the past 12 months, run this audit now. It takes 30–60 minutes.

Step 1: List every departed person from the last year. Pull their name, email (work and any known personal), and their last role. Note who was a "founder" or "early employee" — these are the people most likely to have signed up for tools before governance existed.

Step 2: Check admin rosters in each critical tool. For each of the nine tools above, log in as your current admin and pull the user list filtered by admin role. Cross-reference against your departed employee list.

Step 3: Check for non-SSO accounts. In each tool, look for users authenticating with personal Gmail addresses or email addresses outside your company domain. These are the accounts your IdP doesn't control.

Step 4: Check API keys and tokens. In Stripe, GitHub, AWS, and Vercel — check active API keys and note the owner. Any key tied to a former employee's account should be rotated immediately, before you revoke the account, to avoid breaking active integrations.

Step 5: Transfer ownership before removing. Don't just delete orphaned admin accounts. Transfer their ownership rights first (files in Figma, org ownership in GitHub, account ownership in Stripe), then remove the account. Skipping the transfer step can lock you out of your own tools.

For a full walkthrough of the discovery process before someone leaves, see how to run a who-has-access audit at your startup.

Preventing the Next Orphaned Admin Account

The audit above is reactive. Here's how to make this a non-problem for future departures:

Maintain an admin registry. A simple spreadsheet — tool, admin role, person's name, personal email if applicable, date granted — prevents the "who owns this?" conversation at 3am on a Friday. Update it when anyone gets elevated access and again when anyone leaves.

Set a two-admin minimum on critical infrastructure. Stripe, AWS, Cloudflare, and GitHub should each have at least two current employees with sufficient admin access to manage a departure. If only one person has Owner rights anywhere, fix that today.

Make ownership transfer part of offboarding. Add an explicit step to your offboarding process for each critical tool: "Transfer ownership of [tool] from [person] to [successor] before last day." This is the moment to do it — after they're gone, the process gets harder and sometimes impossible without support tickets.

Use a shared admin email for tool signups. For tools where the account creator becomes the permanent owner, use an alias like ops@yourcompany.com rather than a personal address. The alias is owned by the company, not the person.

Optserv tracks which people hold admin access across your SaaS stack as part of the employee record. When someone leaves, the offboarding flow surfaces every elevated access grant that needs manual transfer or revocation before you close the account. It doesn't eliminate the manual steps for tools like Stripe and Cloudflare — but it makes sure you know about them before the person is gone.

Try Optserv free → app.optserv.ai/signup

Quick Reference: Tool-by-Tool Orphaned Admin Risk

Frequently Asked Questions

What is an orphaned admin account? An orphaned admin account is a SaaS user account that holds admin-level privileges — Owner, Super Admin, Billing Admin — where the original user has left the company but the account was never properly transferred or decommissioned. The person can no longer log in via SSO, but their in-app role still exists and may grant residual access through API keys or password-based login.

Does disabling someone in Okta or Google Workspace remove their SaaS admin access? No. Disabling an IdP account prevents SSO-based login. It does not remove in-app admin roles, invalidate API keys, or terminate existing sessions in most SaaS tools. Each tool requires a separate manual step to revoke the admin role — and some (like Stripe and Cloudflare) require an explicit transfer before removal is possible at all.

How do I regain access to a SaaS account if the original admin is gone? The path depends on the tool. For Stripe and Cloudflare, contact their support teams with documentation proving your business owns the account (domain verification, business registration, billing records). For GitHub, promote an existing member to Owner first. For AWS, the root account recovery process requires access to the root email address — which is why changing that to a shared alias early is critical.

How often should startups audit admin access? At minimum, run a full admin roster check at every offboarding. Additionally, run a broader quarterly access review across all tools to catch any role changes, former contractors who still have access, and admin accounts that were created and forgotten.

Sources

• JumpCloud: 91% of former employee tokens remain active after offboarding
• Atekro / Verizon 2025 DBIR: 20% of breaches involve ex-employee credentials; 63% of businesses have former employees still in SaaS post-offboarding
• Push Security: Ghost logins — accounts that bypass SSO entirely after IdP deprovisioning
• Cloudflare Community: documented super administrator departure lock-out cases
• Stripe Support documentation: owner transfer process and restrictions
• AWS IAM documentation: root user credential behavior and account email requirements
• Torii 2026 SaaS benchmark: orphaned accounts as a top-3 SaaS governance concern for CISOs