SMS 2FA explained: how two-factor authentication by text works

What is SMS 2FA?

SMS 2FA is two-factor authentication that uses a text message as the second step. You enter your password, the service sends a short one-time code to your registered phone, and you type that code to finish signing in. The first factor is something you know, the password. The second is something you have, the phone that receives the message.

The reason it is so common is practical: nearly everyone has a phone that can receive a text, nothing needs to be installed and it is easy to explain. The reason it is debated is that it is not the strongest second factor available. This guide explains how it works, where it is weak and how to build it so it is as strong as it can reasonably be. For the sending side in detail, see our guide to OTP SMS.

How SMS two-factor authentication works

1. The user signs in. They enter their username and password, which your system checks first.
2. A code is generated. Your server creates a random number, stores a hash of it with an expiry time and attempt counter.
3. The code is sent by SMS. It goes through an SMS gateway to the phone number on the account.
4. The user enters the code. Your server compares it, checks it has not expired or been used and allows only a few tries.
5. The session starts. On success the code is deleted, and you record which method was used.

The standard that describes this and stronger methods is the NIST digital identity guideline, which treats SMS as a restricted authenticator rather than a forbidden one. See also the general idea of multi-factor authentication.

How secure is SMS 2FA?

Compared with a password alone, very. Most automated account takeover relies on stolen or reused passwords, and a second factor defeats those attacks even if the password is known. The weaknesses are more targeted:

SMS 2FA compared with other methods

A practical pattern is to make SMS the default for ordinary users, offer an app as an upgrade and require stronger methods for privileged roles. Our OTP solutions page and OTP product describe how this is delivered.

Building SMS 2FA well

Generate and store codes safely

import secrets, hashlib, time

def new_code():
    code = f"{secrets.randbelow(10**6):06d}"
    record = {
        "hash": hashlib.sha256(code.encode()).hexdigest(),
        "expires": time.time() + 300,
        "tries": 0,
    }
    return code, record

Use a secure random generator, never a timestamp or a counter. Store a hash rather than the code, and delete it after use. In production, add a per-user salt or a keyed hash.

Send a clear message

Telnxo: 482913 is your verification code. It expires in 5 minutes. Do not share it with anyone.

Put the brand and the code in the first words, say how long it lasts and warn against sharing it. Android and iOS can read standard formats for autofill. Our OTP best practices covers wording and timing.

Limit abuse

• Allow three to five attempts per code, then require a new one.
• Rate-limit sends per number, per account and per IP address, and watch for bursts to premium or unusual destinations.
• Add a delay before allowing a resend, and show a countdown.
• Do not reveal whether a number is registered on the sign-in screen.
• Log events, not code values.

Fraudsters sometimes trigger thousands of codes to numbers they profit from. Good limits and a HLR lookup or number lookup before sending help you avoid paying for those messages.

Why the code does not arrive

For a fuller diagnosis, use why messages fail or arrive late and the troubleshooting hub.

When to ask for a second factor

Asking for a code on every single page view would drive people away, and never asking leaves accounts open. The sensible middle is to require the second factor when the risk changes. That usually means a sign-in from a new device or location, a password reset, a change of email or phone number, adding a payout account, or a large payment. Many services remember a trusted device for a limited time so a regular user is not interrupted daily, while an unfamiliar device always has to prove itself.

This risk-based approach keeps friction low and still stops the attacks that matter. It also keeps your message volume, and therefore your cost, under control.

Cost, privacy and compliance

Each code is one SMS segment, billed at the rate for its destination, so a login system with a million monthly sign-ins has a real cost line. The cost calculator gives an estimate, and trusted-device rules often cut it sharply. Phone numbers are personal data in most countries, so collect them for a stated purpose, tell users how they are used and keep them only as long as needed. The privacy policy and compliance overview describe how Telnxo handles the data that passes through the platform.

Rules for the sender differ by country. In India, OTP messages travel on registered templates, while in the United States they need a registered campaign. Plan for this early, because a code that is blocked is a customer who cannot log in. The country rules guide lists the main differences.

Give users a fallback

A second factor that locks people out is a support problem. Always offer a way in when the text does not arrive: a voice call that reads the code, an authenticator app, backup codes issued at set-up or a verified alternative email. Each fallback needs the same rate limits, because attackers will target the weakest path.

The best second factor is the one your users will actually complete, backed by a stronger option for the accounts that matter most.