The Workday data breach happened when attackers used social engineering to access a third-party CRM platform connected to Workday’s systems. What makes this incident particularly noteworthy is that Workday’s core production environment wasn’t touched. If you’re tracking this incident, understand that the exposure occurred in a connected CRM app, not in Workday customer tenants.

This matters because your SaaS stack runs on integrations and delegated access. When attackers compromise identities or OAuth tokens, they can slip into connected tools and extract sensitive business context without ever touching your primary systems.

This article breaks down what happened, what data was exposed, and the practical lessons you can apply to SaaS security, identity protection, and third-party risk management.

Workday Data Breach Timeline

Here’s a straightforward sequence of events that shows how the incident unfolded and which systems were affected.

  • June 2025: Google discloses a broader social engineering campaign targeting Salesforce customers, in which attackers impersonate IT or HR staff by phone to steal credentials or trick employees into approving malicious connected apps.
  • August 15, 2025: Workday publicly discloses that attackers accessed information in a third-party CRM platform after targeting employees with social engineering. Workday confirms there’s no indication of access to customer tenants or tenant data in the Workday platform.
  • August 23, 2025: In a related but separate incident, Workday discovers a security issue in Salesloft’s Drift application, a third-party app connected to Salesforce. Workday disconnects the app, invalidates Drift tokens, and launches a forensic investigation.
  • August 26, 2025: Salesloft publishes additional details. Workday confirms that a limited set of information in its Salesforce environment could be queried through the compromised Drift OAuth connection.
  • Affected systems: A third-party CRM (Workday’s Salesforce environment) and a connected app (Salesloft Drift).
  • Not affected: Workday customer tenants and the data within them, including HR, payroll, and financial records.
  • Immediate actions: Workday cut off the malicious access and killed every token and integration tied to Drift. They brought in forensics specialists and locked down similar access paths to prevent repeats.

Data Exposed in the Workday Data Breach

Attackers reached CRM records through a third-party integration, not by entering Workday customer environments. That distinction matters because CRM systems hold business relationships, support context, and operational details that attackers can use to launch follow-on attacks.

Based on Workday’s disclosures, the accessible data focused on business and operational context, not sensitive HR or payroll data. Here’s what was exposed:

  • Business contact information (from the social engineering incident): Names, work email addresses, and phone numbers.
  • Support and CRM context, limited (from the Drift-related incident): A small subset of basic support case information.
  • Tenant and system attributes (from the Drift-related incident): Tenant name, data center name, Workday product and service names, training courses or certificates, and certain system event logs.

What wasn’t included: External files stored in Salesforce, like contracts, order forms, or customer attachments. Any data from Workday customer tenants, including HR, payroll, Social Security numbers, or financial records.

 Even basic contact data is valuable to attackers. It helps them craft targeted phishing and vishing that sounds legitimate. A convincing call that references a real support ticket or product name can lower your team’s defenses and open the door to deeper compromise.

Detection, Containment, and Third-Party Risk Response

Workday’s security team spotted something off: suspicious access patterns in a connected app, all happening while social engineering attacks were already underway. On August 23, 2025, they identified the compromised Drift integration and immediately moved to isolate it. A few days later, on August 26, vendor updates helped them nail down exactly what data was exposed.

The containment playbook was textbook. They revoked OAuth tokens and disconnected Drift completely. A third-party forensics firm validated the findings. Workday also combed through their vendor list to find anyone else using Drift and scanned support tickets for accidentally shared credentials – then notified affected customers.

After the dust settled, Workday hardened its CRM environment and tightened operational hygiene. Keep credentials out of support tickets and make credential rotation a habit, not an afterthought. Layer stronger authentication on sensitive tasks before someone tricks their way past your defenses.

This is a classic third-party risk story, and it’s worth understanding why. CRM platforms are the nerve center of sales, support, and partner operations. They’re loaded with connected apps that rely on token-based access. If one app gets compromised, the blast radius can extend to downstream organizations and business contacts. You need continuous monitoring of OAuth activity and unusual query patterns – especially when attackers start with identity tricks instead of exploiting software vulnerabilities.

Social engineering cranks up SaaS risk because it targets people, not code. A convincing “IT” request can bypass your entire patch management program in seconds. You can blunt this threat by pairing phishing-resistant authentication with real-time detections for risky logins and suspicious token grants in your most critical SaaS platforms.

Regulatory, Compliance, and Third-Party Risk Implications

Regulators are done letting companies off the hook for vendor risk. They expect you to manage the security of your integrations and third parties, not just your own code. CRM platforms concentrate customer relationships and operational context, so exposure here creates headaches on multiple fronts, even if no regulated HR or financial data is touched.

Shared responsibility runs through the entire SaaS stack. Providers secure their platforms, but you need to harden identity controls and scrutinize what integrated apps can read or write. When social engineering is the entry point, your governance should cover employee verification processes and rapid token revocation the moment something feels off.

OAuth and delegated access deserve board-level attention. Tokens can outlive passwords and silently authorize broad data access. Over-privileged scopes and stale app connections expand your attack surface faster than you think. Regular audits of connected apps will reduce your exposure. Prune scopes to least privilege and alert on anomalous data queries before they turn into headlines.

SaaS ecosystems expand your perimeter, and every integration adds new data flows and identity trust decisions. Treat governance of those decisions – who can connect what, with which scopes, and for how long – as a first-class control, not an afterthought.

Lessons Learned from the Workday Data Breach

Use these practices to strengthen SaaS security, identity protections, and third-party oversight:

  • Continuously monitor third-party SaaS and CRM activity. Track OAuth grants, token usage, and unusual queries. Alert on new connected apps, scope changes, and sudden spikes in export-like behavior.
  • Adopt phishing-resistant authentication where feasible. Use hardware-backed or platform-bound methods for admin, support, and integration owners. Require step-up authentication for sensitive actions.
  • Review OAuth permissions and app inventories on a schedule. Map every connected app, its owner, and its scopes. Remove unused integrations and trim scopes to least privilege.
  • Instrument the human layer. Train your team to spot vishing and SMS lures. Give them a fast, judgment-free channel to verify “urgent” IT or HR requests before they share credentials or approve access.
  • Keep secrets out of tickets and chat. Normalize redaction and scan for credentials in support cases. Rotate any credentials that show up in the case history.
  • Treat connected SaaS like critical infrastructure. Put CRM and similar platforms under the same change control, logging standards, and incident playbooks you use for core systems.
  • Test the kill-switch. Practice rapid token revocation and app disconnects. Measure how quickly you can quarantine an integration across all tenants.

Panorays helps you manage third-party cyber risk by adapting to each unique vendor relationship and providing actionable guidance to stay ahead of emerging threats. You’ll get a clear picture of vendor exposure across your ecosystem, with workflows that support continuous oversight and faster remediation aligned to your third-party risk priorities. This approach reflects our broader mission to reduce supply chain cyber risk so companies can securely do business together – and it aligns with our focus on managing third-party data breaches and continuous monitoring across vendor ecosystems.

Ready to strengthen third-party oversight without slowing down the business? Book a personalized demo with Panorays.

Workday Data Breach FAQs