Marks & Spencer's 17 April 2025 network entry started when attackers used sophisticated impersonation to trick a third-party helpdesk into resetting an employee password. According to BleepingComputer, chairman Archie Norman said they appeared as somebody with their details, not a casual password-change request. Phishing-proof device-bound MFA 2.0 hardens workforce recovery so that path stops being a pure social-proof credential handoff. Ransomware and bulk theft after a live authenticated position are residual post-auth problems no login MFA undoes.
For the full attack-chain narrative, read the companion on legacymfa.sucks.
FAQ
Would MFA 2.0 have stopped the Marks & Spencer helpdesk password reset?
Yes for the credential-reset phase. Marks & Spencer's initial access on 17 April 2025 was helpdesk password-reset social engineering: attackers impersonated someone tied to the company and a third-party support path issued a live employee password. Legacy recovery accepted social proof and handed over a transferable factor. MFA 2.0 is phishing-proof across the identity lifecycle, including recovery and device onboarding, so a vished helpdesk cannot silently re-issue a password or equivalent factor to an impersonator. Closing that recovery path stops this entry method. Public reporting does not name OTP, TAP, push, or AiTM for this breach, so the prevention claim stays on hardened recovery, not on inventing unstated second factors.
Does phishing-proof MFA undo DragonForce-linked ransomware after the reset?
No. After the Marks & Spencer password reset succeeded, operators moved into post-authentication impact: numerous VMware ESXi servers encrypted and roughly 150GB of data believed stolen under DragonForce-linked activity, according to BleepingComputer. Once attackers already held an authenticated position from the reset password, no login-time MFA design undoes session use, ransomware deployment, or bulk data theft. Prevention value is upstream at recovery. Containment after that point is revoke, endpoint, and operational response work.
How is helpdesk recovery social engineering the same class as fake-login coaching?
Helpdesk recovery social engineering and coaching a user through a fake login are the same attack class for workforce identity. In both cases a human is live-coached into releasing a transferable factor: a reset password, a recovery secret, a code, or an approval. Marks & Spencer's documented path was the helpdesk side of that class. MFA 2.0 stops both because there is no TAP, OTP, SMS, email code, push, or recovery secret for IT to read out or for the user to type, and adding a device requires an already-enrolled device rather than a phishable enrollment code. State the fix as prevention of social engineering of identity, not as users needing to be more careful. The enrollment model is where that boundary is enforced.
Would passkeys alone have closed the M&S recovery path?
Not necessarily. Passkeys are phishing-resistant at login. They harden the authentication ceremony. Enrollment, device onboarding, and helpdesk recovery can still use phishable factors unless the deployment forbids that. If Marks & Spencer-style recovery still lets support re-issue access after social proof alone, an attacker who wins the helpdesk call can still enroll or reset into the account. MFA 2.0 is phishing-proof because no phishable factor appears at registration, device onboarding, authorisation, authentication, or decommissioning. That full-lifecycle coverage is what closes the recovery gap passkeys leave open when recovery stays social.
What should CISOs change after the Marks & Spencer helpdesk entry?
Treat workforce recovery as a credential-phase control, not a courtesy desk script. Require already-enrolled device-bound proof for password or factor re-issuance so impersonation of somebody with their details cannot mint a fresh transferable secret. Prefer prevention over detection on the identity lifecycle. Keep ransomware response, ESXi hardening, and data-exfil monitoring for the residual phase after any authenticated foothold. Public reporting does not establish a confirmed personal-record count or ransom payment for Marks & Spencer, so prioritize the documented entry method: third-party helpdesk password-reset social engineering.
