SMS OTPs: Bad for Security, Architecture, Engineering, and Call Centres

Overview

SMS OTPs — and even email OTPs and magic links — remain common in customer identity, despite their well-documented weaknesses. Why?

Most companies already collect customers’ phone numbers and email addresses, so bolting on an OTP for MFA or step-up authentication is relatively simple. The alternatives all introduce friction: Google or Microsoft Authenticator (or a custom authenticator app) is heavy for casual consumers, passkeys are still new and unfamiliar, and hardware tokens impose significant cost and overhead on both companies and customers.

The security problems of SMS OTPs are well known. The SS7 network is notoriously insecure. SIM cards can be cloned. Mobile retailers can be social-engineered into issuing new SIMs to attackers. SMS messages aren’t end-to-end encrypted. Mobile phones can be hacked. SMS OTPs aren’t a phishing-resistant factor. And they expose companies to toll fraud. Still, SMS OTPs offer better security than a password alone, and they remain stronger than email OTPs — email accounts are typically easier to take over than a mobile number.

Email OTPs are particularly problematic when paired with email-based password reset. If an attacker compromises an email account, they can reset the password and then “log in” using the same email account as the second factor. The two factors collapse into one.

Architecture, Engineering, and Call Centres

SMS OTPs also introduce architectural problems beyond pure security.

The phone number must be captured in the customer’s profile when provisioning into the IdP, and enabled as an authentication factor. What happens when a customer changes their number? You need self-service flows (in a mobile app or web portal) and call-centre processes to update it. Both typically require APIs and integration between the IdP and CRM.

What if a customer doesn’t have a phone number at all? You’ll need to decide whether they’re blocked from provisioning, allowed to fall back to an email OTP, or permitted to authenticate with a password and add a phone number afterwards — with the CRM updated in the same flow.

Call centres also need robust identity verification before updating a phone number. Otherwise an attacker who calls in can swap the number to one they control, then log in as the customer.

Many IdPs — Okta and Auth0, for example — require phone numbers in E.164 format. Your CRM should enforce matching data-integrity rules around length and composition. Some IdPs go further and will reject phone numbers outside allocated ranges, or numbers previously associated with fraud.

Should you verify a customer’s phone number? Many companies don’t. Email addresses are usually verified for communications and password resets, and adding a phone verification step is seen as excessive friction. The trade-off is that you can never be confident the stored number is actually correct.

Then there’s cost. Each SMS OTP costs money. Multiplied by unique logins per year, this can run to tens or hundreds of thousands of dollars annually.

International support adds further complexity. Your SMS provider may require a separate request — and regulatory approval — for each country you send to. And SMS is a best-effort delivery service: messages are not guaranteed to arrive.

SMS OTP Implementations

Any SMS OTP implementation also has to handle basic security controls:

• How many unsuccessful OTP attempts are allowed?
• What happens after too many failed attempts — lock the factor, or lock the account?

Custom implementations (those not using an IdP) face an additional engineering challenge: sequencing the password and OTP factors correctly. The OTP-validation API must be reachable from the public Internet but unusable without first successfully authenticating with a password. Attackers must not be able to bypass the password step and go straight to OTP entry.