Offboarding

When someone leaves, you have two tools: disabling their account and removing it. They do different things, and the difference matters if you need to say with confidence that someone no longer has access.

Disable first

Go to Settings → Administration → Users, find the person in the list, and choose Disable from their row actions.

If you use LDAP: the Disable row action is hidden while LDAP sync is enabled. For local accounts, open the user’s edit page and turn on User Disabled there instead. For accounts that come from your directory, suspend the person upstream and let the next sync carry it through — that’s where their status is managed.

This takes effect immediately and covers most of what you need:

• They can’t sign in to Permiso.
• Any session they already had stops working on their next click. Permiso re-checks the account on every request, so an open browser tab won’t keep them going.
• Any API keys they created stop working.
• Applications you provision over SCIM are told the account is inactive on the next sync.

Disabling changes nothing else. Passkeys, group memberships, API keys, and their full audit history stay exactly as they were, and you can re-enable the account at any time.

Know what’s still live

One gap is worth understanding. Applications connected over OIDC hold their own tokens, and disabling an account in Permiso doesn’t reach into them:

• An access token an application already holds stays valid for up to an hour.
• An application holding a refresh token can keep exchanging it for a new one for up to 30 days, and that window restarts each time it does.

So an application someone left open, or a background job running under their account, can keep working after you’ve disabled them. If you need access cut off everywhere immediately, sign them out in the affected application directly, or remove the account.

Then decide whether to remove

Removing an account deletes it outright. There’s no soft delete and no undo.

Everything belonging to that user goes with it: passkeys, API keys, group memberships, the record of which applications they’d authorised, and their entire audit log history.

That last point is the trade-off. Removing the account is what actually severs live OIDC sessions, because the refresh tokens are deleted along with it. But you lose the record of what that person did while they worked for you, which is usually what an auditor asks for.

For most teams:

• Keep the account disabled if you may need the audit trail. This covers most regulated environments, and disabled accounts cost nothing and stay out of the way.
• Remove the account if you need to guarantee that no connected application can still act as that user, and you’ve accepted losing their history.

If the account came from LDAP, Permiso won’t let you delete it while LDAP is enabled and the account is still active, because the next sync would recreate it. Disable it first, or remove the person from your directory and let the sync do it.

Worth doing either way

Remove them from groups. A disabled user can’t log in regardless, but keeping group membership accurate is what makes your access reviews meaningful.

Check applications that manage their own accounts. Some applications keep a user record alongside SSO. Disabling someone in Permiso stops them signing in, but doesn’t delete their account or their data inside those applications.

Look at their API keys. A user’s keys stop working when you disable them and are deleted when you remove the account. Their profile page shows what they had, which is worth checking if any of those keys were driving automation somebody else now needs to own.

Re-enabling

Disabled accounts can be re-enabled at any time from Settings → Administration → Users. Passkeys and group memberships come back with them, so someone rejoining picks up where they left off.

Removed accounts can’t be restored. Someone rejoining after removal starts over with a new account and a new sign-up.