Your team rolled out MFA two years ago. SMS, push prompts, maybe TOTP. The board got the bullet point, the auditor got the checkbox. And yet, somehow, last quarter someone in finance got phished, sent a one-time code, and you paid for incident response anyway.
That's not a freak event. It's the default outcome of how most "MFA" is built today. The attackers have caught up — and a $300 phishing kit can defeat anything that asks the user to type a code, tap an approval, or confirm a push. The fix isn't more friction. It's a different model.
The phishing kit economy
In 2023 we started seeing turnkey adversary-in-the-middle (AitM) phishing kits go mainstream. Evilginx, EvilProxy, and Tycoon 2FA sit in front of the real login page, proxy every request, and lift the session cookie after the user has happily typed the code from their authenticator app.
The user sees the real Microsoft / Google / Okta login flow. The kit sees the credentials, the MFA response, and the cookie the IdP issues after a successful login. Within seconds, the attacker is signed in as them — and the user got their dashboard, so they have no reason to suspect anything.
You don't "phish a password" anymore. You phish the entire session, MFA included.
Why classic MFA falls
Every form of MFA in common use today shares the same property: the user can be tricked into completing it on behalf of an attacker. Here's what each one looks like against a modern AitM kit:
| Factor | What the user sees | What the kit does |
|---|---|---|
| SMS code | Receives 6-digit text, types it in | Reads it from the proxied request, replays it |
| TOTP app | Opens authenticator, types code | Same — code is just another field on the proxied form |
| Push prompt | Taps "Approve" on phone | User approved the attacker's session, not their own |
| Email magic link | Clicks link in inbox | Link delivers session token straight to AitM endpoint |
Push fatigue is the worst variant of this — users get spammed with prompts at 2am and tap "Approve" to make the buzzing stop. Uber and Cisco both lost accounts to this exact pattern.
What actually blocks AitM
The thing the user types in a phishing flow has to be impossible for an attacker to replay. That rules out anything shared as a secret, and rules in cryptographic proofs that are bound to the domain.
The reason WebAuthn works is mundane and important: the browser tells the authenticator which origin the user is signing in to. The authenticator signs only for that origin. A phishing site at microsoft-login.com gets a signature for microsoft-login.com, which the real Microsoft endpoint will reject.
Same idea applies to passkeys, hardware tokens, and any device-bound credential model. They're not magic — they just refuse to hand a usable token to the wrong site.
The enrollment gap
If FIDO2 fixes the login flow, why are companies still getting popped? Two reasons. First, most rollouts let users fall back to SMS or TOTP "just in case" — and attackers always target the weakest factor on offer. Second, even with a clean FIDO2 deployment, the enrollment moment is still a phishing target.
The classic flow: HR sends a "Welcome, please enroll your authenticator" email. An attacker who knows the new hire's name and start date sends a near-identical email an hour earlier. The new joiner enrolls the attacker's device as their own factor. The auth flow that follows is technically phishing-resistant — for the wrong person.
Phishing-resistant MFA only matters if the right person enrolled in the first place.
The same problem shows up on account recovery: "I lost my phone, please reset my factor." Most help desks fall back to a process a determined social engineer can clear in fifteen minutes.
PeerProofing: verifying it's really them
The fix to the enrollment gap is structural. Before a new credential gets bound to a person, a human who already trusts them — a manager, an admin, an existing teammate — has to confirm on a live video call that the person requesting enrollment is who they say they are.
That's what we ship as PeerProofing, and it's the missing half of phishing-resistant identity. The cryptographic factor takes care of every subsequent login. PeerProofing takes care of the one moment that cryptography can't help you with: deciding who the credential belongs to.
What teams measure after switching
Across the deployments we've sat through, the metrics that move are roughly the same. We've pulled three representative numbers from teams of different sizes:
| Metric | Before (legacy MFA) | After (Lucid + PeerProofing) |
|---|---|---|
| Successful account takeovers / qtr | 1.8 avg | 0 |
| Help-desk MFA tickets / month | 180 | ~12 |
| Time to onboard a new hire's auth | 1–3 days | ~5 minutes |
| User-reported friction (1-5) | 3.4 | 1.6 |
The help-desk number is the one nobody puts on the marketing page but everyone feels in the budget. Removing password resets, factor reissues, and recovery flows pulls back roughly 20-30% of an IT contact volume.
Conclusion
"We have MFA" stopped being a meaningful statement around 2023. The question now is which factor, with what fallbacks, and how the user got enrolled in the first place. Get all three right and account takeovers stop. Get any one of them wrong — usually enrollment — and the cryptography on the login side is decorative.
If you've already rolled out passkeys or FIDO2, the next conversation worth having is the enrollment one. Where do new credentials come from, and who said it was okay? If you can answer that with a name and a timestamp, you're in the small group of companies attackers will skip past.