No. 07Week of September 23, 2026This week’s briefing
Tradecraft

Field guideNo. 01

Moving a bank off SMS OTP: the field guide

A step-by-step plan for retiring text-message codes: which flows go first, what replaces them, who owns each step, and what the markets that already did it can teach you.

By Reviewed by [REVIEWER NAME]Published 6 min read

For CISOs Fraud & risk IAM engineers Product & payments Compliance

The short answer

How should a bank move customers off SMS one-time passcodes?

Inventory every flow that sends a code, write the risk assessment NIST SP 800-63B-4 asks for, fix account recovery and new-payee setup first, then move customers to phishing-resistant or device-bound methods such as passkeys and in-app approval. Keep SMS only as a restricted fallback, with a dated plan to remove it.

If you read nothing else

  1. SMS codes aren’t banned in the US, but NIST lists them as “restricted”, with four conditions attached.
  2. Start with account recovery, new payees and contact-detail changes, where stolen access turns into money.
  3. There is no single replacement: most banks combine passkeys, in-app approval and carrier signals.
  4. The UAE’s regulator gave banks about nine months, from July 2025 to March 31, 2026.
Illustration of a fraud-operations desk with three monitors showing charts and alerts
A fraud-operations desk mid-migration: alerts, volumes and the one chart everyone watches. Illustration.

Why this is on your roadmap now

SMS codes are not banned in the US. NIST SP 800-63B-4 keeps them on the list of allowed authenticators as “restricted”, with conditions attached.[1] But Revision 4 also accepts synced passkeys as a phishing-resistant option at AAL2,[2] and regulators in several markets have already moved banks off text-message codes: Singapore for customers with digital tokens from July 2024,[3] the UAE by March 31, 2026,[4][5] and the Philippines for high-risk transactions from June 25, 2026.[6] Our regulations tracker keeps the full list.

The attack pressure is older than the rules. A one-time passcode works for whoever holds it within its validity window, which is why OTP bots and phishing pages ask customers for it in real time,[7] and why a SIM swap turns a phone number into a master key. The question for most banks is no longer whether SMS codes go, but which flows lose them first.

Step 1 Inventory every flow that still sends a code

Start with a list, not a vendor. Every place the bank sends a code is a place an attacker can ask a customer to read it out.

Tradecraft’s suggested ordering, based on where SIM-swap and code-relay fraud tends to cash out. Re-rank with your own loss data.
FlowWhy attackers target itSuggested priority
Account recovery and password resetResetting access hands over the whole accountFirst
Adding a new payee or beneficiaryWhere stolen access turns into a paymentFirst
Changing the phone number or email on fileCuts the real customer off from alerts and recoveryFirst
Enrolling a new device or appGives the attacker a lasting footholdHigh
Sign-in from an unrecognized deviceA common OTP-bot and phishing targetHigh
Payment step-upCodes can be relayed in real timeHigh
Routine sign-in on a known deviceLower value on its ownLater

For each flow, record the channel (SMS, voice or email), monthly volume [YOUR DATA], what happens when the code fails, and which team owns it. Email codes belong on the list: the UAE and Philippine rules retire both channels together.[4][6]

Step 2 Write the risk assessment NIST asks for

If you keep offering SMS or voice codes, 800-63B-4 attaches four obligations to that choice:[1]

  1. Offer an alternative that isn’t restricted, so no customer is stuck with SMS.
  2. Tell users the risks of the restricted option in plain language.
  3. Assess the risk to users and the organization of continuing to allow it.
  4. Keep a migration plan in case the authenticator is removed in a future revision.

US banks aren’t directly bound by NIST, and the FFIEC’s 2021 guidance is written in terms of risk rather than named methods.[10] Examiners and auditors do use NIST as a benchmark, so a dated, owned assessment is cheap insurance. Our NIST 800-63-4 field guide lists the evidence to keep.

Step 3 Pick a replacement for each flow

There is no single replacement. The options in Tradecraft’s sourced coverage fall into four groups, and most banks will use more than one.

Summary of Tradecraft’s explainers on passkeys, carrier authentication and NIST 800-63B-4.
OptionPhishing-resistant?Best fitWatch out for
Passkeys (synced or device-bound)YesSign-in and step-up on modern devicesSecurity of the sync account; older devices
In-app approval on a registered deviceDepends on the implementationCustomers who already use the bank’s appCustomers talked into approving a request they didn’t start
Carrier network checks (number verification, SIM-change signal)Not on their ownA risk signal before trusting a phone numberProves something about a SIM, not the person
SIM-based cryptographic authentication[EDITORIAL: confirm against NIST classification]Flows that depend on the phone number todayCarrier and market coverage

Singapore and UAE banks both moved customers to approval inside the bank’s own app, on a device the bank had already registered.[3][4] Carrier checks are standardized by the CAMARA project, which defines Number Verification and SIM Swap APIs,[8] and packaged commercially through GSMA Open Gateway.[9] Our SMS OTP alternatives buyer’s guide sets out evaluation criteria for each group.

Step 4 Fix account recovery before anything else

A passkey rollout that falls back to an SMS code for recovery hasn’t removed the weak link; it has moved it. Recovery is where passkey deployments get attacked.

  • Don’t let a code alone recover an account. Pair it with something the attacker is unlikely to hold, or replace it.
  • Check for a recent SIM change before trusting the phone number for recovery. Carrier SIM Swap APIs report this.[8]
  • Recover through what the customer already has registered, such as a second device or an existing passkey, where you can.
  • Slow down high-risk changes after recovery: a new payee or new phone number straight after a reset deserves a hold or a check. [YOUR POLICY: hold length]

Step 5 Migrate customers, with a date

The UAE is the clearest finished case. The Central Bank of the UAE set a window from July 2025 to March 31, 2026, and banks moved customers to in-app verification.[4][5] Three things stand out:

  • The timeline was months, not years. A defined deadline pushed the work to the top of the roadmap.
  • Email went with SMS. Both were treated as the same class of risk.
  • The replacement was already in customers’ hands. Approval in the bank’s own app avoided a new device or a new habit.

Tell customers what is changing and when, repeat that the bank will never ask for a code by phone, and give support teams a script before the first customer calls.

[PRACTITIONER QUOTE: a bank digital or fraud lead on customer communication during an SMS OTP migration, gathered in original reporting.]

[NAME], [TITLE], [INSTITUTION]

Step 6 Harden SMS while it remains

For as long as codes stay as a fallback, make each one harder to abuse. These controls come from our OTP bot explainer:

  • Say what the code approves (“to add payee J. Smith”) and that the bank will never ask for it.
  • Watch the timing: a sign-in from a new device while the customer is on an inbound call is a strong fraud signal.
  • Check the SIM before sending a code for a high-risk action.
  • Never make SMS the only path for recovery or new-payee setup.

Step 7 Measure the migration

Pick a small set of numbers and report them monthly. We don’t publish benchmark figures we can’t source, so the targets are yours to set.

Suggested measures. Tradecraft does not publish industry benchmarks for these.
MeasureWhy it mattersTarget
Active customers enrolled in a non-SMS methodShows whether the alternative is real[YOUR TARGET]
SMS codes sent per month, by flowShows which flows still depend on SMS[YOUR TARGET]
Fallback rate to SMSReveals where the new method fails[YOUR TARGET]
Account-takeover cases by channelShows whether fraud is moving[YOUR TARGET]
Sign-in support contactsEarly warning of friction[YOUR TARGET]

Who owns this

A suggested split: R responsible, A accountable, C consulted, I informed. Adjust to your organization.
ActivityCISOFraud & riskIAM eng.ProductComplianceSupport
Flow inventoryACRCII
NIST risk assessmentACCIRI
Choosing replacementsACRCCI
Recovery redesignARRCCC
Customer migration and commsICCA/RCR
Hardening SMS fallbackCA/RRCII
Measurement and reportingARCCCI

How long it takes

Questions readers ask

Does NIST 800-63-4 ban SMS OTP?

No. It classifies SMS and voice codes as restricted: still allowed, but only with a risk assessment, user notice, a non-restricted alternative and a migration plan.

Which flows should move off SMS first?

Account recovery, new-payee setup and changes to a customer’s phone number or email. Those are the steps where a hijacked number or a relayed code turns into a payment or a locked-out customer.

What are banks replacing SMS OTP with?

Mostly passkeys, approvals inside the bank’s own app on a registered device, and network-based checks run with the customer’s mobile carrier.

Is email OTP a safe alternative to SMS?

Not really. Email codes can be phished the same way, and the UAE and Philippine rules phase out both together.

Sources

  1. NIST SP 800-63B-4: Authentication and Authenticator Management
  2. FIDO Alliance NIST cites phishing resistance of synced passkeys in digital identity guidelines update
  3. Monetary Authority of Singapore Banks in Singapore to strengthen resilience against phishing scams (2024-07-09)
  4. The Paypers UAE banks cancel OTPs, switching to in-app verification
  5. BankInfoSecurity UAE central bank tells FIs to drop SMS OTP authentication
  6. GMA News No more SMS, email OTPs for high-risk financial transactions starting June 25
  7. BankInfoSecurity One-time passcodes are gateway for financial fraud attacks (2026-04-03)
  8. Linux Foundation CAMARA project
  9. GSMA GSMA Open Gateway
  10. FFIEC Authentication and Access to Financial Institution Services and Systems (2021-08-11)

Changelog

  • : First edition, assembled from Tradecraft’s sourced explainers. Awaiting editorial verification.

Cite this

Tradecraft. “Moving a bank off SMS OTP: the field guide.” Tradecraft, September 24, 2026. https://glide-tradecraft.pages.dev/field-guides/moving-a-bank-off-sms-otp/

Read next

Buyer’s guide

SMS OTP alternatives: a buyer’s guide

There is no single best alternative for every flow. Passkeys are the most widely standardized phishing-resistant option and are accepted by NIST at AAL2. In-app approval on a registered device is what UAE and Singapore banks moved customers to. Carrier network checks are useful risk signals, and SIM-based cryptographic methods are emerging. Most organizations combine two or more.

Field guide

Rolling out passkeys to retail banking customers

Decide which passkeys you accept for which customers, offer enrollment right after a strong sign-in, make passkeys the default for returning users, and design account recovery that doesn’t fall back to an SMS code. Keep a non-SMS alternative for customers who can’t use passkeys, and a device-bound option for staff and other high-risk users.

Take the checklist

Checklist

SMS OTP flow inventory

Every place your organization still sends a code, ranked by where fraud cashes out.

Terms in this piece