SSO admin console sign-in and lockout protection

The Admin Console has its own sign-in policy, separate from the one your employees use. A new installation makes it for you during first-run setup. It is called Administrator sign-in: an administrator types a password and then approves on the phone in the SSOGEN Authenticator, types its code or a recovery code, or uses a passkey. This policy is the only rule for opening the console: nothing else is asked once it is met. SSOGEN also refuses any change that would leave nobody able to sign in to the console. This guide explains how administrators sign in, so you can move administrators to your company’s identity provider without locking yourself out.

You need the Super admin role to change the console’s policy.

What setup creates

First-run setup ends by creating two sign-in policies (the console policy only when the console has no policy yet):

Policy	Used for	What it asks
Default sign-in	My Apps, and any application with no policy of its own	The local directory, a second factor, passkeys allowed. It is the realm’s default policy; change it under SSO policies > Defaults.
Administrator sign-in	The Admin Console only	The local directory, a password, then an approval in the SSOGEN Authenticator (with number matching), its code or a recovery code; passkeys allowed; a new sign-in after an hour. Never phone sign-in, an emailed sign-in link or a remembered browser. Its description reads “Administrators sign in with their SSOGEN password and the SSOGEN Authenticator (an approval with number matching, or its code), a recovery code or a passkey, and sign in again after an hour.”

The administrator you create at setup meets the console policy with the authenticator they set up in the same step, so there is nothing to build before you sign in. On an upgraded installation whose console has no policy, the first start gives it Administrator sign-in when at least one Super admin can meet it; otherwise nothing changes and Setup health says what to do.

The console policy is never the default policy, so an edit aimed at employees cannot change how administrators sign in. You can edit it under SSO policies > Policies and replace it under SSO policies > Defaults; it can never be left without a policy, and it always asks for a second factor: saving it without one is refused. The policy list marks it Used by the Admin Console.

What the console accepts

The Admin Console accepts, of what its policy lists, these second steps: an approval in the SSOGEN Authenticator, the SSOGEN Authenticator code, a recovery code, or a passkey. Every approval asks the person to pick the number the sign-in page shows.

• It never takes an email code or a text-message code, even when the console’s policy lists them. In the policy editor they are shown as unavailable, and Passkey or security key only is suggested as the strongest choice: it takes approvals and codes off the console.
• It never takes an identity provider’s own multi-factor sign-in. An administrator who signs in through a provider is asked for SSOGEN’s own second factor first.
• A second factor added after a sign-in began never opens the console on that sign-in.
• Lost phone recovery by email and text code is not offered to administrators; an administrator uses a recovery code, or another administrator resets their second factors.

An administrator who signed in on My Apps in a way the console’s policy accepts opens the Admin Console without signing in again. One who signed in with a password alone is asked for the second factor on the same sign-in. One whose sign-in is older than an hour, came through a provider the policy does not admit, or used phone sign-in or an emailed link signs in again. Admin mode follows without another prompt (see Multi-factor authentication).

Let administrators sign in through your identity provider

1. Add and activate the provider (for example Microsoft Entra ID). See Add an OpenID Connect identity provider.
2. Open SSO policies > Policies, open Administrator sign-in and add the provider to its first factors. Or assign another policy to the console under SSO policies > Defaults.
3. Give the people who should administer SSOGEN the Super admin role.
4. Sign in to the console through the provider once, as that person, before you disable or remove the local administrator.

Only a Super admin can change the policy the console uses, the provider that policy relies on, or the certificates a directory used for the console’s sign-in. The exact refusals are listed in Admin lockout protection.

Lockout protection

SSOGEN refuses any change that would leave nobody able to sign in to the Admin Console, and writes each refusal to the audit log. The full list of refused changes, the exact messages and the recovery steps are in Admin lockout protection; this page does not repeat them.

The order of work that keeps you safe is always the same: give the next administrator the Super admin role, make sure they can pass the console’s policy (they have signed in once, and have the SSOGEN Authenticator or a passkey), and only then change the first administrator.

If an administrator really is locked out, see If an administrator is locked out anyway.

Check that it works

1. Open SSO policies > Policies. The row Administrator sign-in carries the label Used by the Admin Console.
2. Open SSO policies > Defaults. The console’s policy is Administrator sign-in and the default is Default sign-in.
3. In a private window, sign in to the Admin Console. After the password you are asked to approve on your phone (picking the number shown), or for a code, a recovery code or a passkey, and never for an email or text-message code.
4. If you have a single administrator, open them under Identity > Users and choose Disable user. SSOGEN refuses and names the Super Admin role.

Related

• Multi-factor authentication
• The sign-in page
• Manage users