Craft CMS: disable password login without locking yourself out of the control panel

What "Single sign-on only" actually does

It refuses a password sign-in on the control panel when the form is submitted. Precisely, and the precision matters when you are deciding whether this is safe to turn on:

• Control panel only. Front-end logins on your own site — members, customers, a headless login form — are untouched, because the setting says "control panel" and that is all it does.
• Password sign-ins only. Passkeys are a separate method and are left alone.
• Already signed in? Actions that ask you to confirm your identity with your password still work; Craft checks that on a different path and the plugin does not touch it.
• Not a failed password. A refused attempt is not counted towards Craft's lockout or cooldown, so trying repeatedly during an outage costs you nothing.

The refusal message is "This site requires single sign-on. Use the sign-in button on this screen." — unless preventUserEnumeration is on, in which case both the message and the error code fall back to Craft's generic "Invalid username or password.", which is indistinguishable from a wrong password.

Why the password form is still on screen

The plugin never hides the password fields, and there is no setting that makes it. Hiding would only ever be correct if nobody at all could use a password — and the anti-lockout guard below rewrites exactly that combination when your settings are loaded. The state that would justify hiding the form cannot be reached, so code to hide it would be code that never runs. A user who may not use a password sees the form, submits it, and is refused; the single sign-on button is on the same screen.

The anti-lockout guard, and the gap it cannot close

If the combination you save would leave nobody able to get in when the provider breaks — SSO only, admins blocked, no emergency account — the plugin turns password login for admins back on and tells you so: "These settings would have left nobody able to reach the control panel if the identity provider failed, so password login for admins was turned back on." It does not refuse the save, because these settings are also read while rendering the login page, and failing there would lock you out with the very guard meant to prevent it.

The three settings, in the order you should touch them

1. Admins may still use a password — on by default, and the intended fallback while SSO-only mode is on. Leave it on and none of the lockout scenarios below concern you.
2. Emergency accounts — e-mail addresses or usernames, one per line, that may still sign in with a password while SSO-only is on. This is the list to fill in if you want to turn the admin fallback off. An entry only works if it names an account that exists and has a local Craft password. Craft rejects an unknown login name, and an account with no password, before the plugin is consulted at all, so neither a typo nor a passwordless account is a way back in however it is spelled here. Accounts this plugin created through single sign-on have no local password — on a site that has run SSO-only for a while, the obvious-looking candidates are precisely the ones that cannot use a password. Suspended and still-pending accounts are refused too, by Craft's own status rules.
3. Emergency password login (break glass) — a temporary reopening of the door, with Emergency login expires at as a Unix timestamp. Three rules are enforced on save: an expiry is mandatory, it must be in the future, and it may be at most 24 hours ahead, otherwise the save is refused with "Emergency password login can be enabled for at most 24 hours at a time." Generate the value with something like date -u -d '+8 hours' +%s; while the window is open the settings screen counts the remaining minutes down.

The non-obvious part of break glass is deliberate: if it is somehow enabled with no expiry at all — hand-edited project config, a legacy row, a value that did not survive a deploy — the switch is treated as off, not as open forever, and the screen says "Emergency password login was requested without an expiry time, so it stays off." An expiry further out than 24 hours — a timestamp accidentally written in milliseconds is the usual way to get one — is closed too, but with one difference worth knowing: that case is silent. The settings screen shows the switch as on and says nothing, because the message above is written only for the missing-expiry case. Password sign-in stays shut; if break glass looks enabled and is not letting anybody in, check the size of the timestamp. An emergency switch that never closes is just a permanent password door.

Before you turn the admin fallback off

1. Nominate an emergency account that is not one this plugin created, and make sure it has a local Craft password.
2. Sign in as that account with its password and prove it works. Nothing else confirms it — the plugin does not yet check the emergency list against real accounts when you save it, so that proof is yours to make.
3. Only then turn Admins may still use a password off, and re-read the warnings at the top of the settings screen after the save.

When the identity provider is down

Two ways back in, in order:

1. Break glass, if you can still reach the settings screen through another session: set the switch and an expiry inside the 24-hour ceiling, and password sign-in reopens until it closes itself.
2. Turn the plugin off from the command line, which needs no browser and no session: php craft plugin/disable keyway-sso. A disabled plugin registers nothing, so Craft's password login returns to normal immediately. Your settings are kept, so you can fix the emergency list and re-enable it with php craft plugin/enable keyway-sso.

The setting that can really cost you access is not on this screen

It is the group and admin mapping — but only when a login actually writes to the account, which happens for a new account or for an existing one with Update accounts on every login switched on. Two combinations do the damage: sync mode Replace can remove the Craft group that granted control panel access, and Revoke admin when no rule matches clears the admin flag of anybody who signs in without matching an admin rule — including the account that configured the plugin.

Recovery is ordinary Craft: sign in with a password, from another administrator account if the first one lost its admin flag, and fix the mapping before signing in over single sign-on again. Test both on a throwaway account first. The details are on the group mapping page, and the reason codes are on the troubleshooting page.