Phishing-proof MFA 2.0 would have blocked the City of Oldsmar water-treatment SCADA remote path on 5 February 2021. Unauthorized actors briefly raised sodium hydroxide dosing after remote access that public reporting ties to poor password security and a shared remote-access secret without a multi-factor gate. Device-bound credentials mean a transferable password alone cannot complete operator authentication, so that login never finishes.
For the full attack-chain narrative, read the companion on legacymfa.sucks.
FAQ
Would MFA 2.0 have stopped Oldsmar’s SCADA remote access?
Yes. The Oldsmar water-treatment incident was a credential-phase failure on remote access. Public reporting describes a shared remote password, and post-incident Florida FDLE commentary pushed two-factor authentication, which indicates 2FA was not protecting that path. According to CISA AA21-042A, the actors likely exploited cybersecurity weaknesses including poor password security and an outdated operating system. Desktop-sharing software such as TeamViewer was a possible path the advisory could not confirm at the time. Phishing-proof MFA 2.0 binds authentication to an enrolled operator device with origin-bound public-key signatures. There is no shared secret to type and no OTP or push to coach. Possession of a remote password alone fails. Closing that password-only remote login stops this path.
Why is a stronger shared password not enough for industrial remote access?
A stronger shared password only raises the bar on guessing or reuse. It leaves the architecture that failed at Oldsmar intact: one transferable secret, usable by anyone who holds it, with no second factor on the remote path. AA21-042A pairs strong passwords with multiple-factor authentication for remote access and RDP for that reason. Prevention-focused device-bound authentication removes the transferable factor entirely rather than hoping a shared remote secret stays secret forever.
Would passkeys alone have been enough at Oldsmar?
Passkeys and FIDO2 are phishing-resistant at login when the remote path actually demands a hardware-bound signature. That would still defeat a password-only shared remote secret if the gate required them. MFA 2.0 is phishing-proof across the identity lifecycle, with no phishable factor at registration, device onboarding, authentication, or decommissioning. For Oldsmar, the documented gap was simpler: remote access a shared password could complete without a second factor. Public reporting does not establish a separate enrollment or recovery compromise on this incident.
What does MFA 2.0 not undo after an operator is already on the console?
No login MFA undoes process changes made during a live, legitimate SCADA session. If malware or physical access abuses an already-authenticated operator workstation, that is residual endpoint and operational-technology control work. At Oldsmar the documented failure was getting onto the system without a non-transferable factor. Closing the password-only remote login is the prevention claim. Malware after a legitimate operator login is a harder, separate problem.
How should water utilities authenticate remote SCADA access?
Require a phishing-proof, device-bound factor for every remote path into control networks, including desktop-sharing and RDP. Do not allow a shared password as the sole gate. Tie each session to a named operator identity and an enrolled device. AA21-042A already recommended multiple-factor authentication for remote access after this class of incident. The upgrade is to drop transferable factors so a leaked or shared remote secret cannot finish sign-in. The device-bound architecture enforces that boundary without a central password database to steal.
