One-time passcodes sent by SMS, voice or email are still the most common second factor and verification step on consumer services, and fraudsters have learned to defeat them by relaying codes through phishing kits, talking customers into reading them out, swapping SIMs and pumping traffic for profit. The usual reaction, adding friction everywhere, hurts sign-up and checkout conversion without stopping the attacks that matter. This guide maps the main OTP fraud patterns to controls, shows which controls cost conversion and which do not, and sets out how to design codes, messages and step-up rules so that legitimate users pass quickly while abuse is blocked. It is written for fraud, identity and product security teams running customer authentication, and links to the SMS Pumping and IRSF Guide for the traffic fraud side.
Key takeaways
- OTPs are not phishing-resistant. NIST SP 800-63B-4 says plainly that out-of-band authentication is not phishing-resistant and classes PSTN delivery (SMS and voice) as a restricted authenticator, so OTP must be paired with risk controls or replaced where stakes are high.
- Most OTP fraud is social, not cryptographic. The common pattern is a fraudster triggering a real code and persuading the customer to share it, which no code length or expiry fixes; message wording, transaction context and binding matter more.
- Bind codes to their purpose and origin. A code bound to one request (OWASP ASVS V6.6.2) and, for web, delivered in the origin-bound format
@example.com #123456cannot simply be replayed into a different flow or a lookalike site by autofill. - Spend friction only where risk is. Risk-based step-up, device recognition and silent verification keep most users on a fast path; reserve extra steps for new devices, sensitive changes and high value transactions.
- Offer something better than OTP. NIST requires verifiers to make alternatives to PSTN available, and passkeys usually convert better than SMS once enrolled, so treat OTP as a fallback rather than the destination.
OTP fraud patterns
| Pattern | How it works | ATT&CK reference | What stops it |
|---|---|---|---|
| Real-time phishing relay | A lookalike login page collects the password and then the OTP, and the kit replays both to the real site before the code expires. The Twilio breach phishing kit relayed codes instantly through a Telegram bot; the wider 0ktapus campaign captured 5,441 MFA codes | T1557 Adversary-in-the-Middle; T1111 Multi-Factor Authentication Interception | Passkeys; origin-bound codes with browser autofill; device binding; anomaly checks on the session that submits the code |
| Code sharing by social engineering | The fraudster starts a login or payment, which sends the genuine customer a code, then calls or messages them posing as the bank, a delivery firm or a friend and asks for it. The Canadian Anti-Fraud Centre lists an unrequested OTP and a request to share it as key warning signs | T1684.001 Impersonation | Message wording naming the action, in-app confirmation instead of codes, step-up on new devices, cooling off for sensitive changes |
| SIM swap and number port | The attacker moves the victim's number to a SIM they control and receives codes directly | T1451 SIM Card Swap (Mobile) | NIST says verifiers SHOULD check device swap, SIM change and number porting before sending; fall back to another factor when signals fire |
| SMS pumping and IRSF | Bots trigger OTP sends to premium or inflated number ranges for a revenue share | Not an ATT&CK technique | Send rate limits, geo permissions, conversion monitoring; see the SMS Pumping and IRSF Guide |
| Brute force and enumeration | Guessing six digit codes, or using the send endpoint to test which numbers have accounts | T1110 Brute Force | Attempt limits that survive resends, generic responses, bot management |
| Push or OTP request flooding | Repeated prompts until the user approves or shares one | T1621 Multi-Factor Authentication Request Generation | Rate limits on prompts (ASVS V6.6.4), number matching, alerts on bursts |
Designing the code itself
The baseline technical requirements are well defined and cost nothing in conversion:
- Randomness and length: generate codes with a CSPRNG (ASVS V6.5.3). NIST requires at least six decimal digits; ASVS V6.5.4 requires at least 20 bits of entropy, which six random digits meet.
- Lifetime: NIST treats an out-of-band authentication as invalid unless completed within 10 minutes, and ASVS V6.5.5 sets the same 10 minute maximum. Shorter is fine for login; keep the full window for users switching apps on slow networks.
- Single use and binding: a code is usable once (ASVS V6.5.1) and only for the request that generated it (ASVS V6.6.2), so a code issued for login cannot approve a payee change.
- Attempt limits: codes under 64 bits need rate limiting (ASVS V6.6.3). NIST's default is 100 consecutive failed attempts before the authenticator is disabled, and generating a new code must not reset the failed attempt count. Most consumer services use far lower per code limits (for example, five attempts per code) plus a per account ceiling.
- Resend behaviour: OWASP's MFA cheat sheet advises generating a new code on resend and overwriting the old record, never logging OTP values, and hashing stored codes to limit accidental disclosure.
- Server side only: Google's SMS Retriever guidance says to generate and verify codes only on the server and never return the code in the API response that requests it, a mistake that still appears in mobile apps.
Designing the message
The SMS or email text is a fraud control. It is often the last thing the customer reads before a fraudster asks for the code.
- Say what the code does: "Your code to add a new payee of 250 GBP to your account is 482913" gives the customer a chance to notice a mismatch with what the caller claims. Name the action and, for payments, the amount and payee.
- Say who will never ask: "We will never call you to ask for this code" is short and directly counters the dominant scam.
- Use the origin-bound format for web: the WICG "Origin-bound one-time codes delivered via SMS" draft Community Group Report (24 March 2021, not a W3C Standard) defines a last line of
@example.com #123456, with an optional embedded origin after the code. Browsers that support it only offer to autofill the code on a matching origin, which helps against phishing sites and also improves conversion by removing typing. - Use platform retrieval in apps: on Android the SMS Retriever API reads a message containing an 11 character app hash without extra permissions; the message must be no longer than 140 bytes. Pair it with the
autocomplete="one-time-code"field hint on web. - Keep links out: codes should be typed or autofilled, not delivered with a link; links in OTP messages train customers to tap links in texts, which is how smishing works.
Controls and their conversion cost
| Control | Fraud it reduces | Conversion impact | When to use |
|---|---|---|---|
| Code autofill (origin-bound format, SMS Retriever) | Phishing relay via lookalike sites (partially) | Positive: fewer typing errors and faster completion | Always |
| Device recognition and trusted device cookies | Account takeover from new devices | Positive: returning users skip OTP | Login on consumer apps |
| SIM swap and porting signals before send | SIM swap | Neutral for most users; friction only when the signal fires | Login, recovery and payments where carrier data is available |
| Contextual message wording | Social engineering | Neutral | Always for sensitive actions |
| Risk-based step-up to a stronger factor | Relay and sharing on high risk sessions | Small, concentrated on risky sessions | New device plus sensitive change, high value payments |
| In-app approval with number matching | Code sharing, relay | Neutral to positive once the app is installed | Customers with the app |
| Cooling off period after contact detail changes | Takeover followed by immediate cash out | Negative for a small number of genuine changes | Changes to phone, email or MFA before payments |
| Passkeys | Relay, phishing, sharing, SIM swap | Usually positive after enrolment | Offer at sign-up and after successful OTP logins |
| Send limits and geo permissions | SMS pumping, enumeration | Neutral if tuned to real traffic | Always |
Risk-based OTP: where to add friction
OWASP's MFA guidance recommends requiring the additional factor at login and for sensitive actions such as changing the password, changing the account email, disabling MFA and elevating privilege, and triggering it on risk signals such as a new device or location, IP reputation, device fingerprint and known compromised credentials. A practical tiering for consumer services:
- Low risk: recognised device, usual location, routine action. No OTP, or a silent check.
- Medium risk: new device or first login after a password reset. OTP with autofill, or in-app approval.
- High risk: new device plus a change of phone, email, MFA or payee, or a high value payment. Require a passkey or in-app approval with number matching; if only OTP is possible, add a cooling off period and an out of band notification to the old contact details.
- Blocked: SIM swap signal within the last few days, or impossible travel during an OTP flow. Send no code; route to a stronger factor or assisted recovery.
Fallbacks must be no weaker than the primary method, as OWASP notes; an account recovery path that resets MFA with one SMS undoes all of the above. See the Account Takeover Prevention Guide.
Choosing alternatives to SMS OTP
| Method | Phishing-resistant | Strengths | Weaknesses |
|---|---|---|---|
| SMS or voice OTP | No (NIST restricted) | Universal reach, no install | Relay, sharing, SIM swap, per message cost |
| Email OTP or magic link | No | Cheap, no phone needed | Depends on email account security; NIST does not allow email for out-of-band authentication |
| Authenticator app TOTP | No | No carrier dependence, free to send | Can still be read out or relayed |
| In-app push with number matching | Partly (resists blind approval) | Good UX, transaction context on screen | Needs the app, push flooding risk |
| Passkeys | Yes | Fast, resists phishing and sharing | Enrolment and recovery design needed |
Small businesses usually get the most from autofill, contextual wording, send limits and offering passkeys. Large consumer platforms add carrier signals, device intelligence and tiered step-up. See the Magic Links and Email OTP Security Guide, the Authenticator Apps and OTP Guide and the Passkey Rollout Guide.
Where identity fits: the OTP provider credentials
Every OTP flow depends on a non-human identity: the API key or account token your service uses to send messages through an SMS, voice or email provider. A leaked sending key lets an attacker send messages that appear to come from you, run up pumping charges on your account, or read delivery logs that contain phone numbers. Keep provider keys in a secrets manager, scope them to sending only, restrict them by source IP where the provider allows, set spend alerts, and rotate them when staff or suppliers with access change. See the Secrets Management Guide.
How to implement
- Map every OTP flow: sign-up verification, login, recovery, contact changes, payments, and which provider and channel each uses.
- Fix the code mechanics: CSPRNG, single use, request binding, 10 minute or shorter lifetime, attempt counters that survive resends, no codes in logs or API responses.
- Rewrite messages: action and amount, "we will never ask for this code", origin-bound last line for web, app hash for Android.
- Add risk tiers in observe mode: compute the tier for each flow and log what would have happened for two to four weeks, measuring how many genuine users would see extra friction.
- Enforce in steps: start with high risk tiers and contact detail changes, then medium; A/B test wording and step-up against completion rate.
- Introduce passkeys: offer enrolment after a successful OTP login and measure how many users switch.
- Roll back: keep each control behind a feature flag and agree in advance the conversion drop that triggers rollback.
Detection and measurement
- Relay signals: the code is submitted from a different IP, ASN or device than the one that started the flow, or within an implausibly short time of delivery.
- Sharing signals: a code entered on a new device shortly after an inbound call or chat to the customer, or a payee change immediately after a new device login.
- SIM swap signals: carrier SIM change or porting events near an OTP request.
- Traffic signals: sends without completions by country or number range, the core SMS pumping indicator.
Measure fraud and conversion together:
- OTP delivery rate and verification completion rate per channel and country.
- Median time from send to successful entry (autofill should reduce it).
- Account takeover rate per 10,000 logins, split by authentication method.
- Share of high risk actions completed with a phishing-resistant method.
- Passkey enrolment rate among users who completed an OTP login.
- OTP spend per verified user.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-63B-4 | PSTN restricted authenticator; out-of-band verifier requirements; AAL2 phishing-resistant option | Code length, lifetime, throttling, SIM change checks, alternatives |
| OWASP ASVS 5.0 | V6.5.1, V6.5.3, V6.5.4, V6.5.5; V6.6.1, V6.6.2, V6.6.3, V6.6.4 | Single use, randomness, entropy, lifetime, PSTN conditions, binding, rate limiting, push flooding |
| NIST SP 800-53 Rev. 5 | IA-2(8) Replay Resistant; IA-5 Authenticator Management; IA-11 Re-authentication | Replay resistance and step-up |
| NIST CSF 2.0 | PR.AA-03; DE.AE-02 | Authentication and analysis of adverse events |
| MITRE ATT&CK | T1111; T1621; T1557; T1684.001; T1451 (Mobile) | Interception, request flooding, relay, impersonation, SIM swap |
Common failure patterns
- Generic code messages: "Your code is 123456" gives the customer nothing to check against the fraudster's story.
- Resend resets the counter: attackers request a new code after each batch of guesses, which NIST explicitly forbids.
- One code for every purpose: a login code that also approves a new payee lets a fraudster reuse a code obtained under a different pretext.
- SMS as the recovery root: passkeys or app approval at login, but MFA reset by a single SMS, so SIM swap still wins.
- Codes leaked by the API: verification endpoints returning the code or logging it in plain text for debugging.
- Friction everywhere: mandatory OTP on every login drives abandonment, and support teams then add weak bypasses that fraudsters learn.
Practitioner checklist
- Inventory every OTP flow, channel and provider.
- Use CSPRNG, six or more digits, single use, request bound codes with lifetimes of 10 minutes or less.
- Keep attempt counters across resends and cap sends per account, number and IP.
- Name the action and amount in messages and state that you will never ask for the code.
- Use the origin-bound SMS format, SMS Retriever and one-time-code autofill hints.
- Check SIM swap and porting signals before sending codes for recovery and payments.
- Step up to passkeys or in-app approval for high risk actions, with cooling off after contact changes.
- Monitor relay, sharing and pumping signals alongside conversion metrics.
- Offer passkeys and make OTP the fallback.
Standards and references
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- OWASP: Application Security Verification Standard 5.0
- OWASP: Multifactor Authentication Cheat Sheet
- W3C WICG: Origin-bound one-time codes delivered via SMS
- Google: SMS Retriever API, perform SMS verification on a server
- Canadian Anti-Fraud Centre: Protect your one-time passcodes
- MITRE ATT&CK: Multi-Factor Authentication Interception
Related NHI Mgmt Group resources: SMS Pumping and IRSF Guide · SIM Swap Fraud Guide · AiTM Phishing Guide · Account Takeover Prevention Guide · Passkey Rollout Guide