Okta

The Okta sessions of an employee account seen in a leak are terminated.

How it works

The connection runs over the Okta management API. The account is found from the stable identifier in directory mapping, not from the text of an email. Even if an employee’s address changes, no other account is touched.

Termination requires approval. The preview shows which accounts are in scope; applying is a separate step. Before terminating, the account is read again: if it is not active, not a local Okta account, or its address differs from what is expected, nothing happens.

The call is never retried. If the answer is ambiguous the result is recorded as “could not be confirmed”.

Scope

Only accounts in the selected asset group that have a match in directory mapping.

Only local Okta accounts. Accounts federated from another provider are out of scope; access there is cut in the source system.

Passwords are not changed, accounts are not deleted, roles are not assigned.

Okta API tokens do not report which permissions they hold. The connection therefore stays in the “permission could not be verified” state and termination is not enabled on its own. A button that looks ready with a token that lacks the permission fails during a real incident.

Setup

The setup steps are in the panel, on the integration’s own screen. What to do on the provider side and which value goes where is written there.

Open the integration ↗