OTP authentication: the one-time code policy

This page is for the administrator who manages the 6-digit codes people type at sign-in: the codes the SSOGEN Authenticator shows, and, where you allow it, codes from another authenticator app. It covers the realm-wide Code setup choice, the policy settings that offer codes, the limits under Settings > Security, and what happens to existing set-ups when you change the choice. Emailed and texted codes have their own settings; see Multi-factor authentication, Parts 2 and 3.

Who can do this. A Super admin changes Settings > Authenticator and Settings > Security; an Authentication admin and a Read-only admin can read them. A Super admin or an Authentication admin edits policies.

What you need first. Nothing beyond an administrator account. The defaults already work.

The result. You know which apps your people may use for codes, people who set one up are asked for it where the policy says, and a change you make reaches new set-ups without breaking old ones.

1. What a code is, and what is fixed

A sign-in code is six digits, changes every 30 seconds, and comes from a secret the authenticator app holds. SSOGEN accepts the current code and the one either side of it, to allow for a phone clock that is slightly off, and never accepts the same code twice. None of this is a setting.

Codes are the fallback behind phone approval: when a notification cannot be delivered, or push is off, “people can still sign in with the 6-digit code the app shows”, as the Authenticator page puts it. Codes can be phished; passkeys cannot. For the phishing-resistant choice see Passkeys for administrators.

2. Which authenticator apps are accepted

Open Settings > Authenticator and find the Code setup card. The radio group Where people get sign-in codes has two choices:

Choice	The page says	What it means
SSOGEN Authenticator only (the default)	“Codes are set up only by pairing SSOGEN Authenticator; no QR code is shown. Existing codes in other apps keep working. The default.”	Pairing a phone sets up its codes. My Account shows no QR code and no setup key, so nothing can be scanned into another app.
Any authenticator app	“Pairing sets up codes automatically. People may also scan a QR code with another authenticator app.”	Pairing still sets up codes; in addition My Account > Authenticator shows Use another authenticator app, with Set up authenticator, a QR code and the setup key, for apps such as Google Authenticator or Microsoft Authenticator.

Only the SSOGEN Authenticator approves sign-ins by number matching; another app gives codes and nothing else. This is one setting for the whole realm; a policy cannot choose per application, and there is no per-person exception in the Admin Console.

Change the choice

1. Open Settings > Authenticator. Under Code setup, select Any authenticator app or SSOGEN Authenticator only.
2. Select Save settings. The notice reads “Authenticator app settings saved.”
3. The change is recorded in Monitoring > Audit as authenticator.settings_changed (“Authenticator settings changed”).

Effect on existing enrolments

• Codes already set up in other apps keep working until the person removes them, whichever choice is current. Switching to SSOGEN Authenticator only does not remove anyone’s authenticator; it stops new ones being added by QR code.
• Codes set up by pairing a phone are unaffected either way.
• After switching to SSOGEN Authenticator only, Use another authenticator app disappears from My Account, and the person’s existing apps are still listed under Your authenticator codes with Remove.
• The first administrator’s set-up during first-run installation is always by QR code, whatever the choice.
• A policy that needs a second factor, and whose people may set one up at sign-in, follows the choice too. The policy page says: “What can be set up follows this policy’s second factors: SSOGEN Authenticator only. Any authenticator app is allowed when Authenticator settings say so.”

3. Offer codes in a policy

Codes are asked for by the sign-in policy, not by the Code setup card.

1. Open SSO policies > Policies, select the policy, then Edit beside its requirements.
2. Under Second factor, choose Required. Under Accepted second factors (“Tick the accepted second factors and order them. People are asked with the first they can use; the rest are under “Use another way”.“), tick SSOGEN Authenticator code. The default set is SSOGEN Authenticator approval, SSOGEN Authenticator code and Recovery code, in that order. Text message code (weaker) and Email code (weakest) are also available, and carry their own warnings.
3. Order the list with Move up and Move down. The summary reads “Offered in this order: Approve in SSOGEN Authenticator, then SSOGEN Authenticator code, then Recovery code.”
4. Select Next to Review and Save policy.

Note what Second factor: None does: “After the first factor, nothing more is asked.”, but the page adds “People who set up an authenticator or paired a phone are still asked for it after a password.” A person who has codes is asked for one even under a policy that does not require it.

The Admin Console accepts the SSOGEN Authenticator code, approval in the app, a recovery code and a passkey; its policy is refused if it drops them all: “The console policy needs approval in SSOGEN Authenticator, the SSOGEN Authenticator code, a recovery code, or passkeys. Email codes and text message codes never open the console.”

4. Limits under Settings > Security

These apply to every second-step code (authenticator, emailed, texted and recovery). See Security settings for the full page.

Setting	Default	Allowed	What it does
Verification code attempts per minute	5	1 to 10,000	Codes one person may try from one address per minute after the password.
Failed verification codes before a 15-minute lock	10	3 to 100	Consecutive wrong codes, across every method, after which the second step is locked for 15 minutes. The person sees “Too many attempts. Try again in 15 minutes.”
Show the enrollment key beside the QR code	on	on or off	Under Any authenticator app, whether the setup key is shown in characters beside the QR code, for desktop authenticators that take a typed key. It is not a secrecy control: the same value is inside the QR code.
Allow recovery codes	on	on or off	Whether a recovery code may stand in for a code. Off stops new sets and refuses the ones held; My Account then says “This deployment does not use recovery codes.”

5. Recovery codes

Recovery codes are the person’s own backup for the day the phone is gone. Under My Account > Authenticator > Recovery codes (“One-time codes for when you lose other methods.”), Generate recovery codes makes a set of ten; each works once and the set is shown once: “Copy and store these codes now. They will not be shown again.” Generating again replaces every unused code (“Every current recovery code stops working. The new set is shown once.”). An administrator cannot generate or view a person’s recovery codes; Reset MFA clears them with everything else. See Lost or replaced phone.

6. Removing a person’s codes

• The person, under My Account > Authenticator > Your authenticator codes: an app they added themselves has Remove, with the dialog “Remove this authenticator?” (“Codes from this app stop working. If it is your only second factor, your password alone protects the account.”) and the button Remove authenticator. Codes that came from pairing have no Remove; the row says “These codes belong to a paired phone. Remove the phone to remove them.”
• An administrator removes a paired phone, and with it the codes that phone received, with Revoke on the person’s Devices tab, or removes everything with Reset MFA in the Actions menu. There is no button to remove one authenticator app for someone else.

Check it worked

1. Open Settings > Authenticator and confirm which choice is selected under Where people get sign-in codes.
2. As a test person, open My Account > Authenticator. Under SSOGEN Authenticator only, there is no Use another authenticator app; under Any authenticator app, it is there with Set up authenticator.
3. Under Any authenticator app, complete the set-up with a third-party app: scan the QR code, type the code under Confirmation code and select Confirm. The page reads “TOTP is active. Future local sign-ins will require your authenticator code.” and the app appears under Your authenticator codes.
4. Sign in as that person in a private window. After the password, choose Use a code from SSOGEN Authenticator (or the method the policy offers first), type the code, and you are in.
5. On SSO policies > Policies, select Test on the policy and enter the person’s username. The result lists “SSOGEN Authenticator code” among “Second-step methods this person could use now”.
6. In Monitoring > Audit, search Event type totp.enrolled (“TOTP enrolled”) for the set-up and authenticator.settings_changed for your change.

Troubleshooting

What you see	What it means and what to do
My Account has no Use another authenticator app	The choice is SSOGEN Authenticator only (the default). Switch to Any authenticator app if you want third-party apps.
My Account: “Enter a valid authenticator code.”	The confirmation code was wrong or stale. Wait for the app to show a new one and try again; check the phone’s clock.
My Account: “Authenticator setup is unavailable” with Try again	The set-up could not start. Select Try again; if it continues, check Monitoring > System health.
Sign-in page: “That code didn’t work. Check it and try again.”	Wrong code, a reused code, or a phone clock more than a step off.
Sign-in page: “Too many attempts. Try again in 15 minutes.”	Failed verification codes before a 15-minute lock was reached. Wait, or raise the limit under Settings > Security.
Sign-in page: “Your sign-in took too long. Start again.”	The sign-in expired before the code was entered.
Settings > Authenticator: “Someone else changed this since you opened it. Reload and try again.”	Another administrator saved first. Reload and save again.
Settings > Authenticator: “Too many tries. Wait a minute and try again.”	Saves are rate-limited.
Settings > Authenticator: “Could not save the Authenticator app settings.”	The save failed. Try again; if it continues, check Monitoring > System health.
Policy save: “Choose an accepted second factor or offer passkeys; otherwise nobody can meet this policy.”	Required is chosen with no method ticked. Tick at least SSOGEN Authenticator code.
A person’s old Google Authenticator still signs them in after you chose SSOGEN Authenticator only	Expected: existing codes keep working until the person removes them or you run Reset MFA.