When attackers already have the keys, MFA is just another door to open

The Figure breach exposed 967,200 email records without a single exploit. Understanding what that enables — and why your MFA cannot contain it — is an architectural problem, not a user education problem.

In February 2026, TechRepublic reported that Figure, a financial services company, exposed nearly 967,200 email records in a newly disclosed data breach. No vulnerability was chained. No zero-day was burned. The records were accessible, and now they are in adversary hands.

Coverage of breaches like this tends to stop at the count. That is the wrong place to stop. The number of exposed records is not the event — it is the starting inventory for the event that follows.

To understand the actual risk, you have to follow the attack chain that a credential exposure like this enables, step by step, and ask honestly whether the authentication controls in your environment can interrupt it at any point.

Most cannot. Here is why.

What Adversaries Do With 967,000 Email Records

Exposed email addresses are not static data. They are operational inputs. Within hours of a record set like this becoming available, adversaries are running it through several parallel workflows simultaneously.

The first is credential stuffing. Figure customers and employees almost certainly reused passwords across services. Adversaries combine the exposed addresses with breach databases from prior incidents — LinkedIn, Dropbox, RockYou2024 — and test the resulting pairs against enterprise portals, VPN gateways, Microsoft 365, Okta, and identity providers at scale. Automation handles the volume.

Success rates on credential stuffing campaigns against fresh email lists routinely run at two to three percent. On 967,000 records, that is 19,000 to 29,000 valid credential pairs.

The second workflow is targeted phishing. AI-assisted tooling can now generate personalized phishing campaigns from an email list in minutes. The messages reference the organization by name, impersonate internal communications, and are visually indistinguishable from legitimate correspondence.

Recipient-specific targeting — using job title, department, or public LinkedIn data to tailor the lure — is standard practice, not a capability reserved for nation-state actors.

The third is help desk social engineering. Armed with a valid email address and basic OSINT, adversaries impersonate employees in calls to IT support teams, requesting password resets, MFA device resets, or account unlocks.

This attack vector bypasses authentication technology entirely — it targets the human process that exists to handle authentication failures.

In each of these workflows, no technical vulnerability is required. The adversary’s goal is not to break in. It is to log in as a valid user. The breach does not create access. It creates the conditions under which access becomes achievable through the authentication system itself.

Why Legacy MFA Cannot Interrupt This Chain

This is the part of the analysis that most incident post-mortems underweight. Organizations read about a credential exposure and conclude that their MFA deployment protects them. For the attack chain described above, that conclusion is structurally incorrect.

Modern adversary tooling executes what security researchers call a real-time phishing relay, sometimes referred to as an adversary-in-the-middle (AiTM) attack. The mechanics are precise.

An adversary builds a reverse proxy that sits between the victim and the legitimate service. When the victim enters credentials on the spoofed page, the proxy forwards those credentials to the real site in real time.

The real site responds with an MFA challenge. The proxy forwards that challenge to the victim. The victim responds — because the page looks legitimate and the MFA prompt is real. The proxy forwards the response. The adversary receives an authenticated session.

Push notification MFA, SMS one-time codes, and TOTP authenticator apps are all vulnerable to this relay. They authenticate the exchange of a code. They do not verify that the individual completing the exchange is the authorized account holder. They cannot distinguish a direct session from a proxied one.

Toolkits that automate this attack — Evilginx, Modlishka, Muraena, and their derivatives — are publicly available, actively maintained, and require no advanced tradecraft to operate. The capability is not exotic. It is the baseline.

MFA fatigue compounds this. Adversaries who obtain valid credentials but cannot relay the session in real time will instead trigger repeated push notifications until a user approves one out of frustration or confusion. This attack has been used successfully against organizations with mature security programs, including in incidents that received significant public coverage.

The common thread across all of these techniques: legacy MFA places a human being at the final decision point of the authentication chain, then relies on that human to make the correct call under conditions specifically engineered to defeat it.

The Structural Problem Legacy MFA Cannot Solve

The security industry’s standard response to authentication failures is user education. Train people to recognize phishing. Teach them to verify unexpected MFA prompts. Remind them not to approve requests they did not initiate.

This response is not wrong. It is insufficient, and the insufficiency is architectural, not motivational.

A relay attack does not require a user to recognize a phishing page. The MFA prompt they receive is real, issued by the legitimate service, delivered through the same app they use every day. There is nothing anomalous for the user to detect. The attack is designed to be invisible to the human in the loop — and it is.

The deeper problem is that the authentication architecture most organizations have deployed was not designed to answer the question that actually matters in a post-breach environment: was the authorized individual physically present and biometrically verified at the moment of authentication?

Push notifications do not answer this question. SMS codes do not answer this question. TOTP does not answer this question. USB hardware tokens answer a related but different question — they prove the registered device was present, not the authorized person.

Auditors, regulators, and cyber insurers are increasingly drawing this distinction explicitly. The question “can you prove the authorized individual was there?” is appearing in CMMC assessments, NYDFS examinations, and underwriter questionnaires. Device presence is no longer accepted as a proxy for human presence in high-stakes access contexts.

What Phishing-Resistant Authentication Actually Requires

FIDO2/WebAuthn gets cited frequently in this conversation, and it is a meaningful step forward — but it is not sufficient on its own. Standard passkey implementations bind the credential to a device or cloud account.

Cloud-synced passkeys inherit the vulnerabilities of the cloud account: SIM swap attacks against the recovery phone number, account takeover via credential phishing, recovery flow exploitation. Device-bound passkeys prove device possession. They do not prove human presence.

Phishing-resistant authentication that closes the relay attack vector requires three properties simultaneously:

• Cryptographic origin binding: the authentication credential is mathematically tied to the exact origin domain. A spoofed site cannot produce a valid signature because the domain does not match. The attack fails before any credential is transmitted.
• Hardware-bound private keys that never leave secure hardware: the signing key cannot be exported, copied, or exfiltrated. Compromise of the endpoint does not compromise the credential.
• Live biometric verification of the authorized individual: not a stored biometric template that can be replayed, but a real-time match that confirms the authorized person is physically present at the moment of authentication.

When all three properties are present, a relay attack has no viable path. The adversary cannot produce a valid cryptographic signature from a spoofed site. They cannot relay a session because the cryptographic binding fails the moment the origin changes.

They cannot use a stolen device because the biometric verification fails without the authorized individual. They cannot social-engineer an approval because there is no approval prompt — the authentication either completes with a live biometric match at the registered hardware, or it does not complete.

Token: Cryptographic Identity That Verifies the Human, Not the Device

TokenCore was built on a single, uncompromising principle: verify the human, not the device, credential, or session.

Most authentication products add factors to a weak foundation. Token replaces the foundation. The platform combines enforced biometrics, hardware-bound cryptographic authentication, and physical proximity verification — three properties that must all be satisfied simultaneously for access to be granted.

There is no fallback. There is no bypass code a user can enter in the field. The authorized individual is either present and verified, or access does not occur.

This matters precisely because of the attack chain described above. Token’s Biometric Assured Identity platform eliminates each link:

• No Phishing. Every authentication is cryptographically bound to the exact origin domain. A spoofed login page produces no valid signature — Token simply refuses to authenticate.
• No Replay. The private signing key never leaves the hardware. A relayed session cannot be reconstructed because the cryptographic material it would need to replicate is physically inaccessible.
• No Delegation. A live fingerprint match is required for every authentication event. A colleague, an adversary with a stolen device, or a social engineering target cannot complete authentication on behalf of the authorized individual.
• No Exceptions. There is no code, no recovery flow, and no help-desk override that can substitute for biometric presence. The control is absolute because the risk is absolute.

The form factor matters too. Token is wireless — Bluetooth proximity, no USB port required. Authentication takes one to three seconds: the user initiates a session, taps their fingerprint on the Token device, Bluetooth proximity confirms physical presence within three feet, and access is granted.

For on-call administrators, trading floor operators, and defense contractors working across multiple workstations, this eliminates the friction that drives the shadow IT and workaround behavior legacy hardware tokens create.

Unlike USB-based alternatives, Token is field-upgradeable over the air. As adversaries evolve their tooling, Token’s cryptographic controls can be updated remotely and immediately — without replacing hardware or reissuing devices. The investment does not expire when the threat landscape changes.

Token verifies the human. Not the session. Not the device. Not the code. The human.

The Honest Assessment

The Figure breach will produce downstream authentication attacks. So will the next breach, and the one after that. The adversary infrastructure that runs credential stuffing, AI-generated phishing, and real-time relay attacks operates continuously against exposed email records.

The question is not whether these attacks will be attempted against your environment. They will be.

The relevant question is whether your authentication architecture requires human judgment to succeed — or whether it is designed so that human judgment is not the failure point.

Legacy MFA, in all of its common forms, requires human judgment. A user must recognize the anomaly, question the prompt, and make the correct decision under adversarial pressure. That is a brittle dependency at a critical control point, and adversaries have built an entire toolchain to exploit it.

Token removes that dependency. The device signs for the legitimate domain with a confirmed biometric match — or it does nothing. There is no prompt to manipulate. There is no decision to engineer. There are no exceptions.

That is not a feature. It is the architectural requirement for authentication that holds under the conditions this breach, and every breach like it, creates.

See How Token Closes the Gap

Token’s Biometric Assured Identity platform is built for organizations where authentication failure is not an acceptable outcome — defense contractors, financial institutions, critical infrastructure, and enterprise environments with high-privilege access requirements.

Cryptographic. Biometric. Wireless. No phishing. No replay. No delegation. No exceptions.

Learn more. Visit tokencore.com.

Sponsored and written by Token.