According to Workday’s Security and Trust blog on 15 August 2025, threat actors contacted employees by text or phone while pretending to be from human resources or IT, seeking account access or personal information, and later retrieved some commonly available business contact data from a third-party CRM. Phishing-proof device-bound MFA 2.0 stops that credential-phase path: there is no password, OTP, SMS code, email code, push approval, or recovery secret staff can be coached into handing over live. Closing the phishable login stops this path. Malware after a legitimate login is a harder, separate problem, and CRM data pulls after authentication already succeeded are residual containment work. For the incident narrative and disclosure detail, read the companion on legacymfa.sucks. The same recovery-hardening lesson appears in helpdesk password-reset social engineering.

FAQ

Would phishing-proof MFA have stopped the Workday HR/IT social engineering path?

Yes for the credential phase of the Workday third-party CRM social engineering incident. According to Workday, actors used live text and phone coaching under an HR or IT persona to obtain account access or personal information. Phishing-proof MFA 2.0 removes transferable factors across login and recovery, so a coached call or text cannot complete a usable workforce sign-in or factor handoff the attacker can replay. Public reporting does not name TAP, a spoofed page, AiTM, or a specific MFA method for this case, but the prevention claim does not need those labels: if the usable secret never exists, the coach has nothing to collect. The prevention-focused design is about eliminating that surface, not detecting a bad call after the fact.

Do passkeys alone close the lifecycle gap this attack class exploits?

Not by themselves. Passkeys and WebAuthn are phishing-resistant at the login ceremony: origin-bound signatures harden authentication. Enrollment, device onboarding, and recovery can still rely on email codes, SMS, push, or helpdesk-issued secrets unless policy forbids that. MFA 2.0 is phishing-proof across the identity lifecycle, including enrolment and adding a device only from an already-enrolled device. For Workday-style HR/IT phone and text coaching aimed at account access, that full-lifecycle coverage is what closes the handoff path passkeys leave open when recovery stays phishable.

What does MFA 2.0 not undo after Workday-style account access succeeds?

MFA 2.0 does not undo post-authentication use of a third-party CRM once account access already exists. Workday reported that actors accessed some information from its third-party CRM platform, primarily commonly available business contact information such as names, email addresses, and phone numbers, with no indication of access to customer tenants or data within them. That data-access stage is residual: revoke access, cut sessions, and add platform safeguards. Public reporting does not establish session-cookie theft mechanics, OAuth token issuance, or the CRM vendor name. Login MFA’s job was upstream, stopping the coached account-access handoff.

How should workforce recovery be designed against phone and text HR/IT coaching?

Treat recovery as part of authentication, not a side channel. Do not let IT or HR read out passwords, one-time codes, temporary access secrets, or enrollment codes over phone or SMS. Prefer device-bound proof where adding or replacing a factor requires possession of an already-enrolled device, not a transferable secret a stranger can request under a trusted persona. Workday stated it will never contact anyone by phone to request a password or other secure details, and that official communications come only through trusted support channels. Policy language helps; cryptography that leaves no secret to recite enforces it.

Is awareness training enough against HR or IT impersonation calls?

No. Training reduces some click and approval mistakes, but Workday-style campaigns succeed by borrowing institutional trust in HR and IT over live channels. A skilled coach still wins when the identity system accepts a typed code, approved push, reset password, or recovery secret obtained off-channel. Phishing-proof device-bound MFA changes the architecture so those transferable factors are not part of login or recovery. User caution remains useful hygiene. It is not a substitute for removing the handoff surface the call is designed to collect.