Reusable login secrets still open healthcare mailboxes when a lure can collect something transferable. Phishing compromised a limited number of employee email accounts at Children’s Hospital of The King’s Daughters (CHKD) in Norfolk, Virginia, on 20 April 2021. According to HIPAA Journal, attackers could view messages and attachments holding PHI for some CHKD patients and guarantors, certain Sentara Norfolk General Hospital lab and diagnostic patients, and some student athletes. Public reporting does not establish AiTM kits, device-code phishing, helpdesk recovery, a named actor, or whether those mailboxes required MFA. Phishing-proof, device-bound MFA 2.0 removes the reusable secrets classic workforce email phishing harvests, so that lure never finishes a usable mailbox login. After the accounts are already open, reading inbox content is residual access no login MFA undoes.
For the disclosure timeline and attack-chain detail, read the companion on legacymfa.sucks.
FAQ
Would phishing-proof MFA have stopped the CHKD employee email path?
Phishing-proof MFA 2.0 would have blocked the classic credential-harvest path that opened CHKD’s employee mailboxes: workforce email phishing that yields a usable login. Device-bound, origin-bound signatures leave no password, OTP, SMS code, or push approval for a lure to collect and replay. Public reporting does not establish CHKD’s MFA status, so this is a control verdict on the attack class, not a claim about what CHKD had enabled in 2021. Closing that phishable login stops the account-takeover path. Malware after a legitimate login is a harder, separate problem.
Does any MFA undo PHI reading once CHKD mailboxes were open?
No. Once the CHKD employee email accounts were already compromised, viewing messages and attachments was ordinary use of an open mailbox, not a second authentication ceremony. MFA 2.0’s prevention value sits entirely upstream: the phishing attack never obtains a transferable factor and never completes login. Revoke, mailbox audit, and forensics remain hygiene after takeover. That is prevention, not detection.
Are passkeys enough for healthcare workforce email phishing like CHKD’s?
Passkeys and WebAuthn are phishing-resistant at the login act: they bind the ceremony to the real origin and remove typed secrets at authentication. That already defeats many classic email lures that only harvest passwords or relayable codes. MFA 2.0 is phishing-proof across the identity lifecycle (registration, device onboarding, authorisation, authentication, decommissioning), so no phishable enrollment or recovery factor reopens a back door later.
| Control | Coverage for CHKD-class email phishing |
|---|---|
| Password / OTP / push | Phishable; lure can collect or coach a transferable factor |
| Passkeys / WebAuthn | Phishing-resistant at login; enrollment/recovery can still reintroduce phishable factors |
| MFA 2.0 (device-bound) | Phishing-proof across the full identity lifecycle |
For CHKD-style workforce email phishing, public notices stop at mailbox access via phishing and do not describe enrollment abuse. Harden login first; close the full lifecycle so recovery cannot reintroduce a transferable secret.
What should healthcare CISOs still do after a CHKD-style email compromise?
Treat prevention and containment as different jobs. Deploy phishing-proof, device-bound workforce MFA on employee email and every path that can mint a mailbox session, so a phishing page has nothing useful to steal. After any suspected takeover, revoke sessions, force re-authentication only through enrolled hardware, review mail rules and forwarding, and complete the forensic scope work CHKD described (secure the environment, engage third-party review, notify when individual lists are known). CHKD stated additional anti-phishing measures were being implemented and that no evidence suggested the exposed information had been or would be misused. Shorter token lifetimes and monitoring help after a bad session exists; they do not replace removing phishable login factors.
How should defenders talk about MFA when notices leave MFA status unnamed?
Say only what sources support. For CHKD, public reporting establishes phishing against a small number of employee email accounts and subsequent PHI exposure in those mailboxes. Public reporting does not establish MFA enabled or disabled, an AiTM reverse proxy, stolen session cookies as the stated vector, or a helpdesk reset. The honest line is: phishable workforce email login is the preventable failure mode; phishing-proof device-bound MFA closes that surface; post-takeover mailbox reading is residual. That framing keeps CISOs accurate with boards and regulators while still dropping legacy MFA factors that phishing can coach or capture.