Twilio Two-Factor Authentication via SMS: A Practical Guide

Two-factor authentication via SMS is one of the most common security additions to UK web platforms. A user logs in with their password, receives a 6-digit code by text, and enters the code to complete authentication. Twilio Verify is the purpose-built API for this — it handles code generation, SMS or voice delivery, code validation, rate limiting and fraud detection. This post covers how Twilio Verify works, why it’s better than rolling your own OTP logic, and what the integration looks like.

Twilio Verify vs building your own OTP

It’s possible to build SMS two-factor authentication using the basic Twilio SMS API — generate a random 6-digit code, send it as an SMS, store the code server-side with an expiry, and validate it when the user submits it. Many integrations are built this way. It works, but it requires you to get several things right that Twilio Verify handles automatically.

Code generation. Random codes need to be cryptographically random, not just pseudo-random. Using a weak random number generator produces predictable codes that can be guessed. Twilio Verify uses properly secure code generation.

Code expiry. Codes must expire after a short window (typically 10 minutes). Codes that don’t expire are a significant security vulnerability — an attacker who intercepts a code has unlimited time to use it. Managing expiry correctly in your own code requires careful implementation.

Rate limiting. Without rate limiting on code requests, an attacker can repeatedly request new codes for a target account and flood the user with SMS messages, or attempt to brute-force the code by requesting many in quick succession. Twilio Verify includes built-in rate limiting that blocks excessive requests automatically.

Brute-force protection. The code entry endpoint needs to limit the number of attempts. After a defined number of wrong attempts, the verification should be invalidated and require a new code. Twilio Verify handles this automatically — it invalidates the verification after 5 failed attempts.

Channel fallback. If SMS delivery fails, Twilio Verify can automatically fall back to delivering the code by voice call. Building this fallback yourself requires additional logic and another API integration.

Twilio Verify handles all of this correctly out of the box. For most integrations, using Verify is the right choice — it’s more secure, simpler to implement, and maintains compliance with authentication best practices without requiring you to reinvent them.

How Twilio Verify works

The Twilio Verify flow has two steps: start verification and check verification.

Start verification is called when the user needs to receive a code. Your server calls the Twilio Verify API with the user’s phone number and the channel (SMS or voice). Twilio generates a code, sends it to the user, and returns a verification SID. Your server stores nothing about the code — Twilio manages it entirely.

Check verification is called when the user submits the code they received. Your server calls the Twilio Verify API with the verification SID and the code the user entered. Twilio checks the code against its stored value, confirms it hasn’t expired, confirms the attempt limit hasn’t been exceeded, and returns approved or denied. Your server acts on the result — completing the login or transaction if approved, showing an error if denied.

Your server never sees or stores the verification code. This is a security advantage — the code is only ever in Twilio’s system and on the user’s phone. A database breach of your system doesn’t expose pending verification codes.

When to use SMS 2FA

User login. The most common use case. After entering their password, the user receives an SMS code and must enter it to complete login. Appropriate for platforms where account security is important — financial platforms, healthcare systems, any platform holding sensitive personal data.

High-value transactions. Rather than protecting every login with 2FA, some platforms apply verification only to specific high-risk actions — withdrawing funds, changing a password, adding a new bank account, making a large purchase. Step-up authentication at the point of the action rather than at every login is a better user experience for low-risk daily use while protecting the actions that matter most.

Account registration. Phone number verification at registration confirms the user owns the number they’ve provided, prevents fake account creation with invalid numbers, and provides a verified contact method for future 2FA. Most platforms using SMS 2FA for login also verify the phone number at registration time.

Password reset. Using SMS as a second factor in the password reset flow adds security beyond a link sent to an email that might also be compromised. The user receives a code on their registered phone to confirm the reset.

SMS 2FA vs authenticator apps

SMS-based 2FA is convenient but not the strongest form of second factor. SIM-swap attacks — where an attacker convinces a mobile carrier to transfer a victim’s number to a SIM they control — can bypass SMS 2FA. For most UK consumer platforms, SMS 2FA is entirely adequate protection and the right balance of security and usability. For high-value financial accounts, authenticator app-based 2FA (Google Authenticator, Authy) or hardware security keys provide stronger protection.

Twilio also supports TOTP (Time-based One-Time Password) — the same algorithm used by authenticator apps — through the Verify API, making it possible to support both SMS and authenticator app verification from the same integration if your platform requires it.

Phone number formatting for UK users

Twilio requires phone numbers in E.164 format — the country code followed by the number with no spaces, hyphens or brackets. A UK mobile number stored as “07700 900123” needs to be converted to “+447700900123” before passing to Twilio. The integration includes phone number formatting logic — detecting the format the number is stored in and converting it to E.164 before making the API call.

Landline numbers cannot receive SMS and will fail verification. The integration should handle this gracefully — either preventing landline numbers from being registered for 2FA, or offering a voice call fallback for numbers that don’t support SMS.

For the full Twilio service and pricing, see the Twilio SMS API integration service. For the complete Twilio API guide, see Twilio SMS API integration guide. For appointment reminder integrations, see SMS appointment reminders with Twilio. For what the build costs, see the Twilio SMS integration cost guide.

Implementing 2FA without disrupting user experience

The biggest risk with adding SMS 2FA to an existing platform is friction that drives users away. A poorly implemented 2FA flow — slow code delivery, confusing UI, no fallback when a user changes number — frustrates legitimate users while doing little to deter a determined attacker who has both the password and access to the phone.

A well-designed 2FA implementation addresses these friction points explicitly. Code delivery should be fast — Twilio typically delivers UK SMS within a few seconds, but UI messaging should set expectations (“Code sent — check your texts” rather than making users wonder if it worked). The code entry field should accept the code as soon as it’s entered without requiring a separate click where possible. A visible timer showing how long the code is valid for reduces anxiety about expiry. A “resend code” option handles the case where the first SMS didn’t arrive.

Account recovery is also important to design upfront. What happens when a user loses their phone or changes their number? Without a recovery mechanism, locked-out users create support burden. Options include backup codes generated at 2FA setup, a recovery email flow, or a manual identity verification process for account recovery. The right approach depends on your platform’s security requirements and support capacity.

Twilio Verify pricing

Twilio Verify charges per verification attempt, not per successful verification. As of 2025, UK SMS verification costs approximately £0.05 per attempt. A platform with 1,000 user logins per day using 2FA would incur around £50 per day in Verify charges, or approximately £1,500 per month. This is worth modelling before implementation — particularly for platforms with high-frequency login events where the cost scales with user activity.

Optimisations that reduce Verify costs include: not requiring 2FA on every login (only on new devices or after a set period), caching the verified state for a session or trusted device, and using risk-based authentication to only trigger 2FA for logins from unfamiliar locations or devices. These are design decisions that balance security, user experience and cost, and are worth discussing during the integration scoping.

If you need help with a custom API integration for your website or business application, I can help. I build bespoke API integrations for UK businesses. See API integration pricing or get in touch to discuss your project.

Need a custom integration built?

I build custom API integrations — Stripe, Companies House and bespoke data pipelines. Reliable, well-documented, no agency overhead.

Discuss your project →