Admin lockout protection: always keep an SSO admin

Admin lockout protection means SSOGEN refuses any change that would leave nobody able to sign in to the Admin Console. It is always on and has no setting. This page lists what is refused, what you see, and what to do instead. It also covers the one exception, the break-glass recovery command, for the day an administrator is locked out anyway.

The idea is simple. The Admin Console has its own sign-in policy, made at setup. How administrators sign in, what the console accepts as a second step and how to move administrators to your identity provider are in Admin Console sign-in; the policy is also described under Defaults. SSOGEN counts the active Super admins who can really get in under that policy: they can reach its door (a provider it allows), and answer its second step with a credential they still hold (a paired phone where the policy lists approval, an authenticator code, or a passkey where passkeys are on). A change that would take the count to zero is refused, and nothing is changed.

What is refused

Change	What SSOGEN does
Disable or archive the last administrator who can get in	Refused. Also refused when you take the Super admin role away from them.
Remove a second factor of the last administrator who can get in (Reset MFA, removing their own authenticator code, passkey or phone on My Account, or an administrator revoking their phone)	Refused, nothing removed.
Switch off or archive the identity provider the console’s policy relies on, when no administrator could sign in to the console another way	Refused.
Give a policy to the Admin Console, or edit the console’s policy, so that no administrator can meet it (no administrator has signed in through a provider it allows, none has a second factor it accepts, or your own session would no longer satisfy it)	Refused.
Directory synchronization or SCIM provisioning that would deactivate the last such administrator	Refused. The account stays active; a directory import run reports “not disabled, because nobody else could sign in to the admin console under its sign-in policy”, and a SCIM client receives `409`.
A group rule, nesting, deletion or SCIM group change that would add or remove an administrator	Refused unless a Super admin makes it.

What you see

The console shows the server’s sentence as sent. The main ones:

Message	Where	What to do
This is the only administrator who can still sign in to the admin console. Give another administrator who can sign in to the admin console the Super Admin role first.	Disabling, archiving or removing the role	Grant Super admin to a second person who can sign in to the console, then repeat. See Admin roles.
This is the only administrator who can still sign in to the admin console, and without their second factor nobody could. Nothing was reset. Give another administrator who can sign in to the admin console the Super Admin role first. If this administrator has lost their authenticator and recovery codes, use the break-glass recovery command on the server (installation guide, section 10, “Break-glass recovery of an administrator”).	Reset MFA	Give another administrator the role first, or use the break-glass command.
This is the only administrator who can still sign in to the admin console, and without this second factor nobody could. Nothing was removed. Set up another authenticator first, or give another administrator who can sign in to the admin console the Super Admin role.	Removing a second factor, on My Account or by an administrator	Set up another authenticator first.
The admin console’s sign-in policy lets administrators in through this identity provider, and no administrator could sign in to the console without it. Have an administrator sign in through another connection the policy allows, or have a Super Admin change the console’s sign-in policy, first. Nothing was changed.	Switching off or archiving a provider	Do what the sentence says, then switch the provider off.
No administrator has signed in through any of the connections this policy allows, so applying it would leave nobody able to administer this product.	Choosing a policy for the console or the default	Have an administrator sign in through one of its providers first, or allow a provider one of them already uses.
This policy requires a second factor and no administrator has enrolled one, so applying it would lock every one of them out of the console.	Choosing or editing a console policy	Enroll an authenticator or a passkey for an administrator first.
Your own session does not satisfy this policy, so applying it would lock you out of the console immediately, including out of undoing it.	Choosing or editing a console policy	Sign in a way the policy allows, then apply it.
Nobody else could sign in to the SSOGEN admin console under its sign-in policy, so this account was not deactivated. A Super Admin gives another account that can sign in to the console the Super Admin role first. Nothing was changed.	SCIM (`409`)	Grant the role to another account, then retry the deactivation.

Only a Super admin changes how administrators get in

The same guard keeps the doors themselves in a Super admin’s hands:

Editing, failing over, replacing the rules of, or deleting the Admin Console’s sign-in policy is a Super admin’s. Others are told: “This policy decides how administrators sign in to the admin console. Only a Super Admin can change or delete it. Nothing was changed.” The console policy cannot be deleted while it is assigned to the console.
While the console relies on a provider, only a Super admin can change how that provider signs people in.
While the console relies on a directory, only a Super admin can add or remove a trusted certificate authority, because that decides which directory the console believes.
Changing an administrator’s account, or administrator membership of a group, is a Super admin’s: “Only a Super Admin can change this account.” and “Only a Super Admin can change administrator membership.”

Keep two administrators

The guard keeps the last administrator in, but it cannot give you a second one. Keep at least two Super admins, each with the SSOGEN Authenticator code or a passkey set up under My Account (the console accepts an approval in the SSOGEN Authenticator, its code, a recovery code or a passkey as the second step, never an email or text-message code), and keep a second administrator signed in when you change the console’s policy.

If an administrator is locked out anyway

The break-glass command runs on the server, as the person who runs SSOGEN, and does not need the web server. It prints a temporary password and ten new recovery codes for the administrator you name, and revokes every authenticator and sign-in of that account. Have a phone with the SSOGEN Authenticator at hand: the console needs a new authenticator afterwards. The command also makes sure the recovered administrator can open the console: when the console’s sign-in policy does not admit the SSOGEN directory, it adds it to a policy only the console uses, or, when the console shares its policy with other applications, leaves that policy as it is and gives the console a policy of its own named Administrator sign-in (after break-glass recovery). The second factor is never weakened, and the command prints what it changed. The exact command is in the installation guide, section “Break-glass recovery of an administrator”.