Phishing-proof MFA stops TfL helpdesk 2FA resets

Transport for London’s 2024 Scattered Spider intrusion combined marketplace-sourced partial employee credentials with social engineering that produced a two-factor authentication reset, then privilege escalation inside workforce systems. Phishing-proof device-bound MFA 2.0 closes that path by removing transferable recovery factors and requiring an already-enrolled device before any new authenticator is trusted. Privilege use after a trusted identity already exists is residual post-auth work; closing the phishable login and recovery path is the prevention claim.

For the full attack chain, figures, and sentencing record, read the companion on legacymfa.sucks.

FAQ

Would phishing-proof MFA have stopped the TfL helpdesk 2FA reset path?

Yes for the credential and recovery phases that opened Transport for London to Scattered Spider. Marketplace partial passwords are weaker when workforce login no longer depends on replayable shared secrets, and phishing-proof enrolment blocks a coached helpdesk or recovery reset from installing attacker-controlled factors without an already-enrolled device. According to the National Crime Agency, social engineering produced a 2FA reset after multiple attempts, then privilege escalation followed. Public reporting does not name a Temporary Access Pass, a spoofed login page, or an adversary-in-the-middle kit for TfL. The prevention win is still clear: no TAP, OTP, SMS code, push, or recovery secret exists for IT to read out or for a coached caller to type.

How do passkeys alone differ from MFA 2.0 on a TfL-style recovery abuse?

Passkeys are phishing-resistant at the login ceremony; they do not automatically lock enrolment and helpdesk recovery. If email OTP, SMS, push, or a human-verified reset can still onboard a new authenticator, an attacker who wins that recovery conversation enrolls hardware that later signs as the employee. MFA 2.0 is phishing-proof across registration, device onboarding, authorisation, authentication, and decommissioning, so the same vishing class that hit TfL has no transferable factor to harvest. That ladder matters here: password and OTP sit below phishing-resistant login, and full-lifecycle phishing-proof coverage is what closes the recovery gap passkeys leave open when enrolment stays phishable.

Once attackers held a reset TfL identity, what could MFA still stop?

Nothing useful in the later phases of the Transport for London intrusion. After the 2FA reset stuck, privilege escalation and access to operational and customer-refund related systems were post-authentication work against an identity the environment already trusted. No MFA revokes a session the IdP has accepted, and no login control undoes lateral movement or data access after that point. Closing the phishable login and recovery path stops this path. Malware or operator abuse after a legitimate login is a harder, separate problem, and revoke remains hygiene rather than the primary fix.

What should CISOs change about workforce recovery after TfL?

Treat helpdesk recovery as the same social-engineering class as coached fake login: a live human is talked into handing over a transferable factor. Require proof from an already-enrolled device before any factor replacement, ban read-out codes and temporary secrets at the service desk, and prefer prevention, not detection so the reset call never succeeds. Marketplace credential exposure still matters as a starting wedge, but it should not justify a full 2FA re-issue on voice trust alone. Public reporting does not establish TfL’s exact helpdesk scripts or reset mechanics, so design to the architecture, not to one ticket transcript.

Why did TfL still need mass in-person password resets if the fix is upstream?

According to the National Crime Agency, every one of TfL’s roughly 27,000 employees had to attend a TfL office for a password reset after 148 systems became inoperable and customer-refund paths were hit, with about £29 million in loss and recovery costs. That response is containment after a trusted workforce identity was already inside. Upstream phishing-proof recovery would have aimed to keep the reset from landing; it does not replace incident cleanup, short-lived session hygiene, or endpoint controls once operators are already operating as the employee.