According to the NYDFS Healthplex Consent Order, on or about 22-23 November 2021 an employee typed business email credentials into a phishing site that used a fake fax lure. MFA was not enabled for Outlook Web Access after Healthplex’s O365 migration, so the actor opened the employee mailbox in a browser with the password alone. Requiring phishing-proof device-bound authentication on every external Microsoft 365 mail path stops that password-only session from existing. For the full attack chain and figures, read the companion on legacymfa.sucks.
FAQ
Would phishing-proof MFA have stopped the Healthplex O365 mailbox login?
Yes. Phishing-proof MFA 2.0 would have stopped the Healthplex Office 365 mailbox login because a stolen password alone cannot finish sign-in when every external Outlook Web Access path demands a device-bound, origin-bound signature. The employee still could have typed credentials into the fake fax lure; the actor still would not have received a usable web-mail session. Closing that phishable login stops this path. Malware after a legitimate login is a harder, separate problem.
Is “turn on any MFA” enough to prevent a Healthplex-style OWA breach?
Turning on a real second factor on Outlook Web Access would have blocked the specific Healthplex path, which was password-only external web mail after O365 migration. That is necessary and still not the full control choice. Legacy OTP, SMS, email codes, and push approvals remain transferable factors other campaigns coach or relay. MFA 2.0 removes those phishable factors at login and across enrollment so workforce mail cannot open on a password harvested from a lure. See why legacy MFA was dropped when transferable second factors keep failing the same class of social engineering.
Do passkeys alone match MFA 2.0 for O365 web mail after credential phishing?
Passkeys are phishing-resistant at the login ceremony when the real enterprise origin is enforced and downgrade paths are closed. They harden authentication only. If enrollment or recovery still depends on email OTP, SMS, or helpdesk-issued secrets, an attacker who controls that channel can still onboard a device that later looks legitimate. MFA 2.0 is phishing-proof across the identity lifecycle: registration, device onboarding, authorisation, authentication, and decommissioning use no transferable factor. For a Healthplex-style fake fax lure, either control beats password-only OWA; full-lifecycle coverage is what keeps the next recovery or new-device story from reopening the same mailbox class.
Does MFA 2.0 remove NPI already stored in a compromised Healthplex mailbox?
No. MFA 2.0 does not scrub residual NPI already present in a Healthplex employee mailbox after a fully authenticated session exists. NYDFS-related figures put that mailbox on the order of roughly 130,000 emails, with related reporting citing on the order of about 89,955 members and tens of thousands of New York residents’ NPI reachable in residual mail. Prevention value is upstream: deny the password-only Outlook Web Access session so the actor never reads that content through a browser login. Public reporting does not establish a single exact affected-individual headcount across every figure.
What should CISOs require on external Microsoft 365 mail after an O365 migration?
CISOs should require phishing-proof, device-bound MFA on Outlook Web Access and every other external Microsoft 365 mail path before calling a migration finished. Healthplex became aware on 24 November 2021 that the employee mailbox had been opened after MFA was left off OWA post-migration. Password-only web mail turns one successful credential phishing email into direct NPI exposure. Pair that login bar with revoke hygiene for any session that somehow still exists, and treat endpoint malware after a legitimate login as a separate control problem.
