Workday Breach: Device-Bound Keys Eliminate What Employees Can Read Aloud

As covered on legacymfa.sucks, the Workday incident began when threat actors impersonated internal staff and convinced employees to hand over account details by phone or text. The attackers then used those details to reach a connected third-party CRM containing limited customer and employee records. Core Workday HR systems saw no broad intrusion.

The initial access phase hinged on a human transferring a secret that could be spoken. Traditional MFA inspects only the moment a login request arrives at a server. When the employee themselves supplies the value, that inspection point is never reached.

Why Verbal Credential Transfer Succeeds Against Every Phishable Factor

The compromise succeeded because the required value—password, OTP, or push approval—could be read or performed by the legitimate account holder and relayed to someone else. An OTP sent to a shared inbox or a push notification approved under pressure both fit the same pattern. Once the employee had spoken the code or granted the approval, the attacker possessed everything needed for the subsequent CRM login.

MFA 2.0 changes the equation at the enrollment stage itself. During device onboarding a private key is generated inside hardware and never leaves that boundary. The corresponding public key is registered with the service. No string, code, or approval token ever exists that an employee can dictate over a call. The signature required for any later action is produced only when the enrolled hardware itself performs the cryptographic operation.

This distinction matters across the identity lifecycle. Registration, device onboarding, authorisation, authentication, and decommissioning all avoid phishable factors. FIDO2/passkeys/WebAuthn strengthens only the authentication step; the earlier stages remain exposed to the same social-engineering pressure seen in the Workday case.

Per-Phase Verdict on the Workday Attack Chain

Step 0 of the analysis asks what was stolen or abused in each phase. In the initial-access phase a credential was obtained through human transfer, not through interception of a login. MFA 2.0 removes the attack surface because the credential the employee could have read no longer exists. The later phase—use of the supplied details inside the CRM—required no fresh interactive login from Workday systems. Stolen tokens or session material cannot be prevented by any authentication method once the employee has already decided to disclose access.

The same pattern appears in earlier Scattered Spider operations that relied on help-desk or colleague impersonation. In every instance the decisive moment was the transfer of a value that could be spoken. Device-bound keys make that transfer impossible.

Lifecycle Coverage Versus Single-Stage Hardening

Phishing-resistant standards focus on the login ceremony. They require the private key to stay on the authenticator and bind the signature to the correct origin. That protection is valuable, yet it leaves registration and recovery flows untouched. An attacker who convinces support staff to re-enroll a device can still insert their own hardware if the enrollment process accepts a phishable factor.

MFA 2.0 applies the same hardware boundary to every stage. Onboarding requires proof from an already-enrolled device. Recovery flows are likewise gated by existing hardware rather than knowledge the attacker can extract over the phone. The result is that the social-engineering script used against Workday loses its payload: there is simply nothing for the employee to read aloud.

The operational consequence for defenders is straightforward. Instead of adding detection layers that trigger after a secret has already left the organisation, the design removes the secret from the reachable surface in the first place. Prevention—not detection follows directly from the mechanics of the breach.

FAQ

Would device-bound credentials have stopped the credential hand-off in the Workday incident?

Yes. Because the private key never exists as a readable value, an employee cannot dictate it during an impersonation call. The Workday attackers relied entirely on that transfer.

How does MFA 2.0 differ from FIDO2/passkeys for social-engineering attacks?

FIDO2/passkeys protect the authentication step. MFA 2.0 also protects registration, device onboarding, authorisation, and decommissioning so that no phishable factor is introduced at any point in the lifecycle.

Did the Workday attackers need to defeat any MFA prompt?

No. They never initiated a login themselves. The employee supplied the credential directly, bypassing every server-side check.

What changes for recovery flows when only device-bound keys are accepted?

Re-enrollment or authentication require cryptographic proof from hardware the employee already controls. An attacker on the phone cannot supply that proof.

Could the same impersonation tactic succeed against systems using MFA 2.0?

Only if private devices are allowed and the employee is tricked into adding a new device—an action that itself demands an already-enrolled device. The verbal transfer that worked in the Workday case becomes impossible.