2-Factor Authentication

Enabling 2FA

Two-factor authentication asks for something beyond the password: a code from an authenticator app, a text message or an e-mail. It is the single most effective control available against stolen passwords.

Where to find it

Architect Panel → Configuration:

• Site Settings — whether 2FA is enabled and enforced, and the one-time code settings

Architect Panel → Security:

• Two-Factor Authentication — registered authenticator tokens
• Security Check-up — the Multi-factor authentication section: enforcement, methods offered and coverage
• Passkeys — the stronger alternative

Each person sets up their own methods on My Account, in the 2-Factor Authentication (2FA) card.

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. Where you can use passkeys, particularly for administrators, they are the better control.

The three methods

• Authenticator app (TOTP): the strongest of the three, and the one to recommend. See Authenticator Apps.
• SMS: a code by text to a verified mobile number. Weaker, because numbers can be hijacked.
• E-mail: a code to the address on the account. The weakest, because the same mailbox usually receives password resets. See E-mail Codes.

Which methods are offered, and in which order, is set in the server configuration by your hosting administrator rather than on Site Settings. The shipped order is authenticator app, then SMS; e-mail is offered only when added. When somebody has more than one method set up, they are asked for the first one in that order, so keep the authenticator app first.

Enabling it

1. In Site Settings, make sure 2FA is enabled. On its own this compels nobody: people can enrol, and those who do get the protection.
2. Open Security Check-up and read the Multi-factor authentication section. Methods offered shows what people can choose from.
3. Ask administrators to enrol first on My Account, then everybody else.
4. Watch the "accounts with an authenticator app" figure in the Security Check-up rise, and use its View accounts button to see who is left.
5. Only then consider requiring it: see Forcing 2FA.

How an assessor will read it

The Security Check-up marks 2FA that is available but not enforced as Action needed, because Cyber Essentials expects multi-factor authentication on administrative accounts. It marks enforcement for some groups only as Review, and e-mail codes offered as the only method as Action needed. Its coverage figure counts authenticator apps only.

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 rather than 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.

Turning off SMS or e-mail codes on My Account, or deleting an authenticator token, asks the person to prove who they are again first, so somebody who finds an unlocked, signed-in browser cannot quietly remove a factor.

Worked example

An organisation enables 2FA and asks its twelve administrators to set up an authenticator app within a fortnight; all do. It is then opened to all staff with a short explanation. The Security Check-up shows coverage reaching about 70% in a month, and View accounts lists the rest for their managers. 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, with an authenticator app or a passkey.
• Keep authenticator apps first in the method order.
• Track coverage in the Security Check-up.
• 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.

E-mail Codes

E-mail codes are the third way to receive a second factor, alongside authenticator apps and SMS. After the password is accepted, a one-time code is sent to the e-mail address on the account and must be typed in to finish signing in. It is the weakest of the three, and it is useful as a fallback for people who cannot use an app or receive texts.

Where to find it

Architect Panel → Configuration:

• Site Settings — the 2FA settings, including the one-time code length and time limit that e-mail shares with SMS

Architect Panel → Layout & Pages:

• E-mail Templates — the 2-Factor Authentication Code template that carries the code

Architect Panel → Security:

• Security Check-up — the Multi-factor authentication section, which reports whether e-mail codes are offered and how it rates them

Architect Panel → Activity:

• E-mail Log — each code e-mail that was sent, or failed

Each person switches e-mail codes on for themselves on My Account, in the 2-Factor Authentication (2FA) card.

Why it is the weakest method

A code sent to somebody's mailbox is only as strong as that mailbox, and the mailbox is usually also where a password reset goes. Somebody who controls the mailbox can therefore reset the password and receive the code, so e-mail is close to a single factor. Cyber Essentials does not recognise it as multi-factor authentication. Offer it so that nobody is left with no second factor at all, not as the method that satisfies an enforcement requirement.

Making it available

Which methods are offered, and in what order, is set by your hosting administrator in the server configuration; it is not on the Site Settings screen. The shipped list is authenticator apps then SMS. To offer e-mail codes:

1. Ask your hosting administrator to add e-mail to the list of 2FA methods, and to name the e-mail account the codes are sent from. Ask for an authenticator app to stay first in the list.
2. Open E-mail Templates and check the 2-Factor Authentication Code template. It puts the code in the subject and body, says how many minutes it lasts, and warns the reader not to enter it if they were not signing in. Open tracking is off on purpose: keep it off.
3. Open Security Check-up and confirm the Methods offered row now includes E-MAIL.
4. Switch it on for your own account and sign in once to test it before telling anybody else.

How a person switches it on

1. Open My Account and find the 2-Factor Authentication (2FA) card.
2. In the E-mail Codes column, check the address shown is right, then turn the switch on. The card confirms "2FA by e-mail is enabled on your account."
3. If the account has no e-mail address, or an address that is not valid, the switch is not offered and the card says why, with an Edit Profile button where an address can be added.

Turning e-mail codes off removes a factor, so the person is asked to confirm who they are again before the change is made.

Signing in with an e-mail code

After the password, the sign-in page says "We've sent a one-time authentication code by e-mail to" followed by a partly hidden address (the first letter, asterisks, then the domain), and asks for the code. A person with more than one method set up is asked for the first one in the order your hosting administrator set, which is another reason to keep authenticator apps first.

• Length and lifetime: e-mail codes use the same code length and time limit as SMS codes, 6 digits and 20 minutes as shipped. The Security Check-up shows them as One-time code length and One-time code validity.
• Single use: once a code is accepted, every other outstanding code for that account stops working.

What goes wrong

• "2FA by e-mail is not available on this site." E-mail is not in the methods list. Ask your hosting administrator.
• "There was a server error when attempting to send an authentication code by e-mail." The template or the sending e-mail account could not be found, or the send failed. The Error Log says which; check the E-mail Log for the attempt.
• The code never arrives. Check the E-mail Log for the message and its result, then the person's junk folder.
• Codes are visible to log readers. The E-mail Log keeps the subject and body of every message, including codes. They expire within the time limit and work once, but keep E-mail Log access to the few people who need it.

Worked example

A membership organisation enforces 2FA for staff with authenticator apps, but a few volunteers use shared or basic phones. The hosting administrator adds e-mail as a third method after TOTP and SMS. The volunteers switch on E-mail Codes on My Account and are protected against a reused password without installing anything. The Security Check-up marks E-mail codes as Review, offered alongside a stronger method, and the administrator records why it is offered.

Recommendations

• Never make e-mail the only method; the check-up marks that as Action needed.
• Keep authenticator apps first in the method order.
• Steer administrators away from e-mail codes; their accounts deserve an app or a passkey.
• Restrict who can read the E-mail Log.
• Shorten the code time limit if your mail delivers quickly; it applies to SMS too.