2-Factor Authentication

Enabling 2FA

Two-factor authentication asks for something beyond the password. It is the single most effective control available against stolen credentials.

Where to find it

Architect Panel → Configuration:

• Site Settings — Enable 2-factor Authentication, and the settings below it

Architect Panel → Security:

• Two-Factor Authentication — registered authenticator tokens
• Passkeys — the stronger alternative

What it protects against

A password that has been guessed, phished, reused from a breached site, or read off a note. In every one of those cases the attacker has the password and still cannot sign in.

Given that password reuse is near-universal, this is the control that turns somebody else's breach into a non-event for you.

What it does not protect against

A convincing fake sign-in page can ask for the code as readily as the password, and a user who types one will type the other. Two-factor authentication raises the cost of phishing considerably; it does not eliminate it.

Passkeys do, because the credential is bound to the real site and is simply not offered to a replica. Where you can use passkeys — particularly for administrators — they are the better control. Two-factor remains the right answer for everybody else and for anywhere passkeys are impractical.

Enabling it

Enable 2-factor Authentication makes it available. On its own it does not compel anybody — users can enrol, and those who do get the protection.

This is the right first step. Turn it on, ask people to enrol, and see who does before considering whether to require it.

Start with administrators

They are the accounts worth attacking, they are few enough to support individually, and they are the group most able to tell you if something is awkward.

Explain why, briefly

Enrolment rates depend almost entirely on whether people understand the point. "Your password may already be in a breach somewhere; this means that does not matter" gets more enrolments than a policy announcement.

Have a recovery path before you need one

People lose phones. Decide who can reset a second factor, how they verify the person asking, and what gets recorded — before anybody is locked out, not during.

Make that verification at least as rigorous as the factor it bypasses. An attacker who cannot phish a code will telephone your service desk instead, and a weak reset process quietly undoes the whole control.

Worked example

An organisation enables 2FA and asks administrators to enrol within a fortnight. All twelve do. It is then opened to all staff with a short explanation, reaching about 70% in a month. Only then does the organisation consider requiring it — with a clear picture of who is left and why.

Recommendations

• Enable it before forcing it.
• Administrators first.
• Prefer passkeys where practical, especially for administrators.
• Design and test recovery first.

Forcing 2FA

Requiring a second factor is the goal. Getting there without locking out your users depends on one setting that is easy to overlook.

Where to find it

Architect Panel → Configuration:

• Site Settings — Force Users to have 2FA Configured, and Allow 2FA Setup if Non-compliant

Architect Panel → Security:

• Two-Factor Authentication — who has enrolled
• Blocked User Accounts — where lock-outs surface

The two settings

• Force Users to have 2FA Configured — requires a second factor. Ships off.
• Allow 2FA Setup if Non-compliant — lets a user who has no token set one up. Ships on.

Why the second one is critical

Consider what happens when you force 2FA on a population where some people have not enrolled.

With Allow 2FA Setup if Non-compliant on, they sign in, are required to enrol, do so, and continue. Enrolment happens by itself as people arrive.

With it off, they are required to have a token, they do not have one, and they cannot create one. They are locked out, and the only way back in is for an administrator to intervene for each of them individually.

So: leave it on when you turn forcing on. It ships on, which is correct — the danger is somebody turning it off for the reasonable-sounding reason that self-service enrolment feels less controlled.

When turning it off is defensible

Where enrolment must be supervised — a high-security environment where somebody's identity is verified in person before a token is issued. That is a real requirement, and if you have it, expect the administrative load and plan the sequence: enrol everybody first, then force, then disable self-service.

Doing it in the other order locks out your entire user base at once.

Check enrolment before forcing

Look at how many people actually have a token. Forcing at 95% enrolment is a handful of supported conversations; forcing at 40% is an incident.

Force in stages

Administrators, then power users, then everybody. Each stage tells you what the next will bring, and problems surface at a scale you can handle.

Tell people first

A week's notice, a sentence on what to expect, and a link to instructions. Most of the support volume from a 2FA rollout comes from surprise rather than difficulty.

Watch the first morning

Monday between eight and ten is when you will learn whether it worked. Have somebody available who can help, and know in advance how to reverse the setting if something is badly wrong.

Worked example

An organisation reaches 96% enrolment voluntarily, announces the requirement a week ahead, and turns on forcing on a Tuesday with self-service enrolment left on. The remaining 4% enrol on their next sign-in without contacting anybody. Support handles three calls, all from people who had changed phones.

Recommendations

• Leave self-service enrolment on when you force 2FA.
• Check enrolment figures first — aim above 90%.
• Force in stages, administrators first.
• Announce it, and staff the first morning.

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.

SMS Codes

SMS sends a numeric code to a mobile number. It is the weakest second factor here and still far better than none.

Where to find it

Architect Panel → Configuration:

• Site Settings — SMS Time Limit, SMS Code Length and SMS Sender Name

Architect Panel → Activity:

• SMS Log — codes sent, with provider identifiers

Architect Panel → Communication:

• Message Log — the account codes are sent through

The three settings

• SMS Time Limit — how many minutes a code stays valid. Ships at 20.
• SMS Code Length — digits in the code. Ships at 6.
• SMS Sender Name — what the message appears to come from.

Consider shortening the validity window

Twenty minutes is generous. It is forgiving of slow message delivery, which is a real problem — but it also means a code intercepted, glimpsed on a lock screen, or left in a message list stays usable for a long time.

Five to ten minutes is enough for a person who is sitting at the sign-in page, which is the situation the code exists for. Shorten it unless you have evidence that delivery in your user population is genuinely slow.

Six digits is right

With a short validity window, six digits is ample — an attacker gets very few guesses before the code expires. Longer codes are harder to retype from a lock screen and buy little.

Set a recognisable sender name

Users should be able to tell your code from the several others they receive. A recognisable sender also makes fraudulent messages claiming to be you more obviously wrong.

Know the weaknesses

• SIM swap — an attacker persuades the network to move the number. This is the reason not to use SMS for administrators.
• Lock screen previews — codes are readable without unlocking the phone.
• Delivery — not guaranteed, and not instant.
• Cost — every sign-in is a chargeable message.

Where SMS is the right choice

For users who cannot or will not install an app, and for populations where a mobile number is already held and verified. For a public-facing service, SMS enrolment often succeeds where app enrolment does not — and a second factor people actually use beats a better one they abandon.

What it should not be is the second factor on an administrative account.

Watch the log and the volume

The SMS log holds the provider identifiers needed to trace a message somebody says never arrived. It is also where an unexpected bill is explained — 2FA volume scales with sign-ins, which rises quietly.

Worked example

A public service offers app-based 2FA with SMS as an alternative, and about a third of users choose SMS. The validity window is shortened from twenty minutes to eight after checking the log and finding delivery consistently within seconds. Administrators are required to use an app, so no privileged account depends on a phone number.

Recommendations

• Shorten the window to five to ten minutes.
• Never use SMS for administrators.
• Set a recognisable sender name.
• Review SMS volume alongside the log.