According to Michigan Medicine's consumer notification (Montana DOJ filing), between 23 and 29 May 2024 an attacker called the IT Service Desk, impersonated employees, and triggered password resets that compromised three workforce email accounts. Phishing-proof device-bound MFA hardens helpdesk recovery so a caller cannot re-issue transferable passwords from a phone alone; closing that path stops this attack. For the full attack-chain write-up, see the companion on legacymfa.sucks. The same recovery gap later showed up in Marks & Spencer helpdesk reset social engineering.
FAQ
Would phishing-proof MFA have stopped the Michigan Medicine helpdesk resets?
Yes. Phishing-proof MFA 2.0 would have stopped the Michigan Medicine May 2024 path at recovery because a vishing caller cannot mint a new password or authenticator without proof-of-possession on an already-enrolled device. According to Michigan Medicine's consumer notification, the attacker obtained login credentials by triggering IT Service Desk password resets after impersonating employees. Legacy helpdesk flows that accept caller identity claims and issue transferable secrets fail before any later mailbox prompt can matter. Phishing-proof enrolment removes that re-issue surface across the identity lifecycle.
How does MFA 2.0 differ from passkeys for this recovery abuse?
Passkeys are phishing-resistant at the login ceremony; they do not automatically close a phishable helpdesk reset that still hands out a password. MFA 2.0 is phishing-proof across registration, device onboarding, recovery, authentication, and decommissioning, so there is no OTP, SMS code, email code, push, or recovery secret for IT to read out or for a coached caller to collect. The Michigan Medicine Service Desk event was credential-phase abuse at recovery, not a defeated FIDO assertion on a spoofed origin. Public reporting does not establish which MFA Michigan Medicine had deployed on the three email accounts after the reset.
What remains after you close helpdesk password-reset social engineering?
Closing the phishable recovery path stops helpdesk password-reset social engineering like the Michigan Medicine IT Service Desk calls. Once a successful legacy reset has already issued attacker-held credentials and mailbox access has occurred, no login MFA undoes that access. Revoke and account hygiene still matter for sessions that already exist. Malware after a legitimate login is a harder, separate problem. Prevention, not detection is the design goal: the call never obtains a transferable factor in the first place.
Is the May Service Desk breach the same as Michigan Medicine's July MFA-prompt incident?
No. The May 2024 IT Service Desk password-reset impersonation is distinct from a separate July MFA-prompt incident at Michigan Medicine. Public materials used for this analysis instruct not to conflate the two. Public reporting does not establish the July incident's technique, impact, or timeline in enough detail to analyze prevention claims for it here.
Why treat helpdesk reset vishing like a coached fake login?
Both are live coaching of a transferable factor. In the Michigan Medicine case, a technician was talked into completing password resets that handed the attacker new credentials for three workforce email accounts. On a spoofed login page, a user is talked into typing a password or approving a push. MFA 2.0 stops both because there is no phishable secret to reset over the phone and no transferable factor to type on the wrong origin. Adding a device requires an already-enrolled device, not a recovery code an attacker can collect on a call.
