Your Six-Digit Code Is Not Stopping Anyone Anymore

The login page became the cheapest door into a small company

Ask how a business gets robbed in 2026 and most owners picture something physical: a break-in, a pallet that never arrives, a supplier who disappears with a deposit. The reported numbers point somewhere duller. In its 2025 Internet Crime Report, the FBI's complaint centre logged 1,008,597 complaints and $20.877 billion in losses, a 26% rise on 2024, with an average reported loss of $20,699. Cyber-enabled fraud alone accounts for 85% of those losses.

Two categories matter for this article. Business email compromise, where an attacker writes to you from a mailbox that looks like a supplier or a director, produced 24,768 complaints and $3.05 billion in losses in 2025, up from $2.77 billion in 2024. Phishing and spoofing was the single most-reported crime type of the year at 191,561 complaints. And the report has a descriptor it did not have a few years ago: complaints tagged as AI-related reached 22,364, with $893 million in losses attached.

None of that is a reason to panic, and it is not a prediction about your company. It is a description of where the money is going, and the reason it goes there is structural. A break-in needs your building. A fraudulent transfer needs only one mailbox, and a mailbox needs only one valid session.

Which is why the six-digit code deserves a closer look. The attack it was designed against is simple credential theft: someone guesses or buys your password and logs in. SMS codes raise that cost. They do not stop the attack that actually gets used now, which is a proxy. The attacker stands between you and the real website: you land on their copy, it asks for your password and your code, and it passes both to the real site within seconds. The code was valid, the login was real, and the session that opened belonged to them. No malware, no cracked encryption, no insider. A convincing page and a phone that buzzes on cue.

That is what "phishing-resistant" is meant to exclude, and it is why the standards bodies stopped treating text messages as an acceptable second factor for anything that matters.

What phishing-resistant means, in NIST's own words

The reference document here is NIST Special Publication 800-63B-4, the authentication volume of the US Digital Identity Guidelines. It was approved by NIST's editorial review board on 30 May 2025 and supersedes the 2017 version. It is written for US federal systems, so it binds nobody in Madrid or Manchester — but it is the technical yardstick everyone else copies, and it is unusually blunt.

At authentication assurance level 2, the level most business systems would sit at, the verifier "SHALL offer at least one phishing-resistant authentication option". At level 3, a phishing-resistant authenticator is required, along with a key that cannot be exported. And on one-time passcodes the document is not ambiguous: in both the single-factor and the multi-factor OTP sections it states that "OTP authentication is not phishing-resistant".

NIST publishes a companion table of authenticator types that makes the hierarchy visible at a glance. "Out-of-band device" — the row where SMS and push notifications live — is marked as replay-resistant but not phishing-resistant. The same table marks "multi-factor cryptographic", the row containing FIDO2 passkeys with user verification, as both. The row for key exportability is just as direct: permitted at levels 1 and 2, prohibited at 3.

The Cybersecurity and Infrastructure Security Agency says the same thing in one sentence in its phishing-resistant MFA fact sheet: "The only widely available phishing-resistant authentication is FIDO/WebAuthn authentication." It then describes the two shapes that exist in practice. Roaming authenticators are separate physical tokens you plug in over USB or tap over NFC. Platform authenticators are built into the laptop or phone you already own. Passkeys are the second kind, and the ones synced through a cloud keychain are also the first, because a security key can hold them too.

The mechanism is worth understanding, because it explains why the fix is durable rather than another layer to bolt on. With a passkey, your device holds a private key and the website holds the public one. When you sign in, the site sends a challenge, your device signs it, and the signature only validates on the domain it was created for. A copy of the site on an attacker's domain gets a signature for the attacker's domain, which is worthless. There is no shared secret to type, so there is nothing to relay in real time. The FIDO Alliance's own definition is compact: passkeys are FIDO2 credentials, unlocked with the same biometric, PIN or pattern you use on the device, and built on the WebAuthn standard that browsers implement natively.

The arithmetic for a twelve-person company

Numbers make this decision easier than arguments, so here is a worked example. Every input below is an assumption I am stating, not a measurement. Swap in your own and the shape holds.

Start with the cost of doing nothing. The FBI's 2025 figures divide out to roughly $123,000 per business email compromise complaint ($3.05 billion across 24,768 complaints) — an average dragged up by large victims, so treat it as an order of magnitude, not a forecast. A twelve-person firm that pays one fraudulent invoice of $8,000 and spends forty hours of management time on the recovery has lost $8,000 plus about $1,600 of loaded time at $40 an hour, plus whatever the bank does not return. One incident in five years is enough to make the whole exercise below look cheap.

Now the daily friction, which is what owners actually feel. Assume each of the twelve people resets a password or waits for an SMS code that never arrives twice a month, and each episode costs fifteen minutes including the interruption to whoever helps. That is 12 × 2 × 0.25 = 6 hours a month, or 72 hours a year, of pure overhead. The FIDO Alliance's passkey page cites its Passkey Index reporting an 81% reduction in login-related help desk incidents after deployment, and while that figure comes from the industry promoting the technology rather than from an independent trial, the direction is consistent with everything else published about password resets.

Then the roll-out, priced honestly. Two FIDO2 security keys per person — one on the keyring, one locked in the office as backup — at roughly $50 each, so $100 per person, $1,200 for twelve people. Enrolment takes about twenty minutes per account per person in practice, and most people have three accounts that matter: email, the file store or SSO, and the accounting package. That is an hour per person, twelve hours of staff time, plus an afternoon for whoever administers the tenant. Total first-year cost for the firm, assuming $40 an hour: $1,200 in hardware, $480 in labour for enrolment, call it $2,000 with slack for the accounts that fight back.

Put the two columns side by side. $2,000 once, against 72 hours a year of reset overhead worth about $2,880 and a single $8,000 fraud that wipes out the comparison entirely. The hardware is not even strictly necessary: if everyone already carries a phone that supports passkeys, the $1,200 drops to zero and the case gets stronger. The security keys matter for the two or three people who administer systems, because a device-bound key cannot be phished and cannot be cloned from a cloud backup.

What that arithmetic does not capture is the part that makes it worth doing first: a compromised mailbox in a small firm is not a single bad day. It is the attacker reading six months of invoices, learning who approves what, who is on holiday and which supplier changed banks in March, and then waiting for the right moment. The recovery time for that is measured in weeks, and the trust you lose with the customer whose invoice was redirected does not appear on any balance sheet.

What to switch, and in what order

Not all second factors are equal, and the ranking is not a matter of taste. CISA's guidance for small and medium businesses orders them from most to least secure: a physical security key first, then an authenticator app with number matching, then an authenticator app with a one-time code, then biometrics, and last a code by text or email, which it describes as providing "the weakest protection" and recommends only when nothing stronger exists for that account.

The order to work through is the same one CISA recommends for phasing: protect what is worth stealing and start where the vendor already supports FIDO. In practice that means the mail tenant first, because it is the account that can reset every other account, and hosted mail and single sign-on are the two places where support is nearly universal. Then the identity provider or directory, if you have one. Then the bank and the accounting package, which are the accounts that can move money. Then the domains, hosting and social accounts, which are the ones nobody remembers until the renewal invoice goes to an address that no longer exists.

Two details decide whether the roll-out sticks. First, recovery: enrol each person's phone and issue a backup key that lives in a drawer, because the fastest way to abandon passkeys is to lose access on a Monday morning with a customer waiting. Second, remove the downgrade path. If the tenant still allows "send me a code instead" on the login screen, an attacker will choose that option for you, and the security key you bought becomes decoration. Turn the fallback off for the accounts that matter and keep it documented as an exception where a system genuinely cannot do better — CISA is explicit that some systems will not support phishing-resistant MFA and that you should not let them stall the rest of the plan.

The part passkeys do not fix: the payment itself

There is a gap in all of this, and it is not in the cryptography. A passkey proves that the person clicking approve is the person who owns the device. It says nothing about whether the request they are approving is real. If an attacker never needs your login — because they can call your bookkeeper as your biggest supplier and ask, politely and convincingly, for an urgent change of bank details — a perfect authentication layer is irrelevant. That attack does not break in. It asks.

Reports to the FBI put business email compromise at $3.05 billion in 2025, the second-largest loss category after investment fraud. A meaningful share of those cases end with a legitimate employee making a legitimate transfer to an illegitimate account. The only control that catches it is process, and the process is cheap:

1. Write down which payments need two people, by amount, and make that rule visible to whoever pays the invoices.
2. Verify any change of bank details by calling a number you already had on file, never the number in the email that requested the change.
3. Require the second approver to sign off in the accounting system, not by replying "ok" to an email thread.
4. Keep a list of supplier phone numbers, maintained by someone who is not the person who pays them.
5. Agree in advance, in writing, what your firm will never do — send card details by email, take new bank details over WhatsApp, skip verification because the director is travelling.
6. Test it once a quarter with a fake request from a colleague, and thank the person who flags it out loud.

Two of those steps cost nothing and would have stopped most of the cases in the reports. The reason they are not standard in small firms is not cost. It is that they imply the owner might be tricked, and nobody likes writing that down. Write it down anyway: the rule protects the bookkeeper from having to make a judgement call under pressure from someone who sounds exactly like the boss.

When not to do this yet

Passkeys are not a universal upgrade, and a small firm that rolls them out badly ends up worse off than one that never started — locked out, with a queue of angry people and a half-migrated tenant. Four situations should make you wait or change the plan.

The first is a system that cannot do it. Old on-premise ERPs, workshop software, some point-of-sale terminals and a surprising number of supplier portals still authenticate with a username and a password, full stop. Buying security keys for a system that will never accept them is a waste; document the account as an exception, restrict what it can reach, and put the effort into the systems that do support FIDO.

The second is shared accounts. If four people log into the same mailbox as admin@, a passkey belongs to one device, and the moment the person who enrolled it is on holiday the account is unreachable — or, worse, everyone keeps using the password instead and the passkey protects nothing. Create named accounts first, then enrol. This is the step that makes the whole project slower than expected, and skipping it is why roll-outs get abandoned.

The third is a missing recovery plan. Device-bound keys do not sync: lose the key and you lose the login. Synced passkeys ride on a cloud account, so the security of your business login becomes the security of whoever holds that account — which is fine for most people and worth thinking about for the two accounts that can wire money. Either way, two enrolled devices and one key in a drawer, before anything is switched off.

The fourth is a team that has not been told why. CISA's own guidance treats resistance as a communications problem, not a technical one: explain the risk, get the decision made at the top, then migrate in phases starting with the people whose accounts are most valuable. In a firm of twelve that is one meeting and one afternoon. In a firm where the owner announces it by email and disappears, it is six weeks of people quietly using the SMS fallback.

If none of those four apply, the cost of waiting is the interesting one. The hardware does not get cheaper in any way that matters, the standards are not going to change their mind about text messages, and the only variable that moves is how long your mailbox stays as easy to take as it is today.

Frequently asked questions

Are passkeys safer than a password plus an SMS code?

Yes, for the attack that is actually used. NIST's authenticator table marks SMS and push codes as not phishing-resistant and FIDO2 passkeys with user verification as phishing-resistant, and CISA states that FIDO/WebAuthn is the only widely available phishing-resistant option. A passkey cannot be typed into a fake page, because the signature is bound to the real domain and the private key never leaves your device. What passkeys do not fix is a person approving a fraudulent payment after a convincing phone call, which is a process problem.

Do passkeys cost anything for a small company?

Usually not per person. If your staff already have phones and laptops that support passkeys, the software cost is zero and the cost is enrolment time, roughly an hour per person for three accounts. Physical FIDO2 security keys cost around $50 each, and two of them for the three or four people who can approve payments is the only spend most small firms need. The systems themselves — mail, identity provider, accounting — need to support passkeys, and most hosted ones already do.

What happens if someone loses their phone or security key?

They use the second enrolled device, or the backup key that lives in the office, and then re-enrol. That is why the recovery plan comes before the migration and not after: device-bound keys never sync, and synced passkeys depend on the cloud account that holds them. Enrol two devices per person at the start and the lost-phone scenario costs ten minutes instead of a day.

Can I keep SMS codes as a backup option?

You can, and you should assume someone will use it if it is there. Leaving the fallback enabled means the weakest factor becomes the effective security level of the account, because an attacker will simply choose it. CISA recommends number matching as an interim mitigation where phishing-resistant MFA is impossible; treat SMS as a documented exception for specific legacy systems, not as the default path for everyone.

Does changing logins help if the fraud comes by email or phone?

Partly. Strong authentication closes the mailbox takeover route, which is how most business email compromise starts and how an attacker gets the context — suppliers, amounts, holidays — to make a later request convincing. It does not close the request itself. Pair the migration with a rule that any change of bank details is verified on a previously known phone number, and with two-person approval above an amount you choose.

How long does the roll-out take in a firm of ten to twenty people?

An afternoon for the accounts that support passkeys, plus the time it takes to clean up shared logins — and that second part is where projects stall. Named accounts first, then enrolment by priority: mail, identity provider, banking and accounting, then domains and hosting. Announcing it and disappearing is the failure mode; one meeting explaining the risk is usually enough to carry the rest.