Replacing SMS OTP in banking apps

The failures are not exotic. They are routine, they are cheap to run at scale, and none of them require breaking any cryptography.

• SIM swap. An attacker persuades a mobile operator to move the customer’s number to a SIM they control. Every code then arrives on the attacker’s handset. The bank sees a correct code entered from a plausible device, because from its side nothing is wrong.
• Real-time phishing. A proxy site sits between the customer and the bank, relays the login, prompts for the code the bank just sent, and replays it within its validity window. The code is single-use and short-lived, and neither property helps: the attacker only needs it once, immediately.
• Interception in transit. SMS is delivered through interconnect networks with weak authentication between operators. Messages can be redirected or read without touching the customer’s device at all.
• Device malware. On a compromised handset, an application with SMS read permission forwards codes as they arrive.

The structural problem underneath all four is that an OTP is a shared secret in transit. It is generated somewhere, transmitted, and then typed by a human who has no way to tell whether the site asking for it is genuine. Every mitigation — shorter validity, rate limiting, device fingerprinting — narrows the window without changing that shape.

Supervisory language differs by market, but the direction is consistent. Authentication on a digital channel is expected to use more than one independent factor; the factors are expected to be genuinely independent, which is where a code delivered to the same handset that runs the banking app becomes difficult to defend; and for payment instructions, the authorisation is increasingly expected to be bound to the specific transaction rather than being a generic approval.

That last expectation — often described as dynamic linking — is the one SMS OTP handles worst. A six-digit code carries no information about what it is approving. If an attacker changes the beneficiary and the amount after the code is issued, the code is still valid, because it was never tied to either.

For the specific wording, thresholds and references in each market, see the regulator compliance mappings.

Four replacements are realistic for a retail bank today. They are not equivalent, and the differences matter more for some channels than others.

For a retail base measured in millions, hardware tokens fail on cost and logistics before any security discussion. Voice biometrics is a strong additional signal in a call centre or a voice-driven flow, but is not a general replacement for a login factor. The practical choice is between passkeys and push approval, and the deciding question is whether you need resistance to real-time phishing.

Push approval sends a prompt to a trusted app rather than a code over a network, which removes interception and SIM swap. It does not remove the human in the loop: a customer who has just been telephoned by someone claiming to be the fraud team will approve the prompt. Passkeys close that gap differently — not by asking the customer to judge, but by making the credential unusable anywhere except the origin it was created for.

A passkey is a public-private key pair created on the customer’s device during enrolment. The private key stays in the device’s secure hardware and is never transmitted. The bank stores only the public key. At sign-in the bank sends a challenge; the device signs it, after the customer authorises with a face, fingerprint or device PIN; the bank verifies the signature against the public key it holds.

Three consequences follow, and they are the whole argument:

• Nothing to phish. There is no code and no password to disclose. The secret never leaves the secure element.
• Nothing to breach at scale. The server side holds public keys. A database disclosure yields no credential an attacker can use.
• Origin binding. The browser or operating system will only offer a credential to the origin it was registered against. A proxy site on a lookalike domain is not offered the credential at all, so the real-time phishing flow that defeats OTP has nothing to relay.

Transaction binding uses the same mechanism: the challenge includes the payment detail shown to the customer, so the signature attests to that specific instruction rather than to a generic session.

No retail bank replaces its second factor across an entire base at once, and no regulator expects it to. The workable pattern runs passkeys alongside the existing OTP path and shifts traffic as enrolment grows.

• Enrol opportunistically. Offer passkey enrolment after a successful OTP authentication, when the customer is already verified and the friction is lowest. Do not put it behind a settings menu.
• Prefer, do not require. Once a customer has a passkey, make it the default path for that device, with OTP available as recovery.
• Instrument the fallback. Track how often enrolled customers still fall back to OTP and why. A persistently high rate usually points at a specific device or channel gap, not at customer reluctance.
• Close channels deliberately. Retire OTP per channel as coverage allows, rather than globally. Web and mobile app typically reach viable coverage well before ATM and card-not-present flows.
• Keep an account recovery story. The hardest problem is not enrolment; it is a customer who has lost every enrolled device. Decide that flow before launch, because it will otherwise be decided under pressure at the call centre.

• Inventory every channel that currently issues an OTP, including ATM and 3-D Secure.
• Decide the recovery flow, and who is authorised to run it, before enrolment opens.
• Define the step-up policy: which actions require a fresh authentication, and which require transaction binding.
• Agree what is logged for each authentication, and how long it is retained.
• Confirm where credential metadata is stored, against your market’s residency requirement.
• Instrument enrolment rate, fallback rate and authentication failure rate per channel from day one.
• Brief the contact centre before launch — most early friction surfaces there first.

FortAuth implements the passkey path described above across mobile app, web, ATM and 3-D Secure from a single credential, with the enrolment, recovery and step-up flows already built. It runs alongside an existing OTP path during migration rather than replacing it on a single date, and every authentication is written to an exportable audit trail. Control mappings for each market are on the compliance pages.