Understanding the Breach
Between March and August 2025, attackers compromised Salesloft's GitHub account, stole OAuth authentication tokens from its Drift AI chat platform, and used those tokens to access Salesforce environments across more than 700 organizations. The victims included Workday, Google, Palo Alto Networks, Zscaler, and Cloudflare. The breach didn't exploit a software vulnerability in Workday or Salesforce but rather a weaker link: a Business Associate integration with insufficient access controls.
For Covered Entities and Business Associates, the technical pathway matters less than the compliance gap it exposes. If Salesloft or Salesforce had been processing PHI in your environment, this attack vector would have triggered Breach Notification Rule obligations, Common Agency Provision liability, and OCR scrutiny of your vendor oversight program.
Key Findings
1. Your Business Associate Agreement doesn't protect you from your Business Associate's Business Associates.
Workday's investigation confirmed that attackers stole business contact information, support case details, tenant names, product names, training records, and event logs. No core customer data or attachments were accessed. The attack succeeded because Salesloft, a customer engagement vendor integrated into Salesforce, became the entry point. If your EHR vendor uses a chat platform that gets compromised, your BAA with the EHR vendor won't stop the breach. You need BAA provisions that require your vendors to impose the same security obligations on their subcontractors and to notify you of all third-party integrations that touch your data.
2. OAuth tokens are skeleton keys, and most organizations don't inventory who holds them.
The attackers stole OAuth tokens, which grant applications permission to access other systems without re-entering credentials. These tokens are designed for convenience, but they bypass traditional authentication controls. Between August 8 and August 18, 2025, the stolen tokens gave attackers direct access to Salesforce data across hundreds of organizations. Workday didn't learn of the breach until August 23. If you're using Salesforce, Workday, or any platform that grants OAuth access to third-party apps, you need a quarterly audit of every connected application and the permissions each one holds.
3. Social engineering remains the most reliable attack vector.
The breach began with voice phishing calls targeting employees at Salesloft's English-speaking offices. Attackers impersonated IT or HR staff and convinced employees to authorize a malicious application. This wasn't a zero-day exploit. It was a phone call. Your HIPAA Security Rule risk assessment must evaluate workforce training on vishing, your protocol for verifying access requests, and whether your employees know they're allowed to hang up and call back through a verified channel.
4. The attackers weren't after the data you think.
From Workday's environment, they harvested credentials: AWS access keys and Snowflake tokens that could be used to launch further attacks. They weren't exfiltrating patient records or billing data. They were building a toolkit for the next stage of the campaign. This is a supply-chain attack, not an endpoint. If your risk assessment treats vendor breaches as isolated incidents rather than as stepping stones to deeper compromise, you're underestimating the threat.
5. Discovery timelines reveal the gap between incident and notification.
Salesloft began revoking compromised access on August 20. Workday learned of the breach on August 23. The attack ran from August 8 to August 18. That's a 12-day window during which attackers had active access before detection. Under the Breach Notification Rule, you have 60 days to notify affected individuals once you discover a breach of unsecured PHI. But "discovery" starts when you know or should have known. If your vendor doesn't notify you until weeks after an incident, your notification clock is already running.
What This Means for Your Team
You don't control your vendors' security posture, but you own the consequences when they fail. The Common Agency Provision (45 CFR § 160.402) holds you liable for your Business Associates' HIPAA violations. If this breach had involved PHI, OCR wouldn't accept "we trusted our vendor" as a defense. They'd ask whether your BAA required the vendor to secure third-party integrations, whether you audited the vendor's subcontractor agreements, and whether your risk assessment identified OAuth tokens as a potential vulnerability.
The practical implication: your vendor management program must function as an extension of your own security controls. You need contractual rights to audit, technical visibility into integrations, and a process for evaluating vendor incidents before they become reportable breaches.
Action Items by Priority
Immediate (this quarter):
- Inventory every third-party application integrated into your core systems (EHR, CRM, billing platform). Document the OAuth permissions each application holds and revoke access for any app that hasn't been used in 90 days.
- Review your standard BAA template. Confirm it requires vendors to (1) enter BAAs with their subcontractors, (2) notify you of all third-party integrations that process or access your data, and (3) report security incidents within 24 hours of discovery.
- Audit your current vendors' breach notification clauses. If the timeline exceeds 24 hours or the clause is vague about what constitutes a "reportable incident," renegotiate.
Short-term (next 6 months):
- Implement a quarterly access review process. For each vendor, list every subcontractor, integration, and third-party tool that touches your data. Require vendors to attest that each subcontractor has signed a BAA.
- Update your workforce training to include vishing scenarios. Role-play a call where someone claiming to be from IT asks an employee to authorize an application or share credentials. Establish a verification protocol: hang up, look up the vendor's support number independently, and call back.
- Add a vendor incident response clause to your BAAs. Specify that if a vendor experiences a security incident affecting your data, they must provide forensic findings, a timeline of unauthorized access, and a list of all data elements potentially compromised.
Long-term (next 12 months):
- Conduct a supply-chain risk assessment as part of your annual HIPAA Security Rule review. Map every vendor relationship, identify which vendors have subcontractors, and evaluate whether those subcontractors meet the same security standards you require.
- Implement technical controls for high-risk integrations. Restrict vendor access to named IP ranges. Require multi-factor authentication for any vendor login. Configure alerts for logins from unexpected geographic locations.
- Build a vendor scorecard. Rate each vendor on security posture, incident response capability, and compliance with your BAA terms. Use the scorecard to prioritize audits and to decide whether to renew contracts.
