Skip to main content
Commerce Security Authority
Category: Fraud Typologies

Smishing

Also known as: SMS phishing, SMS-based phishing
Simply put

Smishing is a type of phishing attack carried out through SMS or text messages instead of email. Attackers send deceptive text messages designed to trick recipients into clicking malicious links, revealing sensitive information, or downloading harmful software. The term combines 'SMS' and 'phishing.'

Formal definition

Smishing is a social engineering attack vector that leverages SMS or text messaging to trick targets into disclosing sensitive information, clicking fraudulent links, or downloading malware. As a variant of phishing, it relies on manipulative messaging that impersonates trusted entities to induce a target action, differing from email-based phishing primarily in the delivery channel. In a payment security context, smishing may be used to harvest credentials or cardholder-adjacent personal data that can support downstream fraud such as account takeover or card-not-present fraud; the effectiveness of any single defensive control against it is limited, and it should be addressed as part of broader awareness and anti-phishing measures.

Why it matters

Smishing matters because it exploits a communication channel that many people treat as more trustworthy and immediate than email. Text messages are often read quickly and acted on without the scrutiny applied to email, which makes manipulative messaging that impersonates banks, card issuers, delivery services, or government agencies effective at inducing a target action. In a payment security context, the concern is not the text message itself but what it enables: harvested credentials, one-time passcodes, or personal data that can support downstream fraud such as account takeover or card-not-present fraud.

Because smishing relies on social engineering rather than a technical flaw in payment systems, it sits largely outside the direct control of the cardholder data environment and is not resolved by any single technical safeguard. It should be treated as one component of a broader anti-phishing and security awareness program. The effectiveness of any single defensive control against smishing is limited, and detection controls that flag suspicious messages carry the usual trade-offs of false positives and false negatives.

Exact figures on smishing prevalence and losses depend heavily on the source, reporting period, and methodology, so organizations should rely on qualitative understanding of the risk and their own measured data rather than assuming fixed rates.

Who it's relevant to

Fraud Analysts and Merchant Risk Teams
Smishing can be an upstream source of the credentials and personal data that later appear in account takeover and card-not-present fraud. Analysts should account for social-engineering-sourced compromise when investigating suspicious activity, while recognizing that detection and attribution are imperfect and that exact fraud rates depend on source and methodology.
Security Awareness and Anti-Phishing Program Owners
Because no single technical control reliably stops smishing, it is best addressed as part of broader awareness and anti-phishing efforts. Program owners should treat SMS as a channel that recipients often trust and act on quickly, and design education and reporting mechanisms accordingly.
Compliance Officers and Security Engineers
Smishing targets individuals rather than the payment infrastructure directly, so it generally falls outside the technical boundaries of the cardholder data environment. It should still be considered in risk assessments and awareness measures as a vector that can lead to credential or personal-data harvesting supporting downstream fraud.
Issuers, Acquirers, and Payment Processors
Attackers may impersonate these institutions in smishing messages to harvest credentials or one-time passcodes. Relevant parties should understand that such impersonation is a social engineering problem whose mitigation relies on customer awareness and layered defenses rather than any guaranteed single safeguard.

Inside Smishing

SMS or messaging vector
Smishing is social engineering delivered through SMS text messages, and by extension similar messaging channels such as RCS or over-the-top messaging apps. The delivery channel is what distinguishes it from email-based phishing and voice-based vishing.
Pretext and lure
A message crafted to create urgency or trust, often impersonating a bank, card issuer, payment processor, delivery service, or government entity, intended to prompt the recipient to act quickly without verifying the sender.
Malicious call to action
A link to a fraudulent site, a phone number to call, or a request to reply with information. The action is designed to harvest credentials or data or to induce an approval.
Targeted data
Smishing may attempt to elicit cardholder data such as PAN, expiration date, or cardholder name, and may also seek sensitive authentication data such as CVV2/CVC2/CID or a PIN. It can also target account login credentials, one-time passcodes, or authentication approvals used in account takeover.
Sender spoofing
Manipulation of the displayed sender ID or use of a lookalike short code or number so the message appears to originate from a trusted institution.
Downstream fraud outcome
Information or approvals obtained via smishing may be used to enable card-not-present fraud, account takeover, or bypass of authentication steps. Smishing is an initial-access technique rather than the fraud event itself.

Common questions

Answers to the questions practitioners most commonly ask about Smishing.

Is smishing just another word for phishing?
No. Smishing is a subset of social engineering that uses SMS text messages (and often extends to other messaging channels) as the delivery vector, whereas phishing traditionally refers to email-based lures. The underlying goal is similar—tricking a recipient into revealing credentials, cardholder data, or authentication codes, or into installing malicious software—but the channel, message format, and defensive controls differ. Because SMS lacks the header analysis, link rewriting, and attachment sandboxing common to email gateways, some anti-phishing controls do not translate directly to SMS.
Does receiving a smishing message mean an attacker already has my card data?
Not necessarily. Smishing messages are frequently sent in bulk to phone numbers obtained from many sources, and a message referencing a bank or card brand does not confirm that the sender holds any of your cardholder data or sensitive authentication data. Attackers often use generic templates hoping some recipients happen to be customers of the named institution. That said, a message containing accurate personal details may indicate a prior data exposure; the correlation depends on the specific incident and cannot be assumed from the message alone.
What information should staff and customers be warned never to send in response to a text message?
Guidance should emphasize that legitimate issuers and processors do not request sensitive authentication data—such as full PIN, PIN block, or the card verification value (CAV2/CVC2/CVV2/CID)—via text, and that these values must never be transmitted in an unsolicited SMS reply. It is also prudent to warn against sharing one-time passcodes used for multi-factor authentication or 3-D Secure step-up, the full PAN, and login credentials. Any request to relay such data through SMS should be treated as suspicious and verified through an independently obtained contact channel.
How does smishing interact with multi-factor authentication and one-time passcodes?
Smishing is commonly used to defeat authentication flows by prompting a victim to disclose a one-time passcode delivered by SMS or an authenticator, effectively enabling real-time relay or account takeover. This illustrates a known limitation of SMS-delivered one-time passcodes as an authentication factor. Organizations may mitigate this by favoring phishing-resistant authentication methods where feasible, adding transaction-context binding, and instructing users that a passcode should never be read aloud or forwarded to anyone. No single control eliminates this risk, and layered controls are generally recommended.
What detection and response controls help address smishing targeting an organization?
Practical measures may include user awareness training with reporting mechanisms, monitoring for brand-impersonation domains and lookalike short links, coordinating takedown of fraudulent landing pages, and correlating reported smishing campaigns with fraud monitoring and account-takeover signals. Detection controls carry false-positive and false-negative trade-offs: aggressive filtering of messaging content is limited by channel constraints, and reliance on user reporting produces incomplete coverage. These controls help reduce exposure but do not prevent all attempts.
How should a suspected smishing incident be handled from an incident-response and PCI DSS perspective?
A suspected smishing report should be routed through the organization's incident response process for triage, including determining whether any cardholder data or credentials may have been disclosed and whether affected accounts require containment such as credential reset or card reissue. If exposure of account data is confirmed, applicable card brand and network notification rules and internal PCI DSS incident-handling procedures should be followed; confirm current requirement wording against the published standard rather than assuming a fixed reference. Preserving message artifacts supports investigation and any coordinated takedown.

Common misconceptions

Smishing is the same as email phishing and is covered by the same controls.
Smishing uses SMS or messaging channels rather than email, so email-focused controls such as inbound mail filtering, DMARC, or attachment sandboxing do not apply. It requires channel-specific awareness and controls, and it overlaps with but is distinct from vishing, which uses voice calls.
Multi-factor authentication makes smishing harmless because a stolen password alone is not enough.
Smishing is frequently used to capture the second factor itself, such as a one-time passcode, or to induce the user to approve a push prompt. MFA may reduce the value of a stolen password, but it does not by itself eliminate the risk when the attacker manipulates the user into surrendering or approving the additional factor. MFA is intended to raise the difficulty of account takeover, not to prevent all social engineering.
Any sensitive authentication data captured by smishing is fine to store as long as the receiving system encrypts it.
Sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks must not be stored after authorization even when encrypted. A system that captures such data through a smishing lure and retains it does not become compliant by encrypting it. Some cardholder data may be stored only under defined PCI DSS controls.

Best practices

Educate cardholders and staff that legitimate institutions generally do not request PAN, CVV2/CVC2/CID, PINs, passwords, or one-time passcodes by text message, and encourage verification through an independently obtained contact channel rather than links or numbers in the message.
Include SMS and messaging-based social engineering explicitly in security awareness training and phishing-resistance programs, since email-focused training and controls do not address this channel.
Provide a clear, easy reporting path for suspected smishing so that lures impersonating your brand can be investigated and, where possible, reported to the relevant carrier, aggregator, or abuse channel.
Prefer phishing-resistant authentication where feasible and design authentication flows so that approval prompts and one-time passcodes convey enough context for a user to detect a fraudulent request, recognizing that no single control eliminates the risk.
Monitor for account takeover indicators following authentication events, and apply layered fraud detection for card-not-present transactions, acknowledging that detection controls involve false-positive and false-negative trade-offs.
Ensure that no capture point in your environment stores sensitive authentication data after authorization, and confirm handling of cardholder data against the current published PCI DSS rather than assuming a fixed requirement number.