Orphaned SaaS accounts and access that outlives its owner
An orphaned SaaS account is an account or application authorization that still works but no longer has a legitimate owner — the person it belonged to has left, changed role, or never had a recorded claim to it in the first place.
It matters because the access is real even though the relationship behind it is not. Nothing is broken, nothing generates an error, and nothing prompts anyone to look.
Solvantra’s role here is discovery and review: finding the accounts and OAuth grants it can see through supported connections, presenting the ones that look unowned, and revoking the grants it supports revoking once an administrator decides.
What counts as an orphaned SaaS account?
In practical terms, an access relationship is orphaned when it still functions but no current, identifiable person or business purpose stands behind it.
That covers several different shapes: a user account in a SaaS application belonging to someone who has left; a shared or generic login nobody now owns; an OAuth grant held by a third-party application on behalf of a departed employee; an account created for a project that ended.
What they have in common is not that they are dormant — some are actively used by automation — but that no one is accountable for them. That is what makes them hard to notice and awkward to clean up.
How orphaned access arises
Departures that stop at the identity provider
The leaver’s identity is disabled, but accounts created directly in individual applications, and grants held by third-party tools, are not part of that action. See employee offboarding for how the steps come apart.
Applications adopted outside procurement
A team signs up for a tool directly. Nothing records the accounts it creates, so nothing later reviews them.
Role changes without access changes
Someone moves to a different function. Their new access is granted; their old access is rarely removed, because no event triggers a review of it.
Standing authorizations
An OAuth grant given once to connect a useful tool stays valid indefinitely, independent of whether the person who consented is still there.
Why organizations miss it
Orphaned access is not hidden so much as unaddressed. It fails quietly, which means it fails invisibly.
There is no single console that lists every SaaS account and every application authorization across an organization, so building the list is itself the hard part. Each application knows its own users; the identity provider knows identities; nothing holds the relationships between them.
Orphaned access also produces no symptoms. A disabled identity generates a support ticket within hours. An account nobody owns generates nothing at all — it simply continues to work.
We are deliberately not quoting industry figures on how common or how costly this is. Whether it applies to a given organization is an empirical question about that organization’s own environment, which is what discovery is for.
What discovery actually means
Discovery is the process of building an inventory of the access that exists, from the sources Solvantra is connected to.
Through a connected Google Workspace or Microsoft 365 tenant, that means enumerating the OAuth application grants held against the tenant. Where receipt scanning is enabled, it also means surfacing SaaS spend visible in mailbox receipts — which often reveals applications nobody had recorded centrally.
It is worth being precise about the boundary: discovery covers what the connected providers expose. An application with no OAuth relationship to the connected tenant, accessed with a standalone username and password, is not discovered through this route.
What administrators review, and what Solvantra can act on
Review
An administrator sees the discovered accounts and grants, together with why each was flagged — for example, a grant associated with a terminated employee. Flagging is input to a decision, not the decision.
Action
For OAuth grants in Google Workspace and Microsoft 365, Solvantra can revoke the grant through the provider API once authorised. Revocation removes the application’s authorization; it does not delete the underlying user account, and it does not extend to applications with no supported integration.
Where an application has no API, AI-assisted browser remediation is in development and dry-run only — it can locate a deactivation control but does not perform the deactivation. Current status for every connector is on the integrations page.
Common questions
What is an orphaned SaaS account?
A SaaS account or application authorization that still works but has no current legitimate owner — typically because the employee it belonged to has left or changed role, and nothing triggered a review of the access itself.
How do you find orphaned SaaS accounts?
By building an inventory from the systems you can connect to, then comparing it against who currently works at the organization. Solvantra does this for the OAuth application grants held against a connected Google Workspace or Microsoft 365 tenant, and surfaces SaaS spend from receipt scanning where it is enabled.
Can Solvantra delete an orphaned account?
Solvantra can revoke OAuth grants in supported providers. It does not delete the underlying user account in Google Workspace, Microsoft 365 or any third-party SaaS application — that remains an administrative action in the application itself.
Related reading
Find out whether orphaned access exists in your environment.
Rather than estimating, run discovery against a connected tenant and look at the actual list.