Passkeys for administrators: phishing-resistant authentication

This page is for the administrator who decides whether people sign in with passkeys. A passkey is a credential the person’s device holds and unlocks with a PIN, fingerprint or face; nothing is typed, so nothing can be phished. In SSOGEN a passkey is allowed, required or turned off by the sign-in policy, and the person adds it under My Account. What the person sees is in My Account: sign-in and security, section 5 and Sign in with a passkey.

Who can do this. A Super admin or an Authentication admin edits policies. Making a policy the Default policy or the Admin Console policy is for a Super admin. Any administrator who can open a person in Identity > Users can see that person’s passkeys on the Devices tab; nobody can add or remove a single passkey for someone else.

What you need first. A policy to edit (see Create a policy and assign it), and people on devices with a screen lock. A browser without passkey support tells the person “Passkeys are not supported in this browser.”

The result. Depending on the policy: people may sign in with a passkey instead of a password; or must; or cannot.

1. Allow passkeys

A passkey counts as both factors. The policy’s First factor block describes it: “Sign in with a passkey or security key. Counts as both factors: nothing more is asked after it.”

1. Open SSO policies > Policies, select the policy, then Edit beside its requirements (or Add policy and a starting point for a new one).
2. On Requirements, under First factor (“How people prove who they are. Choose at least one.”), tick Passkey. Leave Password (or your identity provider) ticked as well, so people without a passkey still get in.
3. Under Second factor, choose what suits the rest of your people. With Required, the fieldset notes “A passkey sign-in meets this on its own.” A person signing in with a passkey is asked nothing more; a person signing in with a password is asked for the accepted second factors.
4. Select Next to Review and Save policy (or Create policy). The notice reads “Saved.” or “Policy created. Assign it to applications from their Access rules tab.”
5. Make the policy apply: Make default on its page, or assign it to an application on the application’s Access rules tab.

The sign-in page then offers Sign in with passkey once the person has typed a username.

2. Require passkeys only

A policy can accept nothing but a passkey.

1. Edit the policy as above. Under Second factor, choose Passkey or security key only (“Only a passkey or security key is accepted.”).
2. The First factor block changes: Passkey reads “Always on: this policy accepts nothing but a passkey or security key.” and the note says “Only a passkey or security key is accepted, so the other first factors are not used and saving turns them off.” Phone approval is unavailable.
3. Select Next to Review and Save policy. In the policies list the policy shows Passkey only, and its page says “People sign in with a passkey or security key only.”

The starting point Passkey only under Add policy creates such a policy in one go.

Before you assign a passkey-only policy, make sure the people it reaches have added a passkey: under it, a person with none cannot open the application at all. The person’s own Remove this passkey? dialog warns of exactly this: “It is your last passkey: an application that accepts only passkeys cannot be opened until you add another.”

3. Turn passkeys off

1. Edit the policy. Under First factor, untick Passkey. Under Second factor, make sure Passkey or security key only is not chosen (it is refused otherwise: “A policy that accepts only a passkey has to offer passkey sign-in. Turn passkeys on, or choose another second factor.”).
2. Select Next to Review and Save policy.

A person who selects Sign in with passkey where the policy turns it off sees “Passkey sign-in is not turned on here. Choose another option, or contact your administrator.” The attempt is recorded in the audit log as authentication_policy.passkey_refused (shown as “Authentication policy passkey refused”), so you can see the rule is enforced. The passkeys themselves stay on the person’s devices and under My Account; another policy that allows them still accepts them.

4. The Admin Console

The Admin Console always asks for a second factor, and a passkey is one of the methods it accepts, beside approval in the SSOGEN Authenticator, the SSOGEN Authenticator code and a recovery code. Emailed and texted codes never open the console. A Super admin chooses the console’s policy under SSO policies > Defaults; a policy that fails the console’s rules is refused with a message such as “The Admin Console always asks for a second factor. Choose Second factor: Required, or use another policy. Nothing was saved.” See Admin Console sign-in.

5. What a person enrols

Under My Account > Authenticator, the Passkeys section (“Sign in with this device.”) has Add passkey. The browser and device take over: the person confirms with the device’s PIN, fingerprint or face. Afterwards the table lists the passkey with Added and a Sign-in column reading “Works for sign-in”.

What SSOGEN asks of the passkey:

• The device must have a screen lock, and the person must unlock it both when adding the passkey and at every sign-in. Without one the person sees “The passkey was not added: it was canceled or timed out. A passkey needs a screen lock on the device, such as a PIN, fingerprint or face. Set one up if needed, then try again.”
• The passkey must be one the browser can find by itself at sign-in, which is what a passkey built into the device (Windows Hello, Touch ID, Face ID, Android) or a modern security key provides. The Sign-in column flags an older credential that cannot: “Can’t be used to sign in. Remove it and add it again.”
• One passkey per device per account. A second attempt on the same device answers “This device already has a passkey for your account, so no new one was added. To add a passkey for another device, add it on that device.”
• Adding or removing a passkey in My Account needs a recent sign-in; Re-sign-in window (seconds) under Settings > Security (300 by default) sets how recent. The person is asked to confirm it is them first.
• A passkey has no name of its own: every one is listed as “passkey”, told apart by the Added date. Removing one is Remove, then Remove passkey in the dialog “Remove this passkey?”.

SSOGEN does not restrict passkeys by maker or model, and sets no limit on how many a person adds across their devices.

6. What the Admin Console shows

Open Identity > Users, open the person, select the Devices tab and scroll to Passkeys (n). The list is read-only: “Passkeys this person added under My Account. Reset MFA (Actions) removes them.” Each row shows Name (always “passkey”), Added, Last used (“Never” until the first sign-in) and Sign-in (“Works for sign-in”, “Can’t sign in on its own”, or “Not known (added before this was recorded)”). A person with none shows “No passkey” and “This person has not added a passkey under My Account, or every one was removed.”

There is no button to remove one passkey. If a device with a passkey is lost, the person removes that passkey under My Account (or removes it from the lost device’s account); if the person has lost everything, Reset MFA in the Actions menu removes every passkey together with every phone, authenticator app and recovery code. See Lost or replaced phone.

7. Limits

Limit	Value
Who adds or removes a passkey	Only the person, under My Account. Administrators remove all of them at once with Reset MFA, never one.
Passkeys per device per account	One.
Passkeys per person	No limit set by SSOGEN.
Naming	None; every passkey is listed as “passkey”.
Device or maker restrictions	None.
Time to complete adding or signing in	5 minutes, after which the page says the passkey was not added or that sign-in did not complete.
Sign-in attempts	Passkey attempts per minute under Settings > Security, 20 per client by default. See Security settings.
Where a passkey is not accepted	Where the policy does not tick Passkey (section 3). Phone approval as the whole sign-in is a separate first factor and not a passkey.

Check it worked

1. Test the policy. On SSO policies > Policies, select Test on the policy. Enter a Username, set Signed in with to Passkey or security key, and select Run test. The result reads “Nothing more would be asked.”
2. Sign in with one. In a private browser window on a device where the person added a passkey, type the username and select Sign in with passkey. Confirm with the device’s PIN, fingerprint or face. No second step follows.
3. Look at the record. On the person’s Devices tab, the passkey’s Last used now shows a time. In Monitoring > Audit, open Advanced filters, enter webauthn.registered in Event type and select Search to see when it was added.
4. For a policy with passkeys off, select Sign in with passkey on the sign-in page: the page answers “Passkey sign-in is not turned on here. Choose another option, or contact your administrator.” and authentication_policy.passkey_refused appears in the audit log.

Troubleshooting

What you see	What it means and what to do
Policy save: “A policy that accepts only a passkey has to offer passkey sign-in. Turn passkeys on, or choose another second factor.”	Passkey or security key only is chosen while Passkey is unticked. Tick it, or choose another second factor.
Policy save: “Choose at least one first factor.”	Every first factor is unticked. Tick Password, Passkey or another.
Policy save: “Skipping cannot combine with a passkey or security key requirement. Choose Second factor: Required, or turn skipping off.”	The policy lets people skip the second step on a remembered browser, which a passkey-only policy cannot. Turn skipping off.
Defaults page: “That policy has conditions, and the console does not apply conditions yet. Remove its conditions first, or choose another policy.”	A policy with conditions cannot be the Admin Console’s. Remove the conditions or choose another.
Sign-in page: “Passkey sign-in is not turned on here. Choose another option, or contact your administrator.”	The policy that applies turns passkeys off (section 3).
Sign-in page: “Enter your username first, then choose Sign in with passkey.”	The person selected the button before typing a username.
Sign-in page: “Passkey sign-in did not complete. Check the username, or add a passkey first.”	No passkey is registered for that username, or the username is wrong.
Sign-in page: “Passkeys are not supported in this browser.” or “Passkey sign-in is not available for this device or browser.”	The browser or device cannot do passkeys. Use another device, or another sign-in method the policy accepts.
Sign-in page: “Your browser blocked passkey sign-in. Reload the page and try again.”	The browser refused the request, usually a stale page. Reload.
Sign-in page: “Passkey sign-in canceled.”	The person closed the device prompt. Try again.
My Account: “This device already has a passkey for your account, so no new one was added. To add a passkey for another device, add it on that device.”	One passkey per device per account. Nothing to fix.
My Account: “The passkey was not added: it was canceled or timed out. A passkey needs a screen lock on the device, such as a PIN, fingerprint or face. Set one up if needed, then try again.”	The device has no screen lock, or the prompt was dismissed.
My Account: “The passkey was not added. Try again, or use another device.”	The device or browser refused for another reason. Another device usually works.
Devices tab: a passkey reads “Can’t sign in on its own”	The credential was added in a way the sign-in page cannot use. The person removes it under My Account and adds it again.
Devices tab: “Not known (added before this was recorded)”	The passkey predates this record. If it signs the person in, leave it; if not, they remove and re-add it.