Skip to main content
PurpletGo

Okta

How to offboard a user in Okta without leaving app access behind

Updated · 7 min read

Deactivating a user in Okta stops them signing in through Okta. It is the most important step, and it is not the last one. What happens in each downstream app depends on how that app is connected, and existing sessions in those apps can outlive the Okta account.

This guide covers the Okta side of offboarding and the gaps to check afterwards.

Suspend or deactivate?

For a permanent departure, deactivate. Suspend only when the person is expected back.

  • Suspend: temporarily blocks sign-in while keeping the user's app assignments and group memberships. Useful for leave or an investigation, not for a permanent departure.
  • Deactivate: the standard offboarding action for someone who has left. It ends their ability to use Okta and, for apps with provisioning enabled, starts deprovisioning in those apps.

Offboarding steps in Okta

  1. 1

    Clear active sessions

    Clear the user's Okta sessions so they cannot keep using an existing Okta session to open more apps.

  2. 2

    Remove group memberships

    Groups often drive app assignments and rules. Removing memberships makes sure no rule reassigns access.

  3. 3

    Deactivate the user

    Deactivate the account so it can no longer authenticate through Okta.

  4. 4

    Confirm downstream deprovisioning

    For each app with provisioning (for example SCIM), confirm the account was deactivated or removed in the app itself, not just unassigned in Okta.

  5. 5

    Handle apps without provisioning

    Apps connected only for SSO keep the user's account. Remove those accounts in each app, or they remain usable through any non-SSO login.

The gaps Okta deactivation leaves

  • Existing sessions inside apps: a user already signed in to an app may stay signed in until that app's own session expires, because Okta does not end sessions it did not create.
  • SSO-only apps: without provisioning, the account in the app is untouched when the Okta user is deactivated.
  • Local accounts: apps that also allow username and password login may still accept the old credentials.
  • API tokens and personal access tokens created inside apps (for example GitHub or Atlassian) are separate from Okta and keep working until revoked in the app.
  • Accounts that were never behind Okta at all, such as cloud consoles or tools a team signed up for directly.

A final check before closing the offboarding

  • List the apps the person was assigned in Okta before deactivation, and confirm each one is closed.
  • Search high-risk tools that are often outside SSO: source control, cloud providers, password managers, and finance systems.
  • Rotate shared credentials the person knew.
  • Record what was removed and when, for your access review and audit evidence.

How PurpletGo handles Okta offboarding

On every plan, PurpletGo connects to Okta with an admin API token, uses it to suggest which apps a departing person can reach, and revokes Okta access when an admin runs the revocation for that person. Apps outside Okta, such as GitHub and AWS, can be revoked in the same action, and each system reports its own result.

  • Clears the user's Okta sessions, removes group memberships, and deactivates the user.
  • Access discovery lists the apps assigned to the person in Okta before you revoke.
  • Revocation for tools that often sit outside SSO, such as GitHub and AWS, on every plan.
  • A result per system (revoked, failed, or needs manual action), so an app that did not deprovision is visible instead of silently missed.

30-day free trial - no credit card required

FAQ

Okta: common questions

What is the difference between suspending and deactivating a user in Okta?

Suspending temporarily blocks sign-in and keeps the user's assignments, so they can be restored. Deactivating is the standard action for a permanent departure and triggers deprovisioning in apps that have provisioning enabled.

Does deactivating a user in Okta remove their accounts in other apps?

Only for apps where provisioning is set up. Apps connected for single sign-on only keep the user's account, which needs to be removed in the app itself.

Does deactivating an Okta user log them out of apps they are already signed in to?

Not necessarily. Sessions inside each app are controlled by that app and can remain active until they expire, which is why removing the account in high-risk apps matters.