One-time codes by text: what NCSC and the fraud data say

Six digits, a buzz in your pocket, and you are in. The code by text is the most common second factor there is, and it is also the one every security body puts at the bottom of its list. NCSC's guidance for organisations ranks message-based methods fifth of five. NIST's 2025 revision of its authentication standard labels the mobile network a restricted channel and says a code sent over it is invalid after ten minutes. And UK Finance's members reported £1.28 billion stolen through payment fraud in 2025, some of it by people who got hold of someone else's codes.

A business can still send codes by text. The code should do the job it is good at, within the limits the guidance sets, and nothing more. What follows is what the documents say, with the dates, so you can decide where a text code belongs in your sign-in.

What NCSC has said, in four documents

NCSC's advice to individuals, "Setting up 2-step verification", was published on 7 August 2018 and last reviewed on 10 January 2022. It is the friendliest of the four. "Most services tend to offer 2SV over text message by default," it says, and then: "Text messages are not the most secure type of 2SV, but still offer a huge advantage over not using any 2SV." Its headline is in bold on the page: any 2-step verification is better than not having it at all. Authenticator apps are "the main alternative to text messages", with not needing a mobile signal as one advantage.

The advice to organisations is cooler. "Multi-factor authentication for online services", version 2.0, reviewed on 26 September 2024, has a companion page listing the recommended types in order. First, FIDO2 credentials on trusted platform devices or roaming keys. Then challenge-based authenticator apps, app-based code generators, hardware code generators, and, fifth, "Message-based methods (email, SMS and call-based)". The verdict on that last category is one sentence: "Message-based methods are only likely to be appropriate when no other strengthening method is possible." The example it gives is a legacy system that cannot support anything else.

Between the two sits "Authentication methods: choosing the right type", published on 21 September 2022 and reviewed on 12 June 2025, which is written for anyone authenticating customers. It calls a PIN sent by SMS "the most widespread and well-understood second factor, but is not the most secure option", and its practical advice is to offer a choice: "Providing your users with a choice of second factors will ensure you cover the widest customer base." It also says a second factor should be asked for at the moments that matter, such as transferring large sums, changing a password or changing account details, and when something looks suspicious. Its table on one-time passcodes says they suit a service where security is not highly critical and user experience matters as much, and suit less well a service where security is the top priority or where the mobile network's own security is in doubt.

The fourth document is the blunt one. NCSC's paper comparing traditional credentials with FIDO2, published on 23 April 2026, says that "all traditional / classical multifactor authentication including passwords, SMS codes, email codes, TOTP codes" and "TOTP tokens and notification approval systems are inherently phishable". It names the attacks on codes by text: "attackers conduct SIM-swap attacks to gain access to codes sent by SMS", and "malware on Android devices can intercept and capture SMS authentication codes". So the position across eight years is consistent. A text code beats nothing. An app or a passkey beats a text code. And a text code, like an app code, can be phished, because a person can be talked into typing it somewhere.

What NIST requires

NIST's Digital Identity Guidelines are the standard most of the world's authentication rules borrow from, and the authentication volume, SP 800-63B, was reissued as revision 4 in July 2025, superseding the edition in force since 2020. Section 3.1.3.3, "Authentication Using the Public Switched Telephone Network", covers codes sent by SMS or voice, and its first line is the one everyone quotes: "Use of the PSTN for out-of-band verification is restricted as described in this section."

Restricted is a defined status, set out in section 3.2.9, and it carries four duties. The provider "SHALL do all of the following": offer subscribers at least one alternative authenticator that is not restricted; provide meaningful notice of the restricted authenticator's security risks; address the extra risk in its risk assessment; and develop a migration plan for the possibility that the restricted authenticator will not be acceptable in the future. If the organisation relying on the login decides the risk is unacceptable, the restricted authenticator "SHALL NOT be used". For the phone network in particular, verifiers "SHALL ensure that alternative authenticator types are available to all subscribers" and "SHOULD consider risk indicators (e.g., device swap, SIM change, number porting, other abnormal behavior) before using the PSTN".

The mechanics are in the same section and they are useful whatever channel you use. The code must be at least six decimal digits, generated by an approved random bit generator. If it carries fewer than 64 bits of entropy (every six-digit code does) the verifier must rate-limit attempts. And "the authentication SHALL be considered invalid unless completed within 10 minutes". NIST's threat table is also where SIM swap appears, under social engineering: "An attacker who has convinced the mobile operator to redirect the victim's mobile phone to them" and so receives the code.

What the fraud figures show, and what they don't

UK Finance publishes the only running series on UK payment fraud. Its press release of 15 June 2026 put £1.28 billion stolen in 2025, up four per cent on the year. Authorised push payment fraud, where the victim is talked into sending the money, rose 19 per cent to £576.4 million across 248,070 cases. Unauthorised fraud, where the criminal uses the card or account without the customer, fell five per cent to £703.4 million across 3.81 million cases. The industry says it prevented a further £1.68 billion of unauthorised fraud.

The year before, from the press release of 28 May 2025, the total was £1.17 billion, APP fraud £450.7 million across under 186,000 cases, and unauthorised fraud £722 million across 3.13 million cases. So the money moved from unauthorised to authorised, which matters for codes: a one-time code does nothing against a scam where the customer makes the payment themselves, and that is now the larger half.

Within unauthorised fraud, the category where a text code sits between the criminal and the account is remote banking: a login the customer did not make. UK Finance put 2025 remote banking losses at £104.4 million, down 27 per cent, across 37,646 cases. Remote purchase card fraud was far larger at £423.5 million, lost and stolen cards £109.8 million, contactless £46.8 million.

Where the fraud starts is the other number worth having. In 2025, 66 per cent of APP cases began online and 17 per cent through telecommunications (calls and texts), but the telecoms cases accounted for 28 per cent of the money against 32 per cent for online. In 2024 the online share of cases was 70 per cent and the telecoms share 16 per cent. A scam by phone or text takes more per victim.

What none of these publications give is a count of SIM swap frauds. Ofcom's February 2022 statement on scam calls and texts describes the attack in a paragraph, "the scammer tricks a mobile provider into providing a new SIM card for an account that does not belong to the scammer", notes that it "may then allow the scammer to access one-time security passcodes", and records a commitment from the mobile providers to supply financial firms with a real-time check on whether a number has recently been SIM-swapped. There is no published UK figure for how often it happens, and we have not used one.

Using codes by text sensibly

Decide what the code protects. NCSC's customer authentication guidance puts a second factor at high-impact moments: moving money, changing a password or contact details, and anything that looks odd. A text code at those points, with no second factor at all elsewhere, is the pattern NCSC describes. For an account that holds money or medical records, NIST's position is that a text code must never be the only option.

Offer a second route. Both NCSC ("a choice of second factors") and NIST ("at least one alternative authenticator that is not restricted") want the person to be able to pick an authenticator app or a passkey instead. The text stays for the customers who will not install an app, and NCSC's own advice to individuals says that is still a huge advantage over nothing.

Build the code the way NIST describes. At least six random digits, ten minutes at most, a small number of attempts before the code is void, a small number of resends before the sign-in is paused, and a note in your logs when a code goes to a number that was changed on the account in the last few days. NIST's risk indicators (device swap, SIM change, number porting) are exactly the signals a SIM swap leaves.

Write the text so it cannot be mistaken for a scam. NCSC's guidance on business SMS, published on 19 January 2022 and reviewed on 31 October 2023, asks for a consistent sender name that reflects your brand (not "Alert" or "NoReply"), no links where you can avoid them and never a shortened one, no language that creates panic or urgency, and a clear public statement of what you will never ask for. A code text that follows all of that looks like this:

Fernway: 482913 is your sign-in code. It expires in 10 minutes. We will never call or text to ask you for it.

The code near the front, the purpose, the life, the warning, no link. Register the sender name, and check your provider does the same through the MEF registry; our guide to UK sender IDs covers the review.

Protect the sending side. The same NCSC guidance tells you to keep the API that triggers texts off the public internet, validate the number format on input, limit retries and watch for sudden spikes. A signup form that will text any number it is given is the target of the pumping fraud described in our post on SMS pumping, and the first defence is sending only to the country you serve.

CaptiFi Connect's part in a code flow is delivery: your application generates the code, stores it and checks it, and the verification codes use case walks through sending it with an Idempotency-Key so a retry cannot send the same code twice, and a signed webhook when a text fails so your app can offer another route at once. Texts go to UK mobiles only, which rules out the overseas ranges pumping fraud relies on.