Phishing and smishing: how they work and what actually stops them
Awareness training has never stopped a determined phishing campaign. What the attacks look like in 2026, why one-time codes are no longer enough, and the controls that work.
Phishing is a message that impersonates something trusted to obtain credentials, money or access. Smishing is the same attack over SMS. The channel changes the tactics, not the objective.
The reason to separate them is that SMS is a far weaker channel for the defender. Email carries authentication — SPF, DKIM and DMARC — that lets a receiver verify the sender's domain. SMS has no equivalent, sender IDs are trivially spoofed in many countries, and the display is too small to show a full URL. Advice built for email largely does not transfer.
The variants worth distinguishing
- Bulk phishing — the same message to millions. Low success rate, enormous volume.
- Spear phishing — tailored to one person using real details. Far higher success rate.
- Whaling — spear phishing aimed at executives, usually for payment fraud.
- Vishing — voice. Increasingly paired with the other channels.
- Quishing — a QR code instead of a link, which moves the victim onto a phone outside corporate filtering and hides the destination.
- Consent phishing — no credentials at all. The victim is asked to approve an OAuth application, which then holds legitimate API access that a password change does not revoke.
Why one-time codes stopped being enough
An attacker-in-the-middle kit such as Evilginx does not present a fake login page. It proxies the real one. The victim sees the genuine site, because it is the genuine site relayed through the attacker. They enter their password and their six-digit code, both are forwarded, and the attacker captures the resulting session cookie.
The session cookie is the prize. It represents an already-authenticated session, so the second factor has already been satisfied. Changing the password afterwards does not necessarily invalidate it.
This defeats SMS codes, authenticator apps and push notifications equally, because all three prove possession at one moment and produce a bearer token afterwards.
What actually stops it
Phishing-resistant authentication
FIDO2 and WebAuthn — hardware keys and passkeys — are the control that works, and the reason is mechanical rather than educational. The credential is bound to the origin at the browser level. When the browser is on micros0ft-login.com it will not release a credential registered to microsoft.com, and the user cannot override that. A proxy in the middle has nothing to relay.
Google reported zero successful phishing of its 85,000 staff after mandating security keys. That is not an awareness outcome; it is an architectural one.
Email authentication, enforced
SPF, DKIM and DMARC stop others sending as your domain. The essential detail is that DMARC does nothing at p=none — it only reports. Enforcement requires the policy to reject:
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"Start at p=none, read the reports until legitimate senders are all aligned, then move to quarantine and finally reject. Stopping at none — which is where most domains stop — provides visibility and no protection.
Make reporting effortless
A one-click report button in the mail client, with a response that thanks the reporter even when the message was legitimate, outperforms any training module. The goal is a short interval between the first delivery and the first report, because that is what allows the rest of the campaign to be pulled before anyone else opens it.
Indicators that still hold
- Urgency plus authority. Almost every campaign combines the two. Real requests survive a delay.
- A channel change. "Text me, I'm in a meeting" moves the victim somewhere with no authentication and no logging.
- Payment detail changes. Any request to alter bank details, however well documented, is verified by calling a number you already held.
- A link that must be opened on a phone. Usually an attempt to escape desktop filtering.
What to do about SMS specifically
Treat SMS as unauthenticated by default, because it is. Never use it as a second factor where an alternative exists; never send customers links by SMS, so that "we never send links" becomes a reliable rule your customers can apply. Where SMS is unavoidable, publish the exact sending number and tell people to check it.
