Help-desk social engineering exposed a fundamental weakness in how many retailers still handle MFA enrolment and recovery. Scattered Spider used impersonation calls against Marks & Spencer and the Co-operative Group in May 2025, persuading staff to issue fresh approvals or reset tokens. No malware or zero-day was needed; the existing processes simply treated a phone conversation as adequate proof for granting a second factor.
Attackers researched internal support procedures, spoofed caller identities, and obtained valid session tokens. With those tokens they reached remote-desktop and VPN systems, moved laterally through Active Directory, and deployed ransomware that disrupted distribution and online ordering for weeks. The same pattern had already succeeded elsewhere because standard MFA workflows still allow the second factor to be transferred through human approval.
How Help-Desk Procedures Converted MFA into a Transferable Token
Attackers did not need to compromise servers or guess passwords. They only needed the existing process to treat a phone conversation as sufficient proof for issuing or approving a second factor. Once an approved push notification or new session token was granted, the attackers connected through legitimate remote-access portals that accepted the token without further device verification. This approach bypassed technical controls because the weakness sat in the registration and recovery flows rather than the sign-in step itself.
Why Standard MFA Could Not Prevent the Initial Access
Push notifications and OTPs remain vulnerable when approval or re-enrolment can be socially engineered. The second factor functions as a transferable secret rather than a cryptographic proof tied to a specific device. Standards that strengthen only the authentication event leave enrolment, recovery, and policy-change steps exposed, allowing attackers to obtain fresh, valid credentials before any login attempt occurs.
Device-Bound Public-Key Credentials Remove the Transferable Factor
MFA 2.0 replaces reusable credentials and phishable approvals with device-bound key pairs built on public-key cryptography—the same technology used in Apple Pay and Google Pay. These credentials never leave the endpoint and require no central database. Authentication occurs on the same device; no second device or transferable secret is involved.
When enrolment, device addition, policy changes, daily authentication, and recovery all rely on cryptographic proof from already-attested endpoints, a phone call to the help desk yields nothing usable. The operator has no secret or approval token to transfer. Recovery flows can be restricted to attestation from another pre-enrolled device or a time-bound administrative token that itself cannot be socially engineered.
This approach is prevention-focused rather than detection-focused. The attack cannot occur because no extractable factor exists at any stage of the identity lifecycle. The same credential-and-social-engineering pattern observed here has appeared in dozens of prior incidents; removing transferable secrets eliminates the root condition that allowed initial access.
