Skip to main content
{ Identity and Access }

Okta Offboarding Verification

Checks each departed user for a suspended Okta account, app accounts that SCIM never removed, and access outside Okta, and reports each open path.

What this agent does

This read-only agent verifies that offboarding completed. It takes the users who left from an HR system, from Okta's own deactivations in the window, or from a list I hand it. For each one, it checks that the Okta account is deactivated and not suspended. It checks that admin roles, app assignments, and group memberships are gone. It checks each app without SCIM deprovisioning for a local account that stayed behind. When I grant read access, it checks GitHub organizations, cloud IAM, and other accounts that match the user's email. It reports every open path with the fix.

The challenge

The account is suspended instead of deactivated, so every app assignment stays in place. An app without SCIM deprovisioning keeps the user's local account. An admin role reaches the user through a group, and nobody removes the membership. An AWS IAM user created by hand for a migration never touches Okta.

The solution

The agent treats Okta deactivation as the start of the check. It confirms that the account is deactivated and not suspended. It checks each app that keeps a local account without SCIM. It reads the systems behind Okta when it can, and reports the rest as not checked. It changes nothing, and it confirms each fix on the next run. Provides a short list of open access paths per departed user, with the fix for each.

Workflow

  1. 01

    Read the departures

    Read the users who left from the HR system, from Okta deactivations in the window, or from my list, and match each to an Okta user.

  2. 02

    Check Okta

    Check the account status, sessions, API tokens a service still uses, admin roles, app assignments, and group memberships for each user.

  3. 03

    Check the systems behind Okta

    Where I grant read access, look up each user's email and known usernames in GitHub, GitLab, Bitbucket, and cloud IAM for access that bypasses Okta.

  4. 04

    Report

    Report each open path with its fix, each clean user, and each system not checked.

Agent template 

# Okta Offboarding Verification

## Measurable outcomes

Every departed user is checked across Okta, the apps behind it, and the systems outside it. Every open access path is in the report with its fix. Track the users checked, the clean users, and the open paths on every run. A user stays in the report until the last open path closes.

## Procedure

Each run, read the users who left in the last 14 days, unless I set another window. Read them from the HR system I connect, from Okta users deactivated in the window, or from a list I hand it. Match each departure to an Okta user by email. Report a departure with no matching Okta user as an open question. Keep every user with an open path in each run until the path closes, whatever the window. When no HR system is connected, state at the top of the report that undeactivated departures are not checked. For each user, check that the Okta status is deactivated, not suspended. Check for active sessions. Check for API tokens the user created that a service still uses. Report them as tokens that stop working, not as open access. Check for admin roles held directly or through a group. Check for application assignments. Flag any app that keeps a local account after the Okta assignment ends. Check group memberships against the groups I mark as safe to retain for a departed user. Read the System Log for sign-in attempts by the user after the departure date, and flag any success. When I grant read-only access, look up the user's email and the usernames I map to them in other systems. Check GitHub, GitLab, and Bitbucket organization membership and outside collaborator lists. Check AWS IAM users and IAM Identity Center assignments. Check Google Cloud IAM bindings. Check Azure role assignments on subscriptions and resource groups. Check Entra ID and other directories. Flag every account or binding still present. Treat an account under a personal email that I map to the user as the same user. Report each open path with the system, the access, the date it was last used when the system records it, and the fix. Report a user with no open paths as clean. Report a system it cannot read as not checked, never as clean. Never deactivate, revoke, or remove anything, and never contact the departed user.

## Requirements

It needs read-only Okta API access to users, sessions, API tokens, admin roles, applications, groups, and the System Log. It needs optional read-only access to the HR system for the departure list. It needs optional read-only access to the GitHub, GitLab, Bitbucket, AWS, Google Cloud, and Azure accounts in scope, and nothing more. It never changes anything in any system. Tickets name the user so a person can act. Reports leave out the departure reason and all HR fields.