Your MFA Adoption Rate Is a Broken Metric
TL;DR
Infostealers and phishing-as-a-service platforms now bypass SMS, TOTP, and push MFA by harvesting session tokens after authentication succeeds. FIDO2 and passkeys are the only methods that hold because the credential is cryptographically bound to the origin and cannot be relayed. Enterprises still measuring identity maturity by MFA adoption rates are tracking a metric that no longer reflects actual security posture, and that is a governance failure, not a tooling gap.
Your board deck probably has a slide showing MFA coverage across the organization. Ninety-two percent. Ninety-six. Maybe a hundred, if you pushed hard enough. The number looks like progress. It is not.
The problem with measuring MFA adoption is that not all MFA is the same. SMS codes, TOTP apps, and push notifications are being bypassed routinely by the pipelines that supply today’s ransomware operations. The Verizon 2025 DBIR traced 54% of ransomware attacks to infostealer-enabled credential theft. The organizations in that dataset had MFA. They probably had good adoption rates too.
Phishing-resistant MFA, specifically FIDO2 and passkeys, is the only category of authentication that structurally addresses the way modern attacks work. The reason enterprises are not moving to it faster is not a tooling problem. It is a governance and decision problem. The people who could force the migration are still looking at a dashboard showing 96% MFA coverage and concluding that identity is under control.
The Attack Has Changed. The Metric Has Not.
There are four ways attackers defeat traditional MFA, and your security team has almost certainly briefed all of them at some point. SIM swapping transfers a victim’s phone number to an attacker-controlled device, turning SMS codes into an attacker resource. MFA fatigue floods a target with push notification approval requests until they approve one out of annoyance or confusion. Adversary-in-the-middle proxies, the backbone of phishing-as-a-service platforms like RaccoonO365, sit between the victim and the real service, relaying credentials and live MFA codes in real time before they expire.
The fourth vector is the one that matters most and gets the least attention: session token theft. This is where the attack has fundamentally shifted.
Here is what actually happens. A user authenticates successfully. The MFA challenge fires. They approve it. The identity platform issues a session token, and the browser stores it as a cookie. An infostealer deployed on that endpoint silently exfiltrates that token. The attacker replays it directly, skipping the authentication layer entirely because the session is already authenticated. There is no MFA prompt to bypass. The MFA system did exactly what it was supposed to do. It just stopped being relevant to the attack.
LummaC2, one of the most widely deployed infostealers until Cloudforce One coordinated its disruption in May 2025, was built around this mechanism. Session token and cookie exfiltration was its primary payload, not passwords. RaccoonO365 ran as a subscription service on Telegram, $355 for thirty days, and explicitly advertised MFA bypass via adversary-in-the-middle token harvesting as a product feature. HellCat ransomware breached Jaguar Land Rover and Telefonica using Jira credentials and session tokens sourced from infostealer logs. These are not sophisticated state actors. They are commoditized operations available to anyone willing to pay a monthly subscription fee.
FIDO2 and passkeys are the only methods that close this. The authentication credential is cryptographically bound to the legitimate origin domain at the time of registration. A proxy cannot produce a valid signature for a different origin. An infostealer can steal the session token after authentication, which is why continuous session monitoring and short session lifetimes still matter even after FIDO2 deployment. But the credential itself cannot be exfiltrated and replayed. That is a categorically different security guarantee, not an incremental improvement over TOTP.
“MFA Is Deployed” Is No Longer an Adequate Status Report
When a CISO reports MFA coverage to the board, the implicit claim is that the identity plane is meaningfully protected. That claim was defensible five years ago. It is not defensible now, because the phrase “MFA is deployed” tells you nothing about whether that MFA would withstand an attack against a high-value account in your organization today.
This is a governance failure, and it runs in a specific direction. The decision to deploy push-based MFA was made at a particular moment in time, against a particular threat landscape, with a particular cost and friction calculus. That decision was reasonable when it was made. Nobody built a process to revisit it as the threat landscape changed. So the decision persists, not because anyone evaluated it against the 2025 infostealer pipeline and concluded it was still adequate, but because nobody was assigned to make the decision again.
The identity security posture question is not “do your users have MFA?” It is “does your MFA create a control that would actually stop the attacks breaching your peers right now?” Those are different questions. Most governance structures only ask the first one.
Organizations that have already invested in Entra ID Conditional Access, licensed Authenticator app push, and hit high adoption numbers have a particularly hard time making this argument internally. The metric looks good. The compliance boxes are checked. Proposing a migration to FIDO2 requires making the case that a control that appears to be working is actually inadequate against the threat that matters. That is a harder conversation to start than “we need MFA,” and it requires a different kind of ownership to drive.
What FIDO2 Actually Does (and What It Does Not Fix)
FIDO2 and passkeys bind authentication to the device and the origin. When a user registers a passkey with a service, the authenticator generates a key pair tied to that relying party’s domain. Every subsequent authentication uses that key pair, and the signature is verified against the registered public key. A phishing page at a lookalike domain cannot produce a valid signature. A man-in-the-middle proxy cannot relay it. An infostealer can steal the session cookie issued after authentication, which is why continuous session monitoring and short session lifetimes still matter even after FIDO2 deployment. But the credential itself cannot be exfiltrated and replayed.
For enterprise environments, FIDO2 deployment means hardware security keys (YubiKey and equivalents) or platform passkeys using Windows Hello or device biometrics. Entra ID and Google Workspace both support FIDO2 authentication. Most modern SaaS applications support it through SAML or OIDC federation with your identity provider, which means you do not need FIDO2 to touch every application directly.
The constraint is legacy applications. If you have on-premises apps that authenticate through NTLM, Kerberos, or form-based login with no MFA layer, FIDO2 does not help there. That is a real sequencing problem, not a reason to delay starting. Your highest-value targets, admin accounts, email, remote access gateways, your identity provider itself, almost certainly support FIDO2 today. Start there. The legacy tail is a phased migration problem, not a blocker.
One thing that does not get said clearly enough: maintaining SMS or push as a fallback for FIDO2 users defeats the purpose. If an attacker can trigger a fallback to push notification by claiming the hardware key is unavailable, the protection you gained from FIDO2 disappears. Phishing-resistant authentication requires removing the non-resistant fallbacks for accounts where you have deployed it.
How to Move From “We Have MFA” to “We Have Phishing-Resistant MFA”
Start with your most privileged accounts, not your full user population. Global admins, privileged identity management roles, and accounts with production access to critical systems are the highest-value targets in an infostealer attack. Moving these accounts to FIDO2 first delivers the most risk reduction per unit of deployment effort. Push the rest of the organization through your normal change cycle.
Inventory which Conditional Access policies actually enforce authentication strength. In most Entra ID environments, a CA policy that requires MFA does not specify which MFA. It accepts any registered method, including SMS. Add an Authentication Strengths requirement to your highest-privilege and highest-risk policies that explicitly requires phishing-resistant methods and excludes TOTP and push notification. This is the control that makes the FIDO2 rollout enforceable rather than advisory.
Address fallback authentication before you announce the migration. Decide which accounts will have push or SMS fallback disabled entirely once FIDO2 is registered, and communicate that clearly. Removing the fallback is what makes the control meaningful. If you leave it in place, you have deployed a stronger lock next to an open window.
Define session lifetime policies that complement FIDO2. FIDO2 removes the relay attack surface at authentication time. Continuous access evaluation and short-lived session tokens reduce the window available to an attacker who successfully steals a post-authentication cookie. The two controls address different parts of the attack chain and should be deployed together.
Assign a named owner to the authentication policy decision, not just the deployment project. The reason enterprises are still running push MFA in 2026 is not that nobody tried to deploy FIDO2. It is that nobody was accountable for revisiting the authentication method decision as the threat landscape changed. That accountability gap is what needs to close.
The Question Behind the Metric
Cloudflare processes roughly 20% of global web traffic, and their 2026 threat report frames the infostealer-to-ransomware pipeline in detail. The data is credible even where the product recommendations are self-serving. When that data says the pipeline that funded 54% of ransomware attacks last year runs straight through session token theft, the governance implication is direct: the organizations using MFA coverage as their primary identity assurance metric are measuring the wrong thing.
The meaningful question is not whether your users have MFA enabled. It is whether the authentication methods you have deployed would have stopped the credential attacks that breached organizations in your industry last year. If the answer is uncertain, or if nobody in your governance structure has asked the question at all, the gap is not in your identity tooling. It is in who owns the decision to revisit a control once deployed, on what cadence, and against what threat criteria.
Identity security posture is not a deployment project with an end state. It is a governance function. The organizations learning this the hard way in 2026 all had MFA. They just had the wrong kind, and nobody was responsible for knowing the difference had started to matter.
