A lost-phone story in chat should never mint a multifactor authentication token an attacker can use from anywhere. Motherboard reported in mid-June 2021 that attackers inside an Electronic Arts Slack workspace messaged IT support, claimed a phone was lost at a party, and received MFA tokens twice. That helpdesk handoff is the workforce identity failure phishing-proof MFA 2.0 is built to close: enrollment and recovery must not mint a transferable factor after chat-only proofing. Purchased Slack session cookies only got them into chat; the ~780 GB source-code theft came after network access already existed.
For the full cookie-plus-helpdesk attack chain, read the companion on legacymfa.sucks.
FAQ
Would MFA 2.0 have stopped EA IT from handing over MFA tokens?
Yes, for the helpdesk phase of the Electronic Arts breach. According to a representative for the hackers speaking to Motherboard, once inside Slack they told IT support a phone was lost at a party and requested an MFA token, and that request succeeded twice. Phishing-proof MFA 2.0 removes transferable recovery secrets from that path. There is no OTP, SMS code, push approval, or temporary access secret for support to read out after a chat story. Adding or restoring a factor requires an already-enrolled device, not a phishable enrollment code. That is phishing-proof enrolment across the identity lifecycle, not a hope that helpdesk staff will spot a better liar.
Why is the Slack cookie foothold outside the prevention claim?
The Slack cookie foothold in the Electronic Arts case is post-authentication token replay, not a live login MFA challenge. Attackers purchased already-valid Slack authentication cookies online for about $10 and used them as the victim employee. Public reporting does not establish how those cookies were originally stolen from the endpoint. Stronger MFA at Slack sign-in does not revoke cookies already issued and sitting in a marketplace. Closing the phishable recovery path stops the helpdesk step that opened the corporate network. Malware or cookie theft after a legitimate login is a harder, separate problem.
How does phishing-proof recovery beat a lost-phone helpdesk story?
Phishing-proof recovery beats the Electronic Arts lost-phone pattern by refusing any factor IT can hand to a stranger. Legacy helpdesk flows treat a convincing chat message as enough identity proof, then deliver a code or token the attacker can use from anywhere. Device-bound credentials never place a reusable secret on that channel. The private key stays on enrolled hardware; the server holds only public material. A coached lost-phone claim therefore has nothing useful to collect. The same class of failure shows up in later helpdesk password-reset social engineering, including cases covered in stop helpdesk password-reset social engineering: chat or voice proofing must not re-issue a transferable credential.
Would passkeys alone have closed the Electronic Arts recovery path?
Not necessarily. Passkeys and WebAuthn are phishing-resistant at the login ceremony: origin-bound signatures harden authentication when enrollment is already clean. The Electronic Arts failure was recovery. If a deployment still lets helpdesk re-enroll or issue a temporary factor after a lost-phone story over Slack, an attacker who wins that conversation can land on a device that later signs legitimate-looking assertions. MFA 2.0 is phishing-proof because no phishable factor appears at registration, device onboarding, recovery, authentication, or decommissioning. Phishing-resistant login without locked-down recovery still leaves the EA helpdesk path open.
What stays residual after you harden EA-style enrollment?
After you close helpdesk lost-phone token handoffs, two Electronic Arts phases remain residual. Session cookies already stolen offline still need revoke, short lifetimes where practical, and endpoint hygiene; no login MFA undoes a cookie marketplace purchase. Source-code exfiltration through a developer compilation service and internal VMs is post-authentication abuse of access already granted. EA stated via Motherboard that no player data was accessed and that a limited amount of game source code and related tools were stolen; hackers claimed about 780 GB. Public reporting does not establish a named threat actor or exact intrusion calendar dates. Prevention, not detection owns the recovery step. Containment owns everything after a session or network foothold already exists.
