Three things that are often treated as one

Offboarding conversations tend to collapse three distinct actions into a single checkbox. Separating them is the fastest way to see where access survives.

Disabling the identity

The account in the identity provider is disabled or deleted. The person can no longer authenticate through it. This is what most offboarding checklists mean by “revoking access”, and it is handled by the identity provider, not by Solvantra.

Removing application access

The person’s account inside each individual SaaS application is deactivated. Where an application was adopted outside single sign-on, this is a separate action in a separate admin console, and it does not happen automatically when the identity is disabled.

Revoking OAuth grants

Third-party applications that were authorized against the account retain their grant until it is revoked. These are easy to miss because they are not user accounts — they are authorizations held by software, described in more detail on our OAuth access management page.

Why offboarding misses things

The usual cause is that the list being worked from is not the full list.

An offboarding checklist is typically assembled from known applications — the ones IT provisioned or procurement paid for. Applications a team adopted directly, or tools an individual authorized against their own work account, are not on it, because nothing ever recorded them centrally.

There is also a timing problem. Offboarding happens on a specific day; access discovery, if it happens at all, happens on a different schedule. Anything adopted between the last review and the departure date is invisible to both.

The result is access that has no owner but still exists. That is the subject of our orphaned SaaS accounts page.

How Solvantra fits into the process

Solvantra covers the discovery and review part of offboarding, not the whole of it.

Termination signal

Your HR system sends a signed webhook — authenticated with HMAC-SHA256 — when an employee is terminated. Solvantra receives that event and uses it as the trigger for an access review. Your HR system has to be configured to send it; Solvantra provides the receiving end.

Matching

The terminated employee is matched against the OAuth grants Solvantra has already discovered for the connected tenant, producing a list of application authorizations associated with that person.

Three operating modes

The workflow runs in Off, Dry-run or Live mode, with Dry-run as the default. Dry-run produces the list and the intended actions without changing anything. Live mode can enqueue revocation jobs for the grants Solvantra supports revoking.

Administrator control

The administrator controls whether the HRIS workflow is enabled and which mode it runs in. In Live mode, signed termination events can automatically trigger revocation of already-flagged grants. Dry-run is the default, Live mode requires a connected revocation credential, and the workflow records what was acted on.

What this does not do

Solvantra does not perform complete automated employee offboarding, and it would be misleading to describe it that way.

It does not disable the primary identity — that remains the identity provider’s job. It does not deactivate accounts in arbitrary SaaS applications that have no OAuth relationship with the connected tenant. Revoking an OAuth grant removes the application’s authorization; it does not delete the user’s account in that application or in Google Workspace or Microsoft 365.

AI-assisted browser remediation, which is intended to reach applications with no API, is in development and dry-run only. It can locate a deactivation control but does not perform the deactivation.

A worked example

The following scenario is illustrative, not a customer case study. An employee leaves on a Friday. IT disables their identity in Entra ID the same morning, which stops them signing in.

The HR system sends a termination webhook to Solvantra. Solvantra matches that person against the OAuth grants discovered in the connected Microsoft 365 tenant and returns four: a note-taking tool, a scheduling assistant, a file-conversion utility and a CRM plugin — none of which appeared on the offboarding checklist, because none of them were centrally provisioned.

In Dry-run mode the administrator sees the list and the actions that would be taken. Switched to Live, Solvantra enqueues revocation of the grants through Microsoft Graph. The four applications lose their authorization against the tenant. The person’s Microsoft 365 user account is unaffected by that step — disabling or deleting it remains a separate administrative action.

Common questions

Does disabling an employee’s account remove all their SaaS access?

Not necessarily. Disabling the identity stops authentication through the identity provider, but SaaS accounts created outside single sign-on and OAuth grants held by third-party applications can persist until they are removed separately.

Can Solvantra automate offboarding end to end?

No. Solvantra automates the discovery, matching and — for supported providers — the OAuth grant revocation part of offboarding. Disabling the primary identity, and deactivating accounts in applications with no supported integration, remain separate actions.

What triggers an offboarding review in Solvantra?

A signed webhook from your HR system, authenticated with HMAC-SHA256, carrying a termination event. The workflow can run in Off, Dry-run or Live mode, so it can be observed before it is allowed to change anything.

Find the access that outlived the last departure.

The free assessment runs discovery against your connected tenant so you can see what is still authorized.

Start Free Assessment