MFA used to be the control that let MSPs and security pros sleep at night. In 2026, industrial‑grade phishing kits and AI email engines have turned “we turned on MFA” into the new “we installed antivirus” — expected, but nowhere near enough.

When MFA stops saving you

Picture the pattern you’ve seen in too many incident reviews this year. A finance manager gets what looks like a routine single sign‑on prompt: same branding, same URL pattern, same Okta‑style flow. They enter their username and password, get an MFA challenge on their phone, approve it, and go back to their day. Thirty minutes later, an attacker is in their mailbox, their SaaS tools, and your financial systems — because the entire exchange was proxied through a phishing kit that relayed credentials and one‑time codes to the real application in real time.

That’s the core innovation behind the current wave of phishing‑as‑a‑service: it doesn’t just steal a password or guess a weak factor, it steals the whole login ceremony as it happens. Session cookies, tokens, and OTPs get harvested in the same breath. The end result is nasty and simple: users who “did everything right” are still the entry point.

Meet the new villains: AI phishing and MFA bypass kits

Over the last year, a cluster of commercially packaged kits has emerged that bake real‑time MFA bypass into their feature lists with names like BlackForce, GhostFrame, InboxPrime AI, and Spiderman:

• They proxy the entire login flow. Instead of serving a static clone of your login page, the kit sits between victim and real site. The victim types into the fake page; the kit pipes everything through to the legitimate service.

• They handle MFA as first‑class input. When your identity provider prompts for an OTP or push approval, the kit asks the victim for that code in the same UI. As soon as the victim enters it, the kit replays it to the real service and captures the resulting authenticated session.

• They industrialize realism and evasion. Templates for major banks, Microsoft 365, Google Workspace, and popular SaaS platforms come pre‑loaded. Invisible iframes and obfuscated JavaScript make it easy to swap targets or update pages without changing the parent site. DNS and TLS automation spins up “legit‑looking” infrastructure quickly.

• They outsource the social engineering. InboxPrime‑style tools use generative text models to draft, localize, and A/B‑test lures; built‑in spam‑diagnostics modules help operators tweak subject lines and headers until they bypass mail filters.

The punchline: you no longer need to be a skilled social engineer or web developer to run campaigns that bypass SMS codes, app OTPs, and push‑based prompts. You just need a subscription to one of these kits and a list of emails.

Why legacy MFA is crumbling

On paper, nothing has changed: you still have a second factor, attackers still need it, and you’re still “stronger than passwords alone.” In practice, traditional MFA has three structural weaknesses these kits exploit.

1. It’s phishable.
   SMS codes, TOTP codes, and simple push approvals are all designed to be typed or tapped by humans on demand. If a human can read and type it, an attacker can trick them into reading and typing it in the wrong place. The kits simply make that trick reliable and scalable.

2. It’s front‑loaded.
   Most deployments treat authentication as an event at the front door: we challenge, user passes, we hand out a long‑lived cookie or token, and then we assume it’s fine. Once an attacker has that token — by replaying the MFA or stealing the session — they often enjoy the same privileges as the legitimate user until the token expires or is revoked.

3. It’s one‑size‑fits‑all.
   “MFA on everything” looks good on a slide, but not all sessions or actions carry the same risk. Static rules that apply the same challenge to low‑risk and high‑risk events train users into blind approval, and do little to stand out when something genuinely odd is happening, like a login from a new country on a suspicious device at 3 a.m.

These weaknesses don’t mean MFA is useless. They mean phishable MFA is a speed bump, not a wall, when your adversary has tooling that automates the hard parts.

The new baseline: beyond “we have MFA”

Security leaders need a new way of thinking about authentication — one that focuses less on checkboxes and more on phishing resistance and adaptivity. Three pillars are emerging as the 2026 baseline.

1. Passkeys and passwordless FIDO2

Passkeys (built on FIDO2/WebAuthn) replace shared secrets with asymmetric keys. Instead of a user typing a password and a code into a web form, they:

• Register a device‑bound credential (a key pair) with your service.

• Prove possession of the private key locally via biometrics or a PIN when they sign in.

• Let the browser and authenticator handle the cryptographic dance with your server.

Because the private key never leaves the user’s device and is bound to your domain, the classic phishing kit workflow breaks down. A fake site can’t complete the challenge because it doesn’t control the user’s authenticating device for your real domain. There’s nothing to relay.

At the same time, passkeys remove an entire class of user pain: no passwords to remember, fewer MFA prompts, and simpler recovery flows when implemented well.

2. Adaptive, risk‑based authentication

Instead of treating every login the same, adaptive auth engines continuously score risk and adjust challenges. Signals can include:

• Device fingerprints and OS posture.

• Network and geo context (usual IP ranges, impossible travel).

• User behavior (time of day, typical applications accessed).

• Transaction context (the size and sensitivity of what the user is doing).

Low‑risk events from familiar environments might pass with a seamless passkey or SSO assertion. Suspicious ones — say, a financial transaction from a new device in a new country — trigger step‑up challenges, additional verification, or outright blocking. The goal is to reserve friction for moments that genuinely warrant it.

3. Behavioral biometrics and continuous authentication

Traditional MFA checks identity at a point in time. Behavioral biometrics and continuous authentication treat it as an ongoing question. Systems quietly monitor patterns such as:

• Typing cadence and mouse movements on a desktop.

• Touch gestures, device orientation, and micro‑movements on mobile.

• Typical navigation paths and interaction styles within your app.

When these patterns deviate sharply from the user’s baseline — especially in combination with other risk signals — the system can flag the session, step up verification, or terminate access. This makes it significantly harder for an attacker who has stolen a session token to “blend in” for long.

Combined, these three shifts turn authentication from “a front door with a second lock” into a layered, context‑aware control that’s much harder to script around.

A 12–18 month roadmap to phishing‑resistant auth

Knowing you should move beyond “good enough” authentication is one thing. Doing it under budget, with minimal user revolt, is another. Here’s a pragmatic roadmap you can actually take to your steering committee.

Phase 1 (0–3 months): Assess and triage

Goals: Understand where you are; decide where to move first.

• Inventory MFA as‑is.
  Build a map of which factors are used where: SMS/voice OTP, TOTP apps, push prompts, security keys, passkeys. Include both workforce and customer‑facing flows.

• Identify tier‑1 targets.
  Prioritize systems where a compromise would be catastrophic: admin consoles, identity providers, privileged access tools, core financial systems, health or PII‑heavy apps, VPN/remote access.

• Form an authentication working group.
  Pull in IAM, security architecture, product management, customer experience, and legal/privacy. You’ll need all of them to avoid building a beautiful system nobody will use.

Deliverable: a heatmap that shows your most phishable, highest‑impact authentication points.

Phase 2 (3–9 months): Go phishing‑resistant where it matters most

Goals: Prove the model on critical accounts; iron out UX and support issues.

• Roll out passkeys or security keys for admins and IT.
  Start with the people whose compromise would be hardest to recover from: cloud admins, IdP admins, domain admins, finance and payroll, HR admins. Make phishing‑resistant factors mandatory for them.

• Introduce adaptive auth for workforce SSO.
  Configure your identity platform to score login risk and require step‑up challenges for high‑risk events. Begin with conservative rules and tune them over time.

• Harden remaining phishable flows.
  Where you can’t yet move to passkeys, improve what you have: remove SMS where possible, require app‑based OTP or push with number‑matching, lock down push fatigue (limited retries, alerts on excess prompts).

Deliverable: a clear, measurable reduction in the number of high‑value accounts that rely on phishable factors — and early lessons about user friction and support.

Phase 3 (9–18 months): Scale and normalize

Goals: Make phishing‑resistant auth the norm, not the exception.

• Expand passkeys/passwordless to broader populations.
  Offer passkeys as the default for employees and contractors, with an opt‑out path that requires justification. Where feasible, build passkey support into customer‑facing apps, starting with segments most at risk of account takeover.

• Introduce continuous and behavioral checks on key apps.
  Integrate behavioral biometrics on web and mobile for high‑risk applications. Start with passive monitoring to build baselines, then gradually enable intervention.

• Relegate SMS and email codes to break‑glass only.
  Make it explicit in policy and configuration that these factors are last resort for recovery—not everyday authentication. Surround remaining usage with alerts, rate‑limits, and extra scrutiny.

• Bake requirements into contracts.
  Update vendor and SaaS contracts to require support for passkeys/WebAuthn and to document what authentication methods are used for admins and support staff who can touch your data.

Deliverable: by the end of this phase, you should be able to say, with evidence, that the majority of your high‑value access paths are protected by non‑phishable, adaptive authentication.

Talking to the board: from feature to control

None of this happens without executive support. The framing matters.

Instead of, “We’re upgrading MFA,” try: “Attacker tooling has caught up with our current authentication. Kits now automate what only skilled human phishers could do a few years ago. Our goal over the next 18 months is to restore authentication as a control attackers can’t easily script around.”

Back this up with three simple metrics:

• Coverage: Percentage of critical applications that support phishing‑resistant authentication.

• Adoption: Percentage of privileged and then general users enrolled in passkeys or equivalent.

• Outcome: Change in phishing‑driven account‑takeover incidents or near‑misses.

What you’re really telling them is this: enabling MFA was the right move for its time. But that time is over. Attackers have automated away the margin of safety “good enough” authentication once gave you. Your job now is to move your organization — deliberately, measurably — into a world where stealing a password and an OTP is no longer enough to walk through your front door.

Additional Sources:

Passkey Authentication in Payment Systems: A Practical Guide for 2026

Protecting your users from the 2026 wave of AI phishing kits