Subscribe to the Non-Human & AI Identity Journal

How should security teams replace SMS OTP in customer onboarding?

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.

Why This Matters for Security Teams

SMS OTP is often treated as a convenient second factor, but for onboarding it is a weak trust signal because the phone number is not the same thing as the customer, the device, or the session. A number can be recycled, forwarded, ported, or intercepted, and that creates account takeovers at the exact point where teams are trying to establish identity. NIST SP 800-53 Rev 5 Security and Privacy Controls frames this as a control design problem, not just a user experience problem.

Security teams also need to separate identity proofing from authentication. The onboarding flow should prove the person, then bind the account to a stronger authenticator such as a passkey or verified device. That matters even more where fraud, SIM swap risk, or regulated customer due diligence is in scope. NHI Management Group’s Ultimate Guide to NHIs shows how fragile long-lived shared secrets become when they are overused; the same pattern appears in customer onboarding when SMS becomes the default fallback.

In practice, many security teams discover the weakness only after a successful takeover, rather than through intentional design review.

How It Works in Practice

The cleanest replacement is to stop using SMS OTP as the proof of control and instead use it, if at all, as a low-assurance recovery step. Start with identity proofing or risk-based verification, then issue a stronger binding factor after the customer is established. In many consumer flows, that means a passkey, a verified authenticator app, or a device binding step that creates a durable relationship between the user and the account.

Where phone verification is still required, use carrier-based verification or phone intelligence to confirm line status, not shared-secret challenge codes. That helps distinguish a reachable number from a trustworthy authenticator. Current guidance suggests pairing this with short-lived session handling, explicit device enrollment, and step-up verification for risky changes. For organizations handling onboarding at scale, FATF Recommendations are relevant where customer identity checks intersect with KYC obligations, while Schneider Electric credentials breach is a reminder that weak credential handling creates downstream exposure.

  • Use SMS only when there is no better channel, and treat it as low assurance.
  • Bind the account to a device or passkey after onboarding, not before identity proofing.
  • Prefer short-lived, non-reusable verification steps over static shared secrets.
  • Log verification method, risk score, and fallback usage for fraud review.

This guidance tends to break down in markets where device ownership is unstable, carrier data is unreliable, or users routinely change numbers during onboarding because assurance signals degrade quickly.

Common Variations and Edge Cases

Tighter onboarding verification often increases drop-off and support cost, so organisations must balance fraud reduction against conversion. There is no universal standard for this yet, especially across consumer finance, telecom, and low-risk retail. Some environments can move directly to passkeys after email or document proofing, while others need layered checks because the business cannot rely on a single channel.

Fallback design is the main edge case. If SMS is retained, it should not become a universal recovery path that silently reintroduces shared-secret risk. Teams should define when fallback is allowed, who can approve it, and what extra checks apply. NIST’s security control guidance supports this kind of layered verification, and the broader NHI security evidence from Ultimate Guide to NHIs and Schneider Electric credentials breach reinforces the same operational lesson: long-lived or reusable secrets create persistent exposure.

For high-risk onboarding, the best practice is evolving toward proofing plus possession binding, not code delivery. That is the direction security teams should plan for.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 PR.AC-1 Onboarding requires verified access decisions before account activation.
NIST SP 800-63 IAL2 Identity proofing strength determines whether onboarding signals are trustworthy.
OWASP Non-Human Identity Top 10 NHI-03 Shared-secret replacement reduces exposure from weak, reusable verification factors.
OWASP Agentic AI Top 10 LLM-03 Autonomous onboarding automation can amplify weak verification and fallback abuse.
NIST AI RMF GOVERN Risk governance is needed when replacing familiar auth with new onboarding controls.

Replace reusable OTP patterns with short-lived, bound verification methods.