The Figure Breach: More Than a Headcount
In February 2026, TechRepublic reported that Figure, a financial services company, had exposed nearly 967,200 email records in a newly disclosed data breach. No vulnerability was chained. No zero-day was burned. The records were simply accessible — and now they are in adversary hands.
Most breach coverage stops at the record count. That is exactly the wrong place to stop. The number of exposed records is not the event itself — it is the starting inventory for everything that follows. To understand the real risk, you have to trace 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. For most organizations, the answer is no.
What Adversaries Do With 967,000 Exposed Email Addresses
Exposed email addresses are not static data. They are operational inputs. Within hours of a record set like this surfacing, adversaries are running it through several parallel workflows simultaneously.
Credential Stuffing at Scale
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 credential 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 translates to somewhere between 19,000 and 29,000 valid credential pairs.
AI-Assisted 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 — leveraging job titles, departments, or public LinkedIn data to tailor the lure — is standard practice, not a capability reserved for nation-state actors.
Help Desk Social Engineering
Armed with a valid email address and basic open-source intelligence, adversaries impersonate employees in calls to IT support teams, requesting password resets, MFA device resets, or account unlocks. This vector bypasses authentication technology entirely — it targets the human process that exists to handle authentication failures. No technical exploit required.
In each of these workflows, the adversary's goal is not to break in. It is to log in as a valid user. The breach does not create access directly. It creates the conditions under which access becomes achievable through the authentication system itself.
Why Legacy MFA Cannot Interrupt This Attack Chain
Organizations often read about a credential exposure and reassure themselves that their MFA deployment provides adequate protection. For the attack chain described above, that conclusion is structurally incorrect.
Real-Time Phishing Relay and Adversary-in-the-Middle Attacks
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 genuine. The proxy forwards the response, and the adversary receives a fully 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. This capability is the baseline, not an exotic technique.
MFA Fatigue
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 tactic has been used successfully against organizations with mature security programs, including in incidents that received significant public coverage.
The common thread across all 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 them.
The Architectural Problem That User Education Cannot Fix
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.
The deeper problem is that most deployed authentication architectures were 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 is cited frequently in this conversation, and it represents 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, and recovery flow exploitation. Device-bound passkeys prove device possession. They do not prove human presence.
Phishing-resistant authentication that genuinely 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 confirming the authorized person is physically present at the moment of authentication.
When all three properties are present simultaneously, 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 at all.
Token's Approach: Verifying the Human, Not the Device
TokenCore was built on a single principle: verify the human, not the device, credential, or session. Most authentication products add factors to a weak foundation. Token replaces the foundation itself.
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.
Token's Biometric Assured Identity platform eliminates each link in the attack chain described above:
- 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 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 form factor is also notable. Token is wireless — using Bluetooth proximity — with 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 shadow IT and workaround behavior commonly associated with legacy hardware tokens.
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 Honest Assessment
The Figure breach will produce downstream authentication attacks. So will the next breach, and the one after that. The adversary infrastructure running 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 never the last line of defense. Legacy MFA requires the former. Phishing-resistant, biometrically assured authentication delivers the latter.
The architectural problem exposed by the Figure breach is not new. The attack chain is well-documented, the toolkits are publicly available, and the failure mode of push-based MFA is understood. What remains is a decision about whether the controls in your environment are matched to the threat that actually exists — not the threat that existed when your current MFA stack was deployed.
Source: BleepingComputer