🔑 Authenticating without one-time passcodes

Why SMS codes are being phased out

An SMS one-time passcode is a short-lived string of digits that the issuer sends to the mobile number it has on file for the cardholder. The cardholder types it into the payment page. This code carried Europe's 2019 compliance push because it asked nothing of cardholders: no app to install, no enrollment, no new device. The move away from it is being decided by the networks and issuers, not by any regulatory ban. In the European Economic Area, the European Banking Authority's opinion of June 21, 2019, counts the SIM card as a valid possession element. An SMS code therefore remains formally compliant when paired with a second factor. Three things explain its retreat: the cost of the channel, how easily fraudsters obtain the code, and the roadmaps the networks have published.

An SMS code is a shareable secret. Anyone who learns it can use it, and nothing in the code ties it to the site where it is entered. That opens three attack paths, none of which requires cryptographic skill. In a fraudulent SIM swap, the number is moved to a device the attacker controls, which then receives the messages meant for the cardholder. Malware installed on the phone reads the notification in the cardholder's place. The third path is the cheapest for the attacker, because it involves no technical means at all. A phone call is enough: the victim reads the code out to a fake bank representative.

The cost of the channel has two components. Application-to-person SMS is billed per message and per country, under carrier and aggregator rate cards that issuers have little leverage to negotiate. On top of that comes a fraud specific to the channel: artificially inflated traffic. An attacker triggers mass code sends to number ranges whose termination fees they share. In effect, the attacker bills the attack to the victim. Neither carriers nor issuers publish the volumes involved. Application-to-person messaging providers document the mechanism. A poorly protected sign-up form then becomes a recurring expense for as long as code sends can be triggered unchecked.

Regulators have taken different positions. The European Economic Area has imposed no ban. The joint report by the European Banking Authority and the European Central Bank published on December 15, 2025, finds lower fraud on authenticated transactions, but that finding comes with no binding measure. Outside Europe, several central banks have moved faster. The Reserve Bank of India opened authentication to device-bound passkeys and biometrics, effective April 1, 2026. Bank Negara Malaysia ruled out SMS codes as a standalone second factor in late 2025. An issuer operating in several of these regions can therefore no longer offer the same method everywhere: the SMS code, still acceptable in the European Economic Area, satisfies neither India's directions nor Malaysia's policy.

The networks' timelines take the form of commercial commitments with distant deadlines. In June 2024, Mastercard committed to fully tokenizing European e-commerce by 2030. Manual card number entry and one-time passcodes would disappear on the same timeline. In 2024, Visa announced its own payment passkey service, built on the FIDO specifications. Neither announcement creates any obligation. They do show where the networks are putting their investment, and therefore which new features will arrive first and which issuers will offer them first.

Passkeys and FIDO: what counts as possession and what counts as inherence

A passkey is a cryptographic key pair created by an authenticator for a specific site and a specific account. It is defined by WebAuthn, a W3C specification that the FIDO Alliance combines with its own specifications under the FIDO2 name. The private key stays in the authenticator: the phone's secure element, the computer's trusted platform module, or a plug-in security key. It is never sent to the site, and a device-bound passkey never leaves the hardware that created it. The site stores only the public key, the credential ID, and a few pieces of metadata. For each authentication, the authenticator signs a challenge supplied by the site, along with the calling origin and a set of status flags. The server verifies that signature with the public key it has stored since enrollment.

Phishing resistance comes from checking the calling domain, first in the browser and then on the server. Each passkey carries a relying party ID, which is a domain name. The browser refuses to offer the passkey to a page whose domain does not match, and it includes the actual origin in the signed data. The server then compares that origin with the one it expects. The comparison fails as soon as an attacker relays the ceremony from another domain, however closely that domain resembles the legitimate one. Skipping this comparison throws away the very property that justified moving to FIDO, leaving nothing more than a biometric check with no guarantee of origin.

Passkeys fall into two categories based on how they are stored. A synced passkey is backed up to the platform provider's keychain and follows the user's account from one device to another. A device-bound passkey never leaves the hardware that created it. WebAuthn exposes this distinction to the server through two flags: backup eligibility and current backup state. Both flags reach the server at enrollment. An issuer that requires a possession factor tied to a device can therefore reject synced passkeys before any payment is made.

Independence of elements is governed by Article 9 of the same delegated regulation. It allows both factors to run on a single multipurpose device, provided that mitigating measures, including separate secure execution environments, prevent the compromise of one from compromising the other. A private key stored in the secure element and unlocked by a biometric match processed in that same environment meets this requirement directly. The compliance documentation should therefore describe the device's hardware architecture environment by environment, showing what separates biometric processing from key storage. The authenticator's brand name says nothing about that separation.

Enrollment is the ceremony in which a passkey is created and then registered by the issuer. It has three stages. The first creates the passkey during a session that is already authenticated. The most common occasion is a 3-D Secure challenge served from the access control server's domain, or a session in the banking app. The second stage records the public key, the credential ID, the authenticator's model identifier, and the backup flags. The model identifier is looked up in the FIDO Alliance Metadata Service, which publishes the declared characteristics of the authenticator families registered with it. The service makes it possible to exclude a model with a known weakness. Not every family is registered there, so an identifier the service does not recognize is not a red flag in itself. The third stage manages the lifecycle: revocation, device changes, and the fallback path when no passkey is available.

• Require user verification and check it on the server. The request binds only the client, which is free to ignore it; only the flag received in the assertion proves that a second factor was presented.
• Store the authenticator's model identifier. It tells you after the fact which hardware family produced the passkey, and lets you withdraw a model if a weakness in it is published.
• Decide in writing how synced passkeys are treated. Accepted for sign-in but refused for payment, or accepted everywhere: the rule must exist before the first enrollment.
• Notify the cardholder of every new passkey on a separate channel. For an attacker, a fraudulent enrollment pays better than an interception, and it leaves no trace the cardholder can see.
• Keep a documented fallback path. Lost devices, factory resets, purchases from a shared computer: these cases happen, and the fallback that handles them sets the real security level of the whole setup.
• Check the calling origin on every assertion. Without this check, phishing resistance disappears, and the setup is no better than a biometric password.

Delegated authentication: who authenticates and who is accountable

Delegated authentication means that a third party performs the strong customer authentication ceremony on behalf of the issuer, which bears the obligation. That obligation comes from Article 97 of PSD2, which assigns it to the issuer without specifying who actually carries out the ceremony. The third party can be a merchant, a wallet, or a specialist provider, bound to the issuer by an outsourcing agreement. Liability does not transfer, however, as the European Banking Authority points out both in its June 2019 opinion and in its outsourcing guidelines. The supervisor therefore holds the issuer accountable, including for ceremonies performed by the third party.

Three setups coexist in the market, and each allocates contractual commitments differently. A merchant authenticates its own signed-in customer with the passkey that customer uses to sign in. A wallet authenticates the cardholder on the device, as Apple Pay and Google Pay have done from the start. An authentication provider works for a group of merchants under a network program that approves and monitors it. The first two require a bilateral agreement. The third is contracted by joining the program, with no direct relationship between the merchant and each issuer, which makes it workable for a merchant operating in several countries.

Both major networks publish their own delegation programs. Visa runs a delegated authentication program, Mastercard offers its own under its cardholder authentication brands, and some domestic schemes offer one as well. Eligibility generally depends on volume, a fraud rate kept in check over time, and the use of authentication that complies with the FIDO specifications. The exact thresholds are not public. Programs therefore cannot be compared without going through an acquirer. The acquirer's access to network rules determines what information the merchant will get, which makes it a criterion for choosing the acquirer itself.

Delegation promises a single gain: eliminating the challenge the issuer serves in the middle of checkout. A merchant that already authenticates its customer at sign-in reuses that ceremony instead of imposing a second one a few seconds later. The bar is high, because the sign-in ceremony must itself meet strong customer authentication, with two independent elements and dynamic linking to the amount and payee. The proof must then travel all the way to the authorization message. An issuer that does not see it returns a soft decline requesting SCA, even though the ceremony did take place. A password followed by an emailed link meets neither condition. This filter rules out most candidates for delegation.

Secure Payment Confirmation and in-browser authentication

Secure Payment Confirmation (SPC) is a W3C specification developed by its Web Payments Working Group. It handles payer authentication with a passkey during an online payment, and it adds just two capabilities to WebAuthn. The first is invoking a passkey from an origin other than the one that created it, which WebAuthn prohibits by design. The second is a confirmation dialog drawn by the browser that shows the payee, the amount, and the payment instrument before the user approves. These two additions meet payment needs that WebAuthn alone did not cover.

The second capability has a regulatory consequence. The client data signed by the authenticator contains a payment object listing the payee, the calling origin, the amount, and the chosen instrument. The signature therefore covers the transaction itself, not just a random challenge. The dynamic linking requirement in Article 5 of the delegated regulation is met by the design of the protocol. An ordinary WebAuthn assertion does not carry this data, so an issuer that wants to demonstrate dynamic linking has to bind it to the ceremony itself. The protocol spares the issuer that work: the same assertion serves as proof of authentication and proof of dynamic linking.

Using Secure Payment Confirmation requires prior enrollment. The passkey must have been created for the issuer's or the network's domain, which requires a moment when that domain is running in the cardholder's browser. The 3-D Secure challenge provides that moment, since it is served from the access control server's domain. Enrollment from a frame embedded in a third-party page is also possible, provided the host page explicitly grants, through a permissions policy, the right to create a passkey for payments. Without enrollment, the merchant has no passkey to invoke, and the flow falls back to the standard challenge. The access control server must then be able to verify this type of assertion. Far from every provider can do so yet.

The decision to implement Secure Payment Confirmation rests on two internal measurements taken beforehand. The first is the share of eligible traffic, broken down by browser and by operating system. The second, for that share only, is the abandonment rate of the current challenge, the only figure that gives the project an economic value. No comparable public benchmark exists for this rate, since each provider publishes its own using its own denominator. Internal measurement is therefore the only verifiable basis for the decision, and it takes a few days to produce.

EMV 3DS 2.3 and beyond: what a merchant can ask for today

EMV 3-D Secure is the messaging protocol a merchant uses to ask the issuer to authenticate the cardholder during a remote payment, and that the issuer uses to respond. EMVCo publishes the specification and manages its versions. Version 2.3 did not introduce passkey authentication. FIDO data has traveled in 3-D Secure messages since version 2.1.0, published in 2017. EMVCo published the usage guide for that data on October 28, 2020. The guide defines an authenticator attestation data set that describes the device without carrying any information that identifies the person. Version 2.3.1, published in 2022, adds device binding and automated out-of-band handoffs between the merchant app and the banking app. It also extends support for Secure Payment Confirmation.

Requestor challenge indicators are the fields through which a merchant conveys its exemption and delegation strategy. Version 2.2 expanded the list to cover the cases opened up by European regulation. They include risk analysis already performed and strong customer authentication already carried out upstream. These values do not bind the issuer, which remains free to issue a challenge anyway. They tell the issuer what the merchant has done and how it would like the transaction handled. Version 2.2 also introduced decoupled authentication, in which the issuer verifies the cardholder outside the merchant's checkout flow. This mode enables browserless flows and payments confirmed in the banking app. The exact mapping between each value and each use case depends on the version implemented and is set out in the provider's documentation.

The cost falls into three separate lines, and the first is the cheapest. The provider bills 3-D Secure authentication per unit, on a basis that varies by contract: every request sent, or every challenge actually served. Delegation adds the cost of an authentication provider and of joining the network program. The heaviest line is maintaining the fallback paths. It appears in no price list. No negotiation with the provider covers it. Every added flow has to be tested, measured, and fixed, for a population that shrinks as passkeys become widespread.