Smishing works because a phone is a worse place to be careful
The same person who spots a phishing email at their desk taps the link on their phone. That is not a training failure — the device is structurally worse at this.
Organisations that have spent years on phishing awareness still get caught by SMS. The usual explanation is that users need more training.
We think that is close to backwards. The people falling for these messages are frequently the same people who correctly report the desktop version of the same lure. What changed is not their judgement. It is the device.
What the desktop gives you that the phone does not
Line up the two experiences.
A filtered gateway. Corporate email passes through a security gateway that has already removed most of what would have arrived. SMS, RCS and third-party messaging apps have nothing equivalent — the message goes from the sender to the handset with nothing in between that answers to you.
A visible sender. In a desktop client the full address is visible and the display-name trick is easy to catch. On a handset the sender is a phone number, or an alphanumeric sender ID that anyone can set to a bank’s name, sitting in the same conversation thread as legitimate messages from that bank.
A full URL. Hovering shows the destination. On a phone there is no hover, the URL is truncated in the preview, and the address bar hides most of it once the page loads. A convincing subdomain is more than enough.
Context. At a desk the user is doing one thing. The phone is read while walking, in a queue, between meetings, on a notification that arrived mid-sentence. Every part of that reduces the attention available for a decision that depends on noticing a detail.
None of those is a user failing. They are properties of a small screen and a mobile context, and no amount of training removes them.
The lures that work here
The ones we see land most consistently in Australian organisations:
- Delivery and toll notifications. High base rate of legitimacy, trivially plausible, and the call to action is a payment page.
- MFA prompts and codes. “We detected a login, tap to verify.” The user has been trained to expect MFA prompts and to approve them, and on a phone the approval is one tap away from the message that requested it.
- Executive impersonation. A message claiming to be from a named senior person, usually asking for something time-critical and slightly irregular. Effective because the org chart is public and the sender is unverifiable.
- IT service desk impersonation. “Your password expires today.” Especially effective immediately after a real change announcement, which is why change communications are worth treating as sensitive information.
- Reauthentication after a real event. A message that arrives shortly after a genuine outage, referencing it.
What actually reduces it
Training has a floor and the mobile channel sits below it. Controls have to carry the weight.
Phishing-resistant MFA. The single highest-value change. Passkeys and FIDO2 security keys are bound to the origin, so a credential entered on a lookalike domain is useless — the attack fails even when the user does everything wrong. Push-approval MFA does not have this property, and SMS codes have the least of it.
On-device URL inspection. Because there is no gateway, the check has to happen on the handset, across every channel — SMS, messaging apps, mail and in-app browsers, not just the corporate mail client. This is squarely a mobile threat defence function, and one of the clearest reasons the capability exists.
A one-tap reporting path. If reporting a suspicious message takes more effort than deleting it, nobody reports and you lose the early warning. It needs to be as fast on mobile as it is in Outlook.
Number-matching on approvals. Removes the reflexive tap, which is the mechanic most MFA-fatigue attacks depend on.
Conditional Access on the outcome. Assume the credential is eventually phished. If the resulting sign-in still has to come from a compliant, managed device, the phished credential alone is not enough.
The training that does help
Awareness is not worthless — it is just badly targeted when it teaches people to inspect URLs on a device that hides them. What transfers:
- A channel rule rather than a judgement call. “We will never ask you to approve, pay or authenticate from a link in a text message.” Absolute rules survive a small screen; nuanced ones do not.
- A verification habit. One saved internal number to check anything unusual, regardless of who the message appears to be from.
- Explicit permission to be slow. Executive impersonation runs on urgency. Saying out loud that nobody will be penalised for taking ten minutes to verify a request removes the pressure the attack depends on.
- No blame for reporting a false alarm. The reporting rate is the metric that matters, and it collapses the first time someone is made to feel foolish.
The short version
Mobile phishing is not a training gap. It is a control gap, on the one device where the user has the least information and the least attention.
Put phishing-resistant MFA in front of the credential, on-device inspection in front of the link, and a compliant-device requirement behind both.
More on how we approach mobile security.