Eliminating SMS OTP starts at onboarding

At a glance

What this is: This article explains why eliminating SMS OTP depends less on login changes than on redesigning onboarding, phone verification, device binding, and recovery flows.

Why it matters: IAM teams need to treat onboarding as the control point where authentication method choice, fraud exposure, and conversion risk intersect across human identity and customer access journeys.

Context

SMS OTP is losing its place as the default control for customer authentication in regulated banking journeys. The governance gap is not only login security, but how banks confirm control of a phone number before they can issue stronger credentials or move customers onto phishing-resistant authentication.

For IAM and identity architects, the problem is sequencing. If SMS is removed from high-risk flows, the replacement control has to work at sign-up, during recovery, and across fallback paths without assuming that every customer can complete the same verification method.

The article frames that shift as a programme design issue rather than a single-factor swap. Banks need a front-door model that can separate number verification, identity proofing, device binding, and ongoing step-up into distinct controls.

Key questions

Q: How should security teams replace SMS OTP in customer onboarding?

A: Security teams should replace SMS OTP in onboarding by separating phone verification from authentication. Use carrier-based verification where available, bind the customer to a real device or passkey after identity proofing, and keep a controlled fallback for unsupported channels. The goal is to remove shared-secret dependence without breaking account creation.

Q: Why does SMS OTP create more risk than many teams assume?

A: Because the trust boundary sits in the telecom and messaging path, not in the user’s device alone. Phishing relay, SIM swap, port-out fraud, recycled numbers, and SS7 interception can all break the model without stealing the user’s password. For regulated journeys, that makes SMS OTP a weak assurance factor rather than a stable control.

Q: What breaks when banks rely on SMS OTP as the only transaction authentication method?

A: Banks expose themselves to account takeover and transaction fraud because a stolen or relayed OTP proves only that a code was received, not that the session, device, or transaction is trustworthy. Once the attacker controls the channel or the user is socially engineered, the code becomes a weak hurdle rather than a real assurance step.

Q: How should teams decide between carrier verification, WhatsApp OTP, and passkeys?

A: Use carrier verification as the primary number check where network conditions allow it, treat stronger messaging-app fallback as a contingency, and issue passkeys only after the customer has been anchored with liveness and identity proofing. The decision is sequential, not either-or.

Technical breakdown

Why SMS OTP fails as a trust anchor

SMS OTP was never a strong authentication secret. It depends on telecom delivery, can be intercepted through SIM swap fraud, phishing, malware, or social engineering, and it creates a shared secret that moves through infrastructure the bank does not control. In identity terms, that means the factor can be moved, copied, or tricked out of the user rather than bound to the relying party. The article also notes a cost dimension: OTP traffic can be artificially generated through SMS pumping, which turns authentication into a fraud expense. The result is a control that looks familiar operationally but is weak as an assurance mechanism.

Practical implication: Treat SMS OTP as a fragile fallback channel, not a primary trust anchor for regulated authentication journeys.

How onboarding must replace SMS phone verification

The harder problem is not replacing OTP at login, but confirming that a new customer controls a phone number before stronger credentials exist. The article describes silent network authentication, carrier-based number verification APIs, and SIM-linked checks as the preferred way to validate number ownership without sending a code. That shifts assurance from message delivery to network-level confirmation. It also changes the failure mode: Wi-Fi, roaming, desktop access, or incomplete carrier coverage can make the primary path unavailable, so the onboarding flow needs an ordered fallback model rather than a default text message.

Practical implication: Design onboarding so number verification can route to a stronger non-SMS fallback when carrier-based checks are unavailable.

Why passkeys change the post-onboarding model

Once the phone number and live user are anchored, passkeys can replace repeated OTP prompts with a device-bound credential based on public-key cryptography. The private key stays on the user device or credential manager, while the service stores the public key, which makes phishing materially harder because the credential is origin-bound. In practice, this moves verification effort to the front of the journey and reduces the need to reuse OTPs for login, payee changes, device changes, and recovery. The architectural shift is from repeated out-of-band challenge to a credential lifecycle that starts at onboarding and carries forward across the account relationship.

Practical implication: Issue passkeys after onboarding assurance is established, then use risk-based step-up only for higher-risk actions.

NHI Mgmt Group analysis

Onboarding is now the control point that determines whether SMS OTP can be retired. The article is right to separate login from onboarding because the first moment of customer verification now carries the largest design burden. Regulators have narrowed the acceptable use of SMS OTP, but they have not eliminated the need to prove phone control and user presence at account creation. The implication is that authentication modernisation is really a front-door governance problem, not a single-factor replacement decision.

Phone-number verification and customer authentication are different control jobs. SMS used to blur them together, which made the journey simpler but also made the control architecture weak. Number verification is about confirming control of a channel, while authentication is about confirming the account holder at runtime. The article usefully shows why banks need to split those jobs into separate steps if they want to remove OTP without weakening onboarding conversion or recovery.

Identity assurance must move earlier in the lifecycle than most banking teams planned. If the account only gets stronger after the first login, then the risky part of the journey remains ungoverned. The practical consequence is that device binding, liveness, and passkey issuance have to be sequenced at onboarding, not treated as later hardening activities. For identity teams, the programme question becomes whether the front door can support layered proofing without forcing SMS into the role of default fallback.

Channel routing is becoming part of identity governance. The article makes clear that the right fallback is context dependent: carrier-based verification where available, stronger alternatives such as messaging-app OTP where necessary, and passkeys for the durable credential layer. That is not just orchestration logic. It is policy design for what proofs are acceptable in each step of the customer journey, which means IAM and fraud teams need shared control ownership rather than separate silos.

Passkeys only solve the post-onboarding problem after the onboarding problem is solved. A phishing-resistant credential does not remove the need to establish a trustworthy binding between person, number, and device first. The field should read this as a lifecycle lesson: strong authentication fails when teams try to insert it after weak proofing instead of before it. The implication is that identity programmes need to govern the full transition path, not just the end-state credential.

What this signals

Phone verification is becoming a separate governance control from authentication. Teams that still treat the two as one control will struggle to remove SMS without leaving a gap at account creation. The useful design pattern is to validate the number first, then bind a durable credential after the customer has been anchored.

Lifecycle sequencing matters more than channel preference. A passkey is only as strong as the onboarding process that issued it, so the front door has to establish identity before the account moves into routine login and recovery. IAM teams should read this as a lifecycle redesign problem, not a messaging-channel swap.

For practitioners

• Map every SMS dependency in the customer journey Separate phone verification, login, transaction approval, device binding, and recovery into distinct flows so each can be replaced on its own timetable.
• Replace onboarding SMS with carrier-based checks where possible Use silent network authentication or number verification APIs as the primary path for confirming number control before account creation completes.
• Define fallback routing before the first OTP is removed Set rules for Wi-Fi, roaming, desktop, or low-coverage cases so the journey can move to a stronger alternative without reverting to SMS by habit.
• Bind a passkey only after the identity anchor is established Issue the durable credential after number control and liveness have been completed, then use risk signals for high-value step-up instead of recurring OTP prompts.
• Rework recovery to use the original identity anchor Stop treating texted codes as the default recovery path and require the same assurance stack used at onboarding, especially for device change and account reset.

Key takeaways

• The article shows that SMS OTP removal is an onboarding and lifecycle problem, not just a login or step-up problem.
• Carrier-based number verification, liveness, and passkeys form a staged replacement path, but each layer solves a different job.
• IAM teams should split number control, identity proofing, and credential issuance into separate controls before removing SMS from high-risk journeys.

Key terms

• Silent Network Authentication: A phone-number verification method that confirms device and SIM association through the carrier network instead of sending a one-time code. It reduces exposure to phishing and SMS pumping because the user does not need to read or return a secret.
• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• Device binding: A control that links an authenticator or key pair to a specific endpoint so the same secret cannot be copied and reused elsewhere. It strengthens assurance, but the binding step itself becomes a high-value target if attackers can intercept the enrollment process.
• Identity proofing: The process of verifying that a person is who they claim to be before granting or restoring access. In higher-risk recovery paths, proofing can include stronger evidence checks such as government ID validation or liveness-based facial verification so the assurance level matches the sensitivity of the request.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.