The attackers contacted employees directly, posing as colleagues who needed urgent help with account issues or verification steps. Once the employee believed the story, they provided the requested credentials or performed actions that granted the attackers entry. This approach required no phishing site, no OTP interception, and no push notification. It relied on the employee voluntarily transferring access.
Public reporting ties the tactic to groups such as Scattered Spider. The same method has appeared in earlier incidents where support staff were convinced to reset or share credentials under the guise of routine IT tasks. In the Workday case, the goal was entry into a connected CRM system rather than the core HR platform itself.
Because the attackers never attempted a login themselves, any second-factor check tied to that login never triggered. The compromise occurred at the point where a human decided to hand over the information.
Why Standard Account Protections Did Not Apply
Traditional MFA only inspects authentication attempts. When an attacker never logs in and instead persuades an authorized user to supply the details, the MFA layer has nothing to evaluate. The same limitation applies to password policies or account lockouts. The entry point was human compliance, not a failed login.
Workday stated that the attackers obtained access to limited customer and employee information through the CRM connection. No evidence has surfaced of widespread lateral movement inside Workday’s primary systems after the initial hand-off. The breach therefore stayed contained to the data reachable once the impersonation succeeded.
The pattern matches earlier Scattered Spider operations that targeted organizations with valuable customer data. Those campaigns also began with voice or SMS contact rather than technical exploits against authentication servers.
What Changed After the Access Was Granted
Once inside the CRM, the attackers could view records without further interactive logins from Workday accounts. The stolen access functioned like a stolen session token: authentication had already occurred when the legitimate employee used their credentials. No MFA could retroactively protect data that the account holder had already decided to expose.
Discovery came through internal monitoring of unusual CRM activity. Workday notified affected parties and began reviewing connected third-party integrations. The incident highlighted how a single successful social-engineering contact can reach data stores that sit outside the primary identity perimeter.
The fix isn't complicated, but it requires ditching legacy MFA entirely. The full technical breakdown of what actually works is at https://mfa2point0.com.
FAQ
Did Workday use MFA at the time of the breach?
Workday has not disclosed whether MFA covered the specific accounts that were compromised through the impersonation calls.
Would push notifications have stopped the Workday attackers?
No. The attackers never triggered a login prompt; they obtained credentials by convincing employees to provide them directly.
How did Scattered Spider reach the CRM platform?
They used credentials supplied by tricked employees to access a third-party CRM that was connected to Workday customer data.
What data was exposed in the Workday incident?
Limited customer and employee information stored in the targeted CRM was accessed; core Workday HR systems were not broadly compromised.
Could device-bound credentials have changed the outcome?
Device-bound credentials would have removed the ability for an employee to simply read a password or code over the phone, because no such value exists to share.
