A vendor flagging a missed payment is a painful way to learn attackers already sat in workforce mailboxes for months. According to Mon Health's 21 December 2021 website notice, phishing compromised contractor and employee email accounts, unauthorized access ran from 10 May 2021 to 15 August 2021, discovery came on 28 July 2021 with fraudulent wire-transfer attempts, and the system later stated intent to implement MFA for remote access to email. Phishing-proof device-bound MFA on that remote-email surface would have removed the phishable password and weak second-factor path so stolen workforce credentials alone could not open the mailboxes. Once mailboxes were already open, BEC and wire-fraud attempts sit past authentication. The full timeline and BEC mechanics are on legacymfa.sucks.
FAQ
Would phishing-proof MFA have stopped Mon Health email account takeover?
Yes for the login that opened the mailboxes. The Mon Health incident began when phishing compromised contractor and employee email accounts. Public reporting does not name an AiTM kit, device-code flow, or helpdesk TAP. What is documented is workforce credential compromise leading to remote mailbox access. MFA 2.0 is phishing-proof across the identity lifecycle: there is no transferable password, OTP, or push for an attacker to replay against remote email. That closes repeated sign-ins with the same stolen credentials across a window like May through August 2021. It does not retract mail already read after takeover.
Mon Health planned MFA for remote email. Is ordinary MFA enough?
The control surface is right. Mon Health's December 2021 notice states intent to implement MFA for remote access to email after the phishing-driven account takeovers. Ordinary OTP or push MFA still leaves transferable factors an attacker can capture or coach. Prevention-focused device-bound authentication removes those factors so a captured secret cannot complete remote email sign-in. Passkeys are phishing-resistant at login when origin-bound; MFA 2.0 is phishing-proof across the identity lifecycle. Public reporting does not establish what Mon Health required before the incident.
Does MFA stop Mon Health-style BEC once the mailbox is open?
No. After attackers already control contractor or employee mailboxes, reading mail, staging payment changes, and attempting fraudulent wires are post-authentication impact. No login MFA undoes that phase. Closing the phishable remote-email login stops the path that minted the takeover. Containment after account takeover is session revoke, credential reset, and payment-process controls. Public reporting does not establish whether any fraudulent wires in the Mon Health case completed.
Why does device-bound MFA beat password-plus-OTP on healthcare remote email?
Password-plus-OTP still ships secrets a user can type on a fake page or hand to a coach. Device-bound MFA 2.0 keeps private keys on the enrolled device and demands origin-bound signatures, so remote email login cannot complete from a phished password alone. Healthcare workforces lean on contractors and shared mail patterns; locking remote email to hardware-bound factors shrinks the blast radius of a single phishing message. Malware on a machine that already holds a legitimate session is a harder, separate problem.
What should CISOs lock first after a Mon Health-class notice?
Put phishing-proof MFA on workforce remote email and other high-value mailbox paths before treating BEC as only a finance training problem. Mon Health tied the event to about 398,000 patients and multi-month unauthorized email access. The prevention win is stopping credential-phase mailbox takeover. Pair that with session hygiene and vendor-payment verification so residual fraud after any future compromise is harder to cash. The architecture that binds credentials to devices is the login-side half of that plan.
