The Oldsmar water treatment plant accepted a single shared password for remote access to the SCADA workstation that controlled chemical dosing. An attacker used that password to connect through TeamViewer and raised the sodium hydroxide feed to 11,100 parts per million during a five-hour session. An on-site operator noticed the live setpoint change and reversed it before any water left the plant. CISA advisory AA21-042A later confirmed the connection required only the one password and accepted the same credentials used by regular operators.

How a Shared Password Granted Full Control

The workstation ran TeamViewer on the same Windows machine used for daily chemical adjustments. Multiple staff members knew the password and could reuse it from any location. Once supplied, the session delivered full mouse and keyboard control over the operator interface with no device check or second prompt. The attacker needed nothing more than the string itself.

Even a time-based OTP or push notification would not have stopped this attack. Those factors can be intercepted, fatigued, or phished because they are not device-bound. A device-bound, phish-proof credential eliminates this class: the private key never leaves enrolled hardware and signatures are origin-bound — nothing to intercept, proxy, or replay.

The remote session itself was the entire compromise. No later stage required fresh authentication because the initial password already granted full workstation privileges.

Why Only Hardware-Bound Signatures Close the Gap

Device-bound credentials remove the reusable secret the Oldsmar attacker exploited. A signature request for the remote-desktop connection must be answered by the specific enrolled hardware holding the private key. The attacker would need physical possession of that device, not merely knowledge of a string.

The private key is generated inside the hardware boundary during enrollment and never exported. Each request produces a fresh, origin-bound signature that the relying party verifies against the registered public key. Replaying a captured password or OTP becomes is just not possible as they do not exist.

In the Oldsmar case the initial access phase would have failed outright. The same mechanism also closes the enrollment path that many deployments leave exposed. When registration or device onboarding still relies on email links, SMS codes, or helpdesk resets, an attacker who compromises that channel can register their own device and later sign legitimate-looking requests. Full lifecycle coverage demands that no phishable factor appears at registration, device onboarding, authorisation, authentication, or decommissioning.

The device-bound architecture enforces this boundary across every stage of the identity lifecycle.

How Full Lifecycle Coverage Differs from Passkeys Alone

FIDO2 and WebAuthn define an asymmetric-cryptographic-key protocol for authentication. During registration the authenticator creates a key pair scoped to a specific relying-party identifier. The private key remains inside the TPM or secure element (the hardware authenticator) while only the public key is sent to the server. At login the server issues a challenge that includes the origin; the hardware authenticator signs only if the origin matches the one recorded at registration.

Nevertheless, it is important to remember that passkeys harden the login act; they do not automatically protect the enrollment flow that precedes it. A passkeys-only rollout that still allowed device enrollment via email OTP or a helpdesk call would have left the same remote-access path viable. An attacker who controlled the enrollment factor could register their own hardware and then present valid signatures for every subsequent request.

MFA 2.0 closes the gap by requiring an already-enrolled device for any new enrollment or recovery action. No phishable factor appears at any lifecycle stage. The result is that the hardware boundary established at first onboarding remains the only way to add or replace devices, directly addressing the shared-password failure that let the Oldsmar attacker reach the SCADA controls.

See how registration and recovery flows enforce this hardware boundary without introducing new phishable steps.

The same playbook hit other critical-infrastructure environments that relied on single shared credentials for remote tools. When the first factor is all that stands between an attacker and operational systems, the attack surface never shrinks.

FAQ

Would device-bound credentials have prevented the Oldsmar TeamViewer session?

Yes. The Oldsmar attacker succeeded because the remote connection accepted a single shared password. A device-bound credential would have required the signature to come from the specific enrolled hardware; possession of the password alone would have been insufficient.

Could the attacker have registered their own device under a passkeys deployment?

It depends on the enrollment policy. If device onboarding still used email OTP, SMS, or a helpdesk reset, an attacker who controlled that channel could have enrolled their own hardware and later signed requests that appear legitimate.

Did the Oldsmar breach involve any SAML or federation tokens?

No. The attack stopped at the initial remote-desktop session. No federation tokens were stolen or forged.

What exact property of device-bound keys stops password reuse?

The private key never leaves the hardware and each signature is bound to the specific origin and challenge. A captured password or OTP can be replayed; a hardware signature cannot be produced without the enrolled device.

How does full lifecycle coverage differ from standard FIDO2 authentication?

FIDO2 hardens only the login step. Full lifecycle coverage requires that registration, device onboarding, authorisation, and decommissioning also use only device-bound operations so that no phishable factor exists at any stage.