Smishing (SMS-based phishing)
Smishing is phishing delivered by SMS. The technique is unchanged — impersonate something trusted, create a reason to act — but the channel strips away most of the cues people use to judge a message, and adds a delivery mechanism with almost no sender authentication. That combination is why it converts better than email phishing.
| Name | A contraction of SMS and phishing |
| Channel weakness | SMS has no meaningful sender authentication; the displayed sender can be set |
| What the format removes | Sender address, hover-to-inspect, full URL visibility, formatting cues |
| Common pretexts | Failed parcel delivery, unpaid toll, bank security alert, tax refund, account suspension |
| Link handling | Shortened URLs are normal in SMS, which removes the last inspection route |
| Frequent objective | A one-time code, wallet provisioning approval, or credentials |
| Escalation path | Feeds SIM swap and mobile wallet provisioning attacks |
| Reporting | Chronically low — most recipients simply delete |
Why the channel is the problem
Almost everything that makes email phishing detectable is missing from SMS, and none of it is an accident of design so much as a consequence of the format.
| Inspection method | SMS | |
|---|---|---|
| Sender address | Visible, and checkable against the display name | A short code or number with no meaningful authentication |
| Hover to see a link target | Standard practice | Not available on a touchscreen |
| Full URL visible | Usually | Rarely — shortened links are the norm |
| Formatting and branding cues | Present, and often wrong in a fake | Almost none — all messages look alike |
| Organizational filtering | Mature | Largely carrier-side and outside the employer’s control |
The last row is the one organizations underestimate. A company can filter its own email. It cannot filter its employees’ text messages, and on a personal device it has no visibility at all — which means a channel with weaker inspection and better conversion is also the one the security team cannot see.
The pretexts, and why they work
Smishing pretexts cluster around things people are actually expecting: a parcel that needs redelivery, an unpaid road toll, a bank alert about a transaction, a tax refund. Each is common enough that a meaningful share of recipients are actually waiting for that message when it arrives.
The format helps the attacker again. A text message is expected to be terse, so the absence of detail raises nothing. It is expected to contain a shortened link, so the shortening raises nothing. And it arrives on a device the recipient checks in seconds, often while doing something else — which is exactly the condition under which people act before evaluating.
Why this matters for identity verification
Smishing is rarely the end of anything. What makes it consequential is what it is usually collecting.
A great deal of it targets one-time codes. A message claiming a suspicious transaction, followed by a call or a second text asking the recipient to confirm the code they have just received, delivers the second factor directly to the attacker. Everything described under multi-factor authentication about relayable factors applies, with a shorter path.
Two escalations follow from that. It supports SIM swap, where the aim is control of the number itself — after which every signal described under phone risk looks clean. And it supports fraudulent wallet provisioning, where a stolen card is loaded onto the attacker’s device and the provisioning check is a one-time code the victim was just persuaded to read out. That is the whole of mobile payment fraud in one message.
The pattern is consistent: a control resting on possession of a phone number is defeated by an attack on the phone number. What answers it is evidence rather than possession — identity document verification at provisioning and recovery, which asks something a text message cannot extract. Synthetic and stolen identity controls address what the access is ultimately used for.
What defenses can’t do
Organizations cannot filter personal messages. SMS filtering is carrier-side, and on an employee’s own phone the employer has no visibility.
Sender numbers prove nothing. Displayed senders can be set, and legitimate organizations use a shifting range of short codes, so recipients cannot learn a reliable pattern.
Blocking shortened links is impractical. Legitimate senders use them too, because the format encourages it.
Reporting is too sparse to rely on. Most recipients delete rather than report, so volume is systematically understated and campaigns are detected late.
Frequently asked questions
What is smishing?
Phishing delivered by SMS. The technique is the same — impersonate something trusted and create a reason to act — but the channel removes most of the cues people use to assess a message, including the sender address, the ability to inspect a link, and formatting.
Why is smishing more effective than email phishing?
Because the format removes the inspection routes. There is no hoverable link, shortened URLs are normal rather than suspicious, terseness is expected so missing detail raises nothing, and messages arrive on a device people check in seconds while doing something else.
What do smishing attacks usually want?
Frequently a one-time code. A message about a suspicious transaction, followed by a request to confirm the code just received, delivers the second factor directly. That code then enables account access, a SIM swap, or fraudulent provisioning of a stolen card into a mobile wallet.
Can organizations block smishing?
Only partially. SMS filtering happens at the carrier rather than the organization, and on personal devices the employer has no visibility at all. The practical defense is removing the value of what smishing collects — using authentication that cannot be relayed, and verifying identity with evidence at recovery and provisioning.
Related reading
- Phishing — the parent technique and the channel comparison
- Phone risk — what a SIM swap does to every phone signal at once
- Mobile payment fraud — where a harvested one-time code is often spent
- Multi-factor authentication — why a code a person can read out is a relayable factor
