Figure's filtration shows that traditional MFA is no longer enough

In February 2026, the alarm jumped: a leak linked to Figure - a financial sector entity - revealed almost a million e-mail addresses. That count, it impresses by its magnitude, but to understand it only as a figure is to stay on the surface. A collection of exposed emails is not the end of the incident, it is the initial inventory that attackers transform into access vectors.

When a massive set of directions enters hostile hands, these addresses immediately feed automated processes. First, they are combined with previous casualty databases to launch credental stuffing campaigns: pairs of mail and reused passwords are tested on a scale against corporate portals, VPN passageways and mass-use identity providers. Reports and safety guides on credental stuffing and its impact show that, with recent and well-segmented lists, success rates can produce thousands of valid combinations within hours; the industry documents it and explains it in detail in resources such as Imperva.

In parallel, the same list allows targeted and highly personalized phishing campaigns. Artificial intelligence accelerates the generation of emails with credible lures: messages that look like internal communications, that mention project or department names, and that replicate the aesthetics of legitimate services. With a mail address and public data such as professional network charges or profiles, an attacker can produce a very convincing shipment in minutes. For those who want to deepen how tools and operating kits facilitate these operations, technical repositories and analysis on real-time phishing proxies are a reference, for example in open source projects Evilginx2 and Modlishka.

Third, post exposure feeds social engineering attempts aimed at support service: calls or interactions where the attacker, with basic data from OSINT, pretends to be an employee to request password rebeginnings, MFA resets or account unlocks. This technique directly attacks the human process that exists to correct authentication failures, and does not need technical vulnerabilities in systems.

In all these flows, you don't have to imagine a sophisticated "explosion"; the purpose of the attacker is not to exploit a hole in the software, but rather log in as a legitimate user. And there is the nuance that is often lost in the news: the real risk is the chain of attack following the leak, and the critical question is whether an organization's authentication controls can interrupt that chain at some point.

Unfortunately, the answer is often negative. Much of the industry has relied on MFA forms - push notifications, SMS codes, TOTP - that protect the transmission of a code or the possession of a device, but place a person as the last decision link. This human dependence is precisely what attacks real-time relaxation methods (also called AiTM, adversary-in-the-middle). In such an attack, a malicious proxy retransmits the actions between the victim and the legitimate service: the credentials are ingested on a cloned page, the proxy sends them to the real site, the service generates an MFA challenge, and the victim, who believes he is interacting with the legitimate site, completes the second factor. The attacker thus receives an authenticated session despite not having "exploited" the service software.

It is important to understand why the most common forms of MFA do not stop that attack. Mechanisms that verify a code or confirm a notification do not distinguish whether the exchange occurred directly between user and service, or through an intermediary that retransmits the transaction in real time. In addition, there is the phenomenon known as "MFA fatigue": repeated applications for approval can lead tired or confused users to accept suspicious notifications. Microsoft and other security teams have documented and warned about these patterns and their exploitation by criminal actors; for those who want to review institutional analysis of these tactics, large supplier security blogs and incident response centers are useful sources, such as Microsoft Security and reports of independent broadcasters such as KrebsOnSecurity.

The industry's usual approach - training users to detect phishing and reminders about not accepting unexpected applications - is not wrong, but it is short. The inadequacy is of architecture, not just of behavior. A relay attack does not depend on the user's ability to recognize a cloned page: the MFA notification it receives is legitimate, issued by the service, within the usual application. There are no obvious leads for the human to detect the maneuver.

If the question that auditors, regulators and insurers must answer today is "can you prove that the authorized person was physically present and was biometrically verified at the time of authentication?" many traditional implementations remain unanswered. The standards and guidelines on identity already differ between proof of the presence of a device and verification of the individual; the first case does not guarantee that the person has operated the access. The NIST document on digital authentication patterns and the recommendations of the FIDO Alliance explain the limitations and directions to phishing-resistant authentication mechanisms; see, for example, the NIST guide in SP 800-63B and materials of the FIDO Alliance.

What properties should an authentication have to really close the door to these attacks? They can be summarized in three technical requirements that must coexist: first, a cryptographic link to origin that makes it impossible for a false site to sign a transaction intended for another domain; second, private keys tied to hardware sure they never leave that enclave, so that they cannot be copied or retransmitted; and third, a real-time biometric verification that confirms the presence of the authorized individual in the act of authentication. Combined, these guarantees prevent a proxy from producing valid signatures from a different origin, from reproducing a session with exfiltered cryptographic material, or from completing the process by an attacker without the physical presence of the holder.

FIDO2 / WebAuthn provides an important advance in terms of origin binding and use of hardware keys, and is therefore often cited in these discussions. However, standard implementations may be short if they rely on the cloud synchronization of credentials or on recovery flows that inherit other vulnerabilities. This is why experts demand not only keys linked to the device, but also the incorporation of "live" biometric authentication and proximity controls and hardware that close unsafe recovery routes. The WebAuthn specification of the W3C and the FIDO documentation provide the technical framework for understanding these differences: W3C WebAuthn and the explanatory resources of FIDO Alliance.

The market already has products that claim this comprehensive approach: hardware with non-exportable keys, mandatory local biometry and proximity verification. These devices try to eliminate "human judgment" as the final point of decision: if there is no biometric coincidence at the time and place of authentication, nothing is signed and no access is granted. It is an architectural response to the fragility that has been exploited by the relay campaigns and the MFA campaigns. As in any security measure, these solutions should be assessed for their integration capacity, their impact on privacy and their recovery procedures in the face of device loss; they are a piece of mitigation, but they guide the architecture towards an identity model focused on individual verification and not just the token.

The key lesson that leaves the Figure filtration - and the next one that will inevitably come - is that organizations must evaluate their authentication from the point of view of the attacker who already has initial data: does the authentication model they use require the user, under pressure and sometimes without warning signals, to make the right decision, or does it technically prevent an alien entity from gaining access without the presence and verification of the holder?

If the current response is the first, the base should be redesigned. The real protection against attacks following a mass leak is to change the authentication architecture, not just to better train people.. NIST guides and FIDO initiatives are starting points for understanding the technical path; the analysis of credental stuffing, AiTM and MFA fatigue show why change is urgent. Consult technical sources and documented cases helps to make informed decisions: review the materials of the NIST SP 800-63B resources of the United Nations FIDO Alliance, research and analysis articles in KrebsOnSecurity or reports from suppliers such as Imperva and consider concept tests that incorporate safe hardware and live biometry for high-risk accesses.

The mail leak is just the first step in a chain. Effective defence requires thinking beyond the number of exposed records and building controls that make it impossible for such records to become valid accesses.