Authenticator Apps
An authenticator app generates a six-digit code that changes every thirty seconds. It is the recommended second factor.
Where to find it
Architect Panel → Security:
- Two-Factor Authentication — registered tokens and their device nicknames
Architect Panel → Configuration:
- Site Settings — the 2FA settings
How it works
Enrolment shares a secret between the platform and the app, usually by scanning a QR code. Both then derive the same code from that secret and the current time — so the app needs no network connection, and nothing is sent anywhere to produce a code.
Why it beats SMS
- No network dependency — it works on a train, abroad, in a basement.
- No interception — nothing is transmitted. SMS can be redirected by a SIM swap, which is a routine attack against people worth attacking.
- No cost — SMS has a unit cost per sign-in.
- Immediate — no waiting for a message that may be delayed.
Offer SMS as a fallback for people who genuinely cannot use an app, and make the app the default.
Device nicknames
Tokens carry a nickname. It matters for the same reason it matters for passkeys: when somebody reports a lost phone, you need to know which token to remove without removing the others.
Prompt for it at enrolment.
Encourage a second token
A token on one device means one lost phone is a lock-out. A second on a tablet, or a backup within an app that supports it, turns that into an inconvenience.
Suggest it at enrolment — asking afterwards is asking people to do a task with no visible benefit.
Clock drift
Codes depend on time. A device whose clock has drifted produces codes that are consistently rejected while the user is certain they typed them correctly.
It is the commonest "2FA is broken" report and the fix is to enable automatic time on the device. Worth putting in your support notes, because it is otherwise baffling from both sides.
Removing a token
Treat it as an access request. Verify the person as rigorously as for a password reset — someone asking you to remove a second factor is asking you to weaken their account, which is exactly what an attacker would ask for.
Enrolment is the moment to get it right
Nickname the device, register a second token, and check the first code works before the user leaves the screen. Two minutes there prevents most later support.
Worked example
An organisation standardises on authenticator apps, with SMS available on request. At enrolment each user nicknames their device and is asked to add a second token. Over the following year the four lost-phone reports are each resolved by the user's second token, without administrator involvement.
Recommendations
- Default to an app; keep SMS as a fallback.
- Require a nickname at enrolment.
- Encourage a second token then, not later.
- Check clock settings when codes are rejected.