Passwords are changing. Where do verification codes fit?

The one-time code has had a long run as the default second factor. It is simple to explain, works on any phone, and needs nothing installed. It is also phishable, delayed by carriers, and typed out by the customer in a small box under time pressure.

Passkeys fix most of that. They are bound to the site, so they cannot be handed to an attacker, and they are faster than reading six digits off a lock screen. The direction of travel is not in doubt.

Passkeys use public-key cryptography rather than asking the customer to type a shared secret. Depending on the implementation, a passkey can be synchronized across a user's devices or remain bound to a particular device. In either case, the authentication experience is designed around the device's existing unlock mechanism, such as a biometric or PIN.

The important question, then, is not whether verification codes will replace passkeys. They should not. The more useful question is where a verification code still makes sense when the preferred credential is unavailable.

Where codes still do the job

The interesting cases are the ones where the customer has no working credential to start from, which is precisely when authentication matters most.

• New device: The passkey is on the phone that was lost, replaced or stolen.
• Account recovery: The customer cannot sign in, which is the whole reason they are here.
• Shared and public devices: Nothing can be stored, and nothing should be.
• Step-up: Confirming one sensitive action inside a session that is already open.

There is an important qualification here: not every new-device scenario requires a verification code. Synced passkeys can be available across multiple devices, which is one of their advantages. Device-bound passkeys are different, however, and may require a separate recovery or re-enrollment process when the original device is unavailable.

In each of those, the code is not competing with a passkey. It is the fallback that makes having a passkey safe to adopt at all.

That fallback needs to be designed as carefully as the primary authentication method. FIDO guidance recommends that recovery mechanisms be appropriate to the security level of the credential being recovered rather than simply falling back to the weakest available factor.

Verification codes are a fallback, not a destination

This distinction matters because SMS verification codes have real security limitations. NIST currently classifies the use of SMS and voice over the public switched telephone network for out-of-band authentication as a restricted authenticator. The risks include phone-number reassignment, weaknesses in telecommunications infrastructure and the possibility of authentication messages being redirected.

That does not make every SMS verification flow useless. It means businesses should understand what the code is actually protecting and what risks remain around the phone number itself.

For lower-risk situations, an SMS code may still provide a practical way to verify control of a phone number. For higher-risk account recovery or sensitive actions, businesses should consider stronger, phishing-resistant authentication and additional risk signals rather than treating possession of a phone number as proof of identity.

Designing the fallback properly

A fallback that is slow or unreliable quietly becomes the ceiling on the whole login experience, because it runs at the worst possible moment. Speed matters more here than anywhere else in the product.

That means routing that fails over between channels instead of waiting, a message that names your business in the first few words, and a code that is short enough to hold in your head while you switch apps.

The best code is the one the customer never needs. The second best arrives before they go looking for it.

The operational details matter because authentication failures happen when customer patience is already low. A delayed message can lead to repeated requests, multiple active codes, abandoned logins and unnecessary support contacts.

A good verification flow should therefore make the state of the process obvious. Tell the customer what is happening, make the latest code clearly identifiable, expire old codes appropriately, and provide another recovery path when delivery fails.

The delivery channel matters too. SMS is attractive because it requires no app installation and works across a huge range of devices, but it should not be treated as a guaranteed delivery mechanism. A robust authentication system needs to account for carrier delays, unavailable service, changed numbers and other delivery failures.

The message itself is part of the security experience

A verification code message should be deliberately boring. The customer should immediately know which service generated it, what the code is for and what to do with it.

For example, a useful authentication message identifies the business, clearly labels the code as a verification or sign-in code, and avoids unrelated links or requests for additional information. The less ambiguity there is, the less room there is for a customer to confuse the legitimate message with a phishing attempt.

Businesses should also be careful about what they put into the message. A verification code should not become an opportunity to collect passwords, payment information or other sensitive data. The authentication message has one job: deliver the authentication factor clearly and safely.

What happens as passkeys become normal?

Expect code volume to fall as passkey adoption rises, and expect the codes that remain to be more important, not less. They will increasingly be concentrated in recovery and step-up flows, where a failure is not an inconvenience but a locked-out customer contacting support.

That creates an interesting shift for messaging teams. The volume of authentication traffic may decline, but the importance of each successful delivery increases. A code that arrives five minutes late is not simply a slower notification; it can be the difference between a customer completing a login and abandoning it.

The long-term authentication stack is therefore likely to become more layered rather than simply "passwordless." Passkeys can handle routine authentication. Stronger authenticators can protect sensitive actions. Verification codes can remain available for carefully designed fallback and recovery scenarios where they are appropriate.

The goal is not to eliminate every code. It is to stop making the code responsible for jobs that a stronger authenticator can do better.

Passkeys are changing the front door. Verification codes still have a role in the emergency exit. The better the primary authentication becomes, the more deliberately that fallback can be used.