Phishing in 2026: why the second factor isn't enough anymore

For years the advice against phishing stayed the same: check the sender, be suspicious of urgency, watch for spelling mistakes, turn on the second factor. The first three still help. The fourth fell short, and it's worth explaining exactly why, because a lot of companies believe turning on MFA closed the issue.

Phishing is still the most-used entry vector — in Q2 2026 it showed up in more than half of the incidents Cisco Talos responded to. What changed isn't how much it's used, but what it steals.

The shift: they no longer want your password

The classic attack sent you to a fake page, saved your username and password, and the attacker used them later. With MFA on, that stopped working: the password alone opened nothing.

Attackers' response was to stop stealing credentials and start stealing the session instead. The technique is called adversary-in-the-middle (AitM), and it works like this:

1. The link in the email takes you to a site that isn't a static copy of the real login: it's a proxy that forwards everything to the legitimate site in real time.
2. You see the authentic page, because it is the authentic page, served through the attacker.
3. You type your password. The proxy passes it through. The real site asks for the second factor.
4. You get the SMS code or the push notification. You approve it, because everything's going as it should.
5. The real site issues the session cookie — and that cookie passes through the proxy, which keeps a copy.

From there the attacker has an already-authenticated session. They don't need your password or your code: they get in with your cookie, which the server can't tell apart from yours.

Microsoft reported a 146% increase in AitM attacks during 2024, and the technique has since been industrialized into kits sold ready to use. In January 2026 the FBI documented a campaign by the Kimsuky group combining QR lures with AitM proxying to capture session tokens and bypass MFA on targeted accounts.

The other shift: the link isn't a link anymore

Corporate email goes through filters that analyze URLs: domain reputation, blocklists, link rewriting. So the lure moved to a format those filters don't read well — a QR code, usually inside an attached PDF or an image.

It's called quishing, and it gives the attacker a double advantage:

• The email scanner doesn't see the URL. It sees an image. Extracting a link from a QR code embedded in a PDF requires a step many gateways don't take.
• It moves the victim to their personal phone. That device almost never has the corporate machine's protections, and the small screen hides the full address bar.

Unit 42 (Palo Alto Networks) reported more than 11,000 malicious QR detections a day. In March 2026 an operation was documented running in three waves, specifically targeting corporate inboxes with this method.

The important detail: a QR code doesn't tell you where it goes. A text link can be inspected by hovering over it — a square of pixels can't.

What a current attack looks like, start to finish

Stage	2020 phishing	2026 phishing
Lure	Email with spelling mistakes	Correct text, written or polished with AI
Vector	Link in the body	QR in an attached PDF, or a link behind several redirects
Fake page	Static copy of the login	Live proxy of the real site
Prize	Username and password	Already-authenticated session cookie
Effect of MFA	Blocks the attack	Doesn't block it
Device	The corporate computer	The personal phone

The practical conclusion is that the indicators we used to teach people to look for — writing mistakes, clumsy urgency, obviously fake domains — filter out the old version of the attack. The current version avoids them almost entirely.

What still works

None of these measures depend on someone spotting the trick.

Passkeys (FIDO2/WebAuthn)

This is the only widely available defense that resists phishing by design, and the reason is technical, not statistical: the cryptographic key is bound to the domain that registered it. If the site asking for authentication isn't the right domain, the browser signs nothing. There's no code the victim can hand over, because there's no code.

An AitM proxy can't forward a passkey: what it would forward doesn't match its own domain, and the signature never gets produced.

Two honest caveats:

• Adoption is low. Different measurements put it around 19% of organizations, which means most are still exposed when they don't have to be.
• The fallback weakens it. In mid-2025 the PoisonSeed group managed to bypass FIDO keys by abusing the cross-device QR authentication flow — they didn't break the cryptography, they used the emergency exit. If SMS or code-based fallback stays enabled, the attacker will simply ask for that instead. Turning on passkeys without closing off the weak methods leaves the door open right next to the good lock.

Phishing-resistant MFA where passkeys aren't feasible yet

If passkeys aren't yet viable for the whole team, the order of preference is clear: physical security keys, then apps with number matching, then code apps, and SMS last. SMS is the weakest of all, and it's also vulnerable to number theft.

Shortening session lifetimes and watching how they're used

If the prize is the session cookie, then how much that cookie is worth matters. Sessions that expire, re-authentication for sensitive operations, and alerts when the same session suddenly shows up from another country or with a different user agent. An impossible login is easier to catch than the email that caused it.

Treating a QR code like an unknown link

A QR code in an email you weren't expecting is a link you can't inspect. The useful rule isn't "don't scan QR codes," which nobody follows: it's never authenticate on a site you reached by scanning a code. If a QR code leads to a login screen, that's the moment to close it and go in through the site you already know.

Training the team on the right attack

Training that teaches people to look for spelling mistakes prepares the team for the attack from six years ago, and leaves a false sense of coverage. What needs to get across today:

• That approving a legitimate MFA prompt can be part of an attack.
• That the signal is no longer in the message, but in the context: did I ask for this?
• That reporting a click shouldn't carry any cost. A stolen session reported within ten minutes can be revoked; one discovered in ten days can't.

To start this week

• Check which second factors are enabled on your corporate email and identity provider. If SMS is still active as a fallback, the rest of the chain is only as strong as SMS.
• Turn on passkeys wherever your provider supports them, starting with admin accounts.
• Check whether your email filter opens attached PDFs and extracts QR codes. If it doesn't, quishing reaches you unanalyzed.
• Define how a session gets revoked and who can do it. If that has to get figured out on the day of the incident, it's already too late.

In short

Phishing stopped being an attention problem and became an authentication architecture problem. As long as the security factor is something a person can read and hand over — a code, an approval, a cookie — a middleman can ask for it. Passkeys change that because they bind the credential to the domain, and that's where it's worth putting the effort.

---

This article was originally published in March 2024 and rewritten in September 2026. The earlier text described an attack that MFA still blocked; keeping it as-is would have meant vouching for a defense that no longer holds.

Let's talk about your company's security