Verification Code Scams: How They Work and What to Do

A verification code is the last thing standing between a criminal who already has your password or phone number and your account, so the scam is simply to get you to read it out. Codes sent by text, email or an authenticator app are meant to prove the account holder is present, but they prove nothing if the holder can be talked into passing them on. The scripts vary (a "buyer" checking you are real, a friend who "sent you a code by mistake", a bank fraud team "securing" your account) and the outcome is the same: account takeover, a hijacked messaging profile or a phone number registered in your name. This guide explains the common scripts, why each code is valuable to the attacker, what to do in the first hour after sharing one, and how security and fraud teams can reduce these losses through awareness, message design and stronger authentication. It is written for awareness leads, fraud and help desk teams, and anyone who explains these scams to staff, customers or family.

Key takeaways

Anyone who asks for your code is the scammer. The US Federal Trade Commission's guidance is blunt: a verification code is only for your own login, and a request to share one from someone you did not contact first is a scam every time.
The code authorises whatever the criminal is doing right now. It may be a bank login, a password reset, a new messaging registration or a payment approval, and the person asking will not tell you which.
Speed matters after a mistake. Contact the provider through its own app or a known number, reclaim or lock the account, change the password and revoke other sessions, then report it.
Awareness alone will not fix it. NIST SP 800-63B-4 states that OTP and out-of-band authentication are not phishing resistant; organisations should move important accounts towards passkeys or other phishing-resistant MFA.
Message design helps. A code message that names the service and the action, and says "we will never ask for this code", gives the victim a last chance to notice the mismatch.

How verification code scams work

Every version follows the same three steps. The criminal starts an action that triggers a code to your phone or inbox (a sign-in, a password reset, a new device registration or an account creation that uses your number). At the same moment they contact you with a believable reason why you will receive a code. Then they ask you to read it back, forward it or type it into a page they control. The Vishing and Smishing Guide covers the delivery channels; this guide focuses on the code itself.

The FTC's consumer guidance describes the pattern from the victim's side: the caller often poses as a trusted organisation, may already know details about you, says there is a problem with your account or that someone is misusing your identity, and then asks for the code they have just triggered. With your password already in hand, the code is the only thing they lack.

The common scripts and what the code unlocks

Script	What you are told	What the code actually does	Source
"Prove you are real" marketplace buyer	A buyer on a selling site, or someone who "found your lost pet", wants to confirm you are a real person and texts you a code	Links a Google Voice number to your phone number, which the criminal then uses to scam others while hiding their identity	FTC consumer alert, October 2021
"I sent my code to you by mistake"	A message from a friend's account, often in a shared group, asks you to forward a six-digit code that "should have gone to them"	Registers your messaging account (for example WhatsApp) on the criminal's phone and locks you out; they then repeat the trick on your contacts	Action Fraud warning, March 2023
Bank or card "fraud team"	Suspicious activity on your account; read back the code to verify yourself or to stop a payment	Completes the criminal's sign-in, adds their device or approves a payment or transfer	FTC consumer alert, 2024
Retailer, delivery or tech support	A refund, a failed delivery or a "hacked account" that needs a code to resolve	Resets the password on your retail, email or cloud account	Pattern described in FTC guidance on verification codes
Fake sign-in page	A link to a page that looks like your bank or employer asks for your password and then the code	Relays both to the real site in real time, giving the criminal a live session	Real-time phishing relay; see the Twilio case below
Employer help desk or IT	IT is "migrating your MFA" and needs the code you are about to receive	Enrols the criminal's device as your MFA method or completes a VPN or SSO login	Help desk social engineering pattern

The workplace version matters because one employee's code can open the whole organisation. In the Twilio breach (2022), SMS phishing sent employees to fake sign-in pages that captured credentials, opening a supply chain path to Signal and over a hundred other organisations. See the Vishing and Help Desk Social Engineering Awareness Guide for the staff-facing scripts.

Red flags people can learn

You did not start it: a code arrives when you were not signing in, resetting a password or making a payment. Someone else triggered it.
Someone asks for it: no bank, retailer, platform or employer needs you to read a code to them. The code is for typing into the official app or site that you opened yourself.
The message and the story do not match: the text says "WhatsApp registration code" or "Google Voice" but the caller says it is a delivery check. Read the whole message before acting.
Urgency and sympathy: "your savings are being drained right now", "I am locked out and need it urgently". Pressure is the tool that stops you reading.
They already know things about you: a caller who knows your address, last transaction or bank name may have bought leaked data. Knowledge is not proof of identity.
Requests to move money: the FTC notes that anyone who tells you to move money to keep it safe is a scammer.

The single habit to teach is "stop, hang up, call back": end the contact, then reach the organisation through the number on your card, statement or official app. The Impersonation Scams Guide covers that habit in depth.

If a code has already been shared

Time matters because the criminal will change the password, add their own MFA method or move money quickly. A practical first-hour sequence:

Identify which account: read the code message again. It usually names the service (bank, WhatsApp, Google, Microsoft, a retailer).
Contact the provider directly: for banks and card issuers, call the number on the card or statement and say you shared a verification code; the FTC advises telling the bank straight away, especially if money moved.
Reclaim the account: sign in on your own device and reset the password; for messaging apps, re-register your number (which sends a new code to you) and turn on the app's two-step PIN. For Google Voice, the FTC points victims to Google's steps for reclaiming a linked number.
Remove what the criminal added: sign out other sessions and devices, remove unknown MFA methods, recovery emails, phone numbers and forwarding rules. See the Hacked Social Media or Email Account Recovery Guide.
Warn contacts: a hijacked messaging account is used to target your contacts with the same script.
Report: in the UK to Report Fraud (which replaced Action Fraud on 4 December 2025); in Scotland, to Police Scotland on 101; in the US to ReportFraud.ftc.gov. See the Consumer Reporting Routes Map for other countries.
Check for wider exposure: if your password was also known, change it everywhere it was reused and watch for SIM swap signs such as sudden loss of mobile signal. See the SIM Swap Fraud Guide.

What organisations can do

Awareness campaigns help, but the strongest controls change the code itself or remove it.

Control	What it stops	Trade-off	Who it suits
Phishing-resistant MFA (passkeys, FIDO2 security keys, PKI smart cards)	Read-back and fake-page relay, because there is no code to pass on and the credential is bound to the real site	Enrolment and recovery effort; device support	Workforce accounts, admins, high-value customer accounts
Number matching on push approvals	Blind approval of push prompts (push fatigue)	Still not phishing resistant against a live relay	Workforce MFA where FIDO2 is not yet possible
Purpose-bound code messages	Read-back scams where the message names a different action than the caller's story	Longer SMS; needs careful wording	Any service sending codes
Risk checks before sending SMS codes (SIM change, porting, new device)	Codes sent to a number that has just been hijacked	Needs carrier or risk data; may add friction	Banks, telecoms, large consumer platforms
Transaction confirmation in the app (showing payee and amount)	Approval of a payment the victim thinks is a "security check"	Requires an app channel	Banking and payments
Help desk verification that never uses codes read over the phone	Attackers posing as users, and staff being asked for codes	Slower identity checks	Every organisation with a help desk

CISA's fact sheet on implementing phishing-resistant MFA describes FIDO/WebAuthn as the only widely available phishing-resistant authentication, calls SMS and voice a last resort because of phishing, SS7 exploitation and SIM swap, and lists app-based OTP as vulnerable to phishing. NIST SP 800-63B-4 classes SMS and voice delivery of codes as a restricted authenticator, tells verifiers to consider SIM change, device swap and number porting before sending a code, and requires verifiers at AAL2 to offer at least one phishing-resistant option. See the Phishing-Resistant MFA Guide.

Writing a safer code message

Name the service and the action: "Your [Service] code to sign in on a new device is 123456", not just "Your code is 123456".
State the rule: "We will never call or message you to ask for this code. Do not share it."
Keep it short-lived and single-use, and limit attempts. The OTP security guide covers expiry, attempt limits and domain-bound code formats for service designers.
Send a follow-up notice after a new device, recovery change or payee is added, through a different channel where possible.

Implementing an awareness and reduction programme

Baseline: pull fraud, help desk and incident records for the last 12 months tagged as code sharing, account takeover or messaging hijack. Note the scripts used.
Fix the message first: rewrite your own code messages to name the action and carry the "never share" line. This is cheap and reaches every user.
Set the help desk rule: staff never ask for codes, and a policy that callers asking staff for codes are escalated. Publish it so users can recognise impostors.
Train with real scripts: short scenarios based on the table above, delivered to staff and, for consumer services, in-app. Avoid generic slideware.
Pilot stronger MFA: start with administrators and finance roles on passkeys or security keys, then broaden. Keep a recovery path that does not depend on a code read over the phone.
Measure and adjust: track the metrics below quarterly and retire scripts that no longer appear.

Rollback is rarely needed for awareness work, but MFA changes need a fallback: keep the previous method registered for a defined pilot period and monitor lock-out tickets before removing it.

Detection and measurement

Code requested, then success from a new device or location within minutes, particularly after a password reset.
Multiple code requests to one number for different services in a short window, which can indicate a criminal working through the victim's accounts.
New MFA method or recovery phone added straight after a code-based sign-in.
Help desk calls where the caller asks staff to read or accept a code.

Metrics that show progress:

Account takeover cases where a shared code was the entry point, per quarter.
Percentage of privileged and high-value accounts on phishing-resistant MFA.
Median time from victim report to account lock or recovery.
Rate at which staff report code-request attempts (a rising report rate with falling losses is a good sign).
Percentage of outgoing code messages that name the action and include a do-not-share line.

Common failure patterns

Codes that say nothing about their purpose. "Your code is 482913" lets the criminal attach any story to it.
Organisations that do sometimes ask for codes. If your own agents ever request a code to "verify" a caller, you have trained customers to comply with criminals.
Relying on SMS codes for administrators. NIST and CISA both treat SMS as a weak option; a single read-back can hand over a privileged session.
Recovery paths that bypass strong MFA. A passkey-protected account that can be reset with an SMS code is only as strong as that code. See the Account Recovery and Help Desk Security Guide.
Awareness that blames the victim. People who feel foolish report late or not at all, which costs the recovery window.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-63B-4	Sec. 3.1.3.3 PSTN out-of-band (restricted); Sec. 2.2.2 AAL2 phishing-resistant option	SMS and voice codes as a restricted authenticator; offering a phishing-resistant alternative
NIST SP 800-53 Rev. 5	AT-2 and AT-2(3) Social Engineering and Mining; IA-2 Identification and Authentication	Awareness of code requests; strength of authentication
NIST CSF 2.0	PR.AT-01; PR.AA-03	Awareness and training; users are authenticated
MITRE ATT&CK (enterprise)	T1111 Multi-Factor Authentication Interception; T1566.004 Spearphishing Voice; T1684.001 Impersonation; T1621 Multi-Factor Authentication Request Generation	How codes and approvals are captured or coerced
MITRE ATT&CK (mobile)	T1451 SIM Card Swap	Redirecting SMS codes without the victim's help

Practitioner checklist

Rewrite every code message you send to name the service and action and include a do-not-share line.
Publish and enforce a rule that staff never ask customers or colleagues for codes.
Train staff and customers with the real scripts: marketplace buyer, "code sent by mistake", bank fraud team, IT migration.
Give a clear first-hour response: which number to call, how to reclaim accounts, where to report.
Move administrators and finance roles to passkeys or security keys first.
Check SIM change and porting signals before sending SMS codes for high-risk actions.
Alert on new MFA methods or recovery details added straight after code-based sign-in.
Close recovery paths that let a single code bypass stronger MFA.

Standards and references

Related NHI Mgmt Group resources: OTP security · Vishing and Smishing Guide · Phishing-Resistant MFA Guide · MFA Fatigue and Bypass Guide

Verification Code Scams Guide: Spot the request and protect accounts