SIM-based Authentication vs SMS OTP: Silent Network Auth

SMS one-time passcodes are still the default second step for most consumer services, yet the code can be phished, relayed, intercepted or redirected by a SIM swap, and the user does all the work of typing it. SIM-based or network-based authentication, often marketed as silent network authentication, takes a different approach: the mobile operator confirms in the background that the phone number a user claims is the one attached to the SIM in the device making the request, with no code to read or type. This guide compares the two on threat model, architecture, SIM swap signals, coverage and privacy limits, and the push fatigue trap teams fall into when they move away from SMS. It uses the open CAMARA Number Verification and SIM Swap API definitions as the reference architecture and ends with a decision guide for fraud and identity teams. It is for fraud managers, customer identity architects and product owners of sign-up, login and payment flows. Facts were checked on 14 November 2026.

Key takeaways

Network verification removes the code, and with it most phishing. There is no secret for a fake site or a social engineer to collect, because the operator checks the SIM and connection directly. The CAMARA definition guarantees no user interaction.
It proves the SIM, not the person. A stolen unlocked phone or a successful SIM swap passes number verification just as it receives an SMS code. Pair it with a SIM swap check and device signals.
A SIM swap check strengthens both methods. Asking the operator whether the SIM changed in the last few hours, before trusting an SMS code or a silent check, is the cheapest anti-account-takeover control available for phone-based flows. NIST SP 800-63B-4 tells verifiers to consider SIM change and porting before sending a PSTN secret.
Coverage decides rollout, not security. Silent checks need operator support and, without a GSMA TS.43 token, an active mobile data connection. Keep SMS OTP as a fallback and measure how often it is used.
Do not swap SMS for push approve buttons. NIST no longer accepts simple approve-on-the-second-device flows because of authentication fatigue. For high value accounts the destination is passkeys; phone-number methods are a step on the way.

How each method works

SMS OTP

The service generates a short random code, sends it by text message to the registered number, and asks the user to type it back within a time window. Delivery passes through an SMS aggregator, the operator's messaging core and the radio network to whichever SIM currently holds the number. The code proves only that someone could read a message sent to that number and chose to type it into the page in front of them. NIST SP 800-63B-4 classes out-of-band authentication over the public switched telephone network (PSTN) as "restricted" (Section 3.1.3.3) and states that out-of-band authenticators are not phishing resistant (Section 3.1.3). Code design and abuse controls are covered in the OTP security guide.

Network-based and SIM-based verification

The CAMARA project, an open source project hosted under LF Projects with requirements supplied by the GSMA Operator Platform Group for GSMA Open Gateway, publishes the Number Verification API. Release r4.2 contains version 2.1.1. It defines two mechanisms:

Network-based authentication: the operator knows which subscriber a connected mobile device belongs to and its phone number. Without a temporary token, the app runs an OpenID Connect authorisation code flow with prompt=none while the device is on the mobile network, and the operator recognises the connection.
SIM-based authentication: the operator issues a temporary token on the device under GSMA TS.43. With that token the check "works over all connections e.g. WiFi", and the backend presents it through CIBA (login_hint=operatortoken:<token>) or a JWT bearer grant.

The resulting access token is three-legged, tied to the network-authenticated subscriber, single use, never refreshable and valid for at most 300 seconds. The service then calls /verify with the number the user entered, in plain text or as a SHA-256 hash of the E.164 number, and receives devicePhoneNumberVerified true or false. Alternatively /device-phone-number returns the number itself. The specification states that SMS OTP and password logins are incompatible with this API, because the point is to validate the number actually in use.

Side-by-side comparison

Dimension	SMS OTP	Network or SIM-based verification
What is proven	Someone read a text sent to the number and typed the code	The device making the request uses the SIM currently assigned that number
User action	Wait, read, type a code	None; failure if interaction would be needed
Phishing and relay	Code can be captured by a fake page and replayed in real time	No transferable secret; the check is bound to the device's connection or operator token
Interception	Exposed to SS7 and Diameter abuse, malware reading messages, lock screen previews	No message to intercept
SIM swap	Code goes to the attacker's SIM	Check passes on the attacker's device; needs a SIM swap signal
Coverage	Almost any phone that can receive texts	Supported operators only; mobile data needed unless a TS.43 token exists
Channel	Any device can type the code, including a laptop	The check runs on the phone that holds the SIM
Cost risk	Per message fees and artificially inflated traffic	Per API call fees agreed with an operator or aggregator
Privacy	Number shared with message aggregators	Operator processes the request; consent may be collected under local law
NIST SP 800-63B-4 view	Restricted PSTN out-of-band authenticator	Not described as an authenticator type; treat as a possession and risk signal

Threat model: why SMS OTP fails

Real-time phishing and relay (ATT&CK T1111): an adversary-in-the-middle page asks for the password, triggers the real SMS, and asks for the code, which it replays before expiry. In the Twilio Breach 2022, text messages lured staff to fake single sign-on pages that relayed passwords and one-time codes in real time; the fallout included about 1,900 Signal users' numbers exposed to possible re-registration on other devices.
Social engineering for the code: callers posing as the bank or support ask the user to read the code aloud. Message wording helps, but cannot stop a determined victim. See the Vishing and Smishing Guide.
SIM swap and port-out (ATT&CK T1451, mobile): the attacker convinces or bribes the operator to move the number to a new SIM or another operator, then receives every code. See the SIM Swap Fraud Guide.
Signalling abuse: SS7 and Diameter weaknesses allow message rerouting by parties with interconnect access. See the SS7 and Diameter Signalling Security Guide.
Device-side exposure: notifications on locked screens, message forwarding and malware that reads texts.
Number recycling and stale numbers: operators reassign numbers; a number registered years ago may belong to someone else today.

Threat model: where network verification fails

SIM swap still wins: once the number sits on the attacker's SIM, the operator truthfully reports that the requesting device holds that number. This is why the check must be paired with a SIM swap query.
Stolen or borrowed device: anyone holding the unlocked phone passes. Silent checks prove possession of the SIM, not the identity or presence of the account holder.
App and backend weaknesses: the verification only helps if the server binds the access token to the session it is protecting. A backend that trusts a client-reported "verified" flag, or reuses tokens, loses the guarantee. CAMARA's single-use, 300-second token rule exists to prevent replay.
Insider and operator process risk: the result is as good as the operator's subscriber records and SIM issuance controls.
Mis-scoped trust: treating a number match as full authentication for high value actions, when it is one possession signal.

The two methods therefore share one dominant weakness, control of the phone number at the operator, and differ on everything else. Network verification removes the user-transferable secret; it does not remove dependence on operator account security.

SIM swap signals

The CAMARA SIM Swap API (sim-swap, with sim-swap-subscriptions for event notifications; the CAMARA project page listed sim-swap v2.1.0 when checked in November 2026, so confirm the current release in the CAMARA repository) offers two operations:

Operation	Input	Output	Typical use
`POST /retrieve-date`	Phone number (two-legged token) or subject from a three-legged token	`latestSimChange` timestamp, or `null` with an optional `monitoredPeriod` where privacy rules limit retention	Risk scoring, case investigation
`POST /check`	Phone number and `maxAge` in hours (1 to 2,400)	`swapped` true or false	Gate before sending an SMS code, changing a number, or releasing a payment

The definition counts more than a replacement SIM as a swap: a number change, porting to a new provider, activating an additional SIM on the same number (multi-SIM) and a new subscription all register. Expect legitimate positives after phone upgrades and design a step-up path rather than a hard block. When a provider cannot return the date for privacy reasons, it returns null; treat that as unknown, not as safe.

On the operator side, regulation is raising the bar. In the United States, FCC Report and Order 23-95 (WC Docket No. 21-341, adopted 15 November 2023) requires wireless providers to use secure methods to authenticate customers before SIM changes and port-outs, rules out methods based on readily available biographical, account, payment or call detail information, requires immediate notification of SIM change and port-out requests, and gives customers the option to lock their accounts against them. Fraud teams should still treat operator controls as a layer they do not own.

Coverage and privacy limits

Operator support: each operator decides whether and how to expose these APIs, often through aggregators. Coverage varies by country and operator, so measure the share of your users who can complete a silent check.
Connection type: the network-based flow needs the device on mobile data; on Wi-Fi it fails unless the app holds a TS.43 temporary token. Users who disable mobile data, or desktop users, fall back.
Same device only: the check validates the phone that makes the request. A desktop login cannot be silently verified unless the flow hands off to the phone.
Consent and purpose: CAMARA requires three-legged tokens where personal data is processed and users can exercise opt-in or opt-out rights, and leaves consent collection to the provider under local law (OIDC Section 3.1.2.4). Expect a consent screen in some markets, which breaks the "silent" promise.
Data minimisation: prefer /verify with a hashed number over /device-phone-number, which discloses the number. Record the purpose and lawful basis for SIM swap lookups, and keep results only as long as the fraud case needs.
Accessibility: NIST SP 800-63B-4 requires verifiers using the PSTN to offer alternative authenticator types, because not everyone has telephone or mobile coverage. The same applies to silent checks.

Push fatigue: the wrong replacement

Teams moving off SMS often reach for an in-app push with an Approve button. NIST SP 800-63B-4 states that a method that asks the user to compare secrets and approve on the secondary channel is no longer acceptable because of authentication fatigue attacks; the secret must move between the out-of-band device and the primary channel, and verifiers sending push notifications should limit how many are sent since the last successful authentication. Attackers exploit approve prompts with repeated requests (ATT&CK T1621). If you use push, require the user to enter a value shown on the primary channel into the app, rate limit prompts, and show context. See the MFA Fatigue and Bypass Guide.

Network verification avoids prompts altogether, which makes it attractive for low friction sign-up and login. It is not a substitute for phishing-resistant authentication on high value accounts; see the Phishing-Resistant MFA Guide and the Passwordless and Passkeys Guide.

Fraud-team decision guide

Use case	Recommended pattern	Why
Sign-up: confirm the number belongs to the device	Silent number verification first; SMS OTP fallback	Removes code friction and confirms the number is on the device signing up
Returning login on mobile app	Passkey where enrolled; otherwise silent verification plus SIM swap check	Phishing resistance first; silent check as a low friction possession signal
Login on desktop web	Passkey or authenticator; SMS OTP only with SIM swap check	Silent checks need the phone's connection
Change of phone number, email or payee	SIM swap `check` with a short `maxAge`, then step-up that does not rely on the phone number	These are the actions a SIM swapper takes first
High value payment	Strong authentication bound to the transaction; SIM swap as a risk input	Number verification is not transaction signing
Account recovery	Do not rely on phone number alone; add document, passkey or in-person routes	Recovery is where SIM swaps succeed. See the Account Recovery and Help Desk Security Guide

Small versus large organisations: a small service can add a SIM swap check before every SMS code through an aggregator with little engineering, which closes the largest gap at low cost. A large bank or marketplace should run silent verification and SIM swap as inputs to a risk engine, measure coverage by operator and country, and plan the move of high value customers to passkeys.

Worked scenario

A digital bank sends SMS codes at login and for new payees. It sees account takeover cases where the victim reports that their phone lost signal shortly before.

Diagnose: case review shows a pattern consistent with SIM swaps: a recent SIM change, then login from a new device, then a payee added.
Quick win: before sending any SMS code, the backend calls SIM Swap check with maxAge of 72 hours. If swapped is true or the result is unknown, the code is not sent and the user is routed to a stronger step-up (passkey or in-app approval with a typed value, or a branch or video check).
Reduce friction: in the mobile app the bank adds silent number verification at login. The backend compares the entered number using /verify with a hashed number, consumes the single-use token immediately, and binds the result to the login session.
Fallback: users on Wi-Fi without a TS.43 token, or on unsupported operators, get SMS OTP with the SIM swap gate.
Destination: the app offers passkey enrolment after every successful login and removes SMS for customers who enrol, keeping it only for recovery with extra checks.
Measure: the bank tracks SMS sends, silent coverage, SIM swap hits and the account takeover rate monthly.

How to implement

Baseline: measure SMS volumes, delivery failure, cost, and account takeover cases linked to phone number control.
Add the SIM swap gate first: query before SMS sends and before sensitive changes. Start in log-only mode for two to four weeks to set maxAge and see the false positive rate from upgrades.
Pilot silent verification: in the mobile app for one country or operator set, behind a feature flag, with SMS fallback. Check consent screens and latency.
Harden the backend: perform the API call server side, never trust a client verdict, enforce single use and the 300-second limit, store only the boolean result and correlation identifier.
Expand by coverage: add operators and countries as success rates meet target; keep SMS for the rest.
Roll back: the feature flag returns users to SMS OTP with the SIM swap gate; never remove the fallback until coverage is proven.
Move high value users to passkeys: treat phone-based methods as transitional for them.

Detection and measurement

Log: method used, operator response, SIM swap result and age, fallback reason, and session binding, for every authentication and sensitive change.
Silent coverage rate: share of mobile sessions where silent verification completes.
SMS fallback rate: should fall as coverage grows; a sudden rise suggests an operator outage or abuse.
SIM swap hit rate and conversion: hits per thousand checks, and how many hit users later complete step-up.
Phone-linked account takeover rate: confirmed cases per 100,000 active accounts, the outcome metric.
SMS cost per successful login: exposes inflated traffic and the savings from silent checks.

Common failure patterns

Treating a number match as identity: using silent verification alone to authorise payee changes or recovery.
Skipping the SIM swap check: moving to silent verification and assuming SIM swap is solved, when it is not.
Treating null as clean: a SIM swap date withheld for privacy is unknown risk.
Client-side verdicts: letting the app report "verified" without the server calling the API and binding the token to the session.
Approve-button push as the SMS replacement: trading one phishable method for one vulnerable to fatigue.
No fallback: locking out users on Wi-Fi, abroad or on unsupported operators.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-63B-4	Section 3.1.3.3	PSTN restricted; alternatives required; consider SIM change and porting before sending
NIST SP 800-63B-4	Section 3.1.3	Out-of-band not phishing resistant; approve-only push not acceptable
NIST CSF 2.0	PR.AA-03	Users, services and hardware are authenticated
NIST CSF 2.0	DE.CM-03	Monitoring of activity for SIM swap and account takeover signals
NIST SP 800-53 Rev. 5	IA-2, IA-5	Authentication and authenticator management, including phone number binding
NIST SP 800-53 Rev. 5	IA-11	Re-authentication before sensitive changes
MITRE ATT&CK	T1111, T1621, T1451 (mobile)	MFA interception, MFA request generation, SIM card swap

Practitioner checklist

Query SIM swap status before sending SMS codes and before changes to phone, email, payee or recovery settings.
Treat an unknown SIM swap result as elevated risk.
Run silent number verification server side, with single-use tokens bound to the session.
Prefer hashed number verification over retrieving the number.
Keep SMS OTP as a measured fallback, and offer non-phone alternatives for accessibility.
Never use approve-only push; require a typed value and rate limit prompts.
Do not let phone number control alone recover an account.
Track coverage, fallback, SIM swap hits and phone-linked takeover monthly.
Plan passkeys as the destination for high value customers.

SIM-based Authentication vs SMS OTP: Silent Network Auth and the End of Texted Codes