What the Salesforce Breaches Teach Us About Shared Accountability

2025 hasn’t been a good year for Salesforce clients. A shady criminal group mounted a series of attacks on its customers, ultimately affecting organisations ranging from tech giants like Google and Cisco to luxury brands including Chanel and Louis Vuitton. Even critical infrastructure providers such as Qantas Airways, FedEx, and TransUnion have been nobbled by the attackers, called either Scattered LAPSUS$ Hunters, ShinyHunters, or variations thereof. The group, which seems to be a coalition of members from various other criminal gangs, has reportedly compromised over 760 organisations and roughly 1.5 billion records.

But Salesforce says that this isn’t a problem of its own making. How did an attack become the biggest source of data theft in 2025, without the vendor admitting any responsibility?

It’s easy to understand why Salesforce refused to carry the can for this one. The attackers don’t appear to have exploited any vulnerabilities in the vendor’s online platform.

Instead, the attackers got into the Salesforce systems via flaws in customer security, such as inadequate OAuth governance, missing MFA enforcement, poor integration vetting, and social engineering susceptibility.

A typical method for gaining access was to create a fake version of the Salesforce Data Loader app, which customers use to download their Salesforce data.

The Scattered LAPSUS$ crew used this fake software to send a device code to Salesforce’s servers, which is supposed to be entered by a Salesforce user. Then, one of the gang would call the victim and pretend to be from their company’s helpdesk. They’d ask the victim to log into Salesforce and enter the device code, unwittingly confirming the fake app (which they know nothing about) as legit. Then, the criminals get access to the victim company’s sensitive Salesforce data.

These failures in customer security aren’t anomalies. Gartner predicts that 99% of cloud security failures through 2025 will be the customer’s fault. Recent research from AppOmni also shows that 70% of SaaS incidents stem from a mixture of customer-controlled permission issues and misconfigurations.

Understanding the Shared Responsibility Model

The worry here is that customers for vendor software might be lulled into a false sense of security by relying on the vendor’s platform alone, especially when that software is hosted in the cloud. But in reality, vendor platform security doesn’t automatically equal data security.

The cloud industry even has a name for this: shared responsibility. It’s a mutual understanding of where the service provider/software host’s responsibility ends, and the customer’s begins. Many enterprises don’t seem to understand this; 53% of AppOmni respondents describing themselves as confident in security do so based on the strength of their vendors’ controls. As evidenced by the Salesforce attacks, even those that do get it often aren’t handling security well enough on their side of that line.

For Salesforce and SaaS platforms, the vendor typically covers secure platform infrastructure, core application code, availability guarantees, and built-in security features like MFA capabilities and encryption. That leaves customers responsible for measures such as managing user accounts, enforcing MFA and managing OAuth tokens, implementing least privilege access, handling third-party integrations, and configuring security settings appropriately.

It’s also up to users to train staff on security threats. Given the social engineering involved in these attacks, that seems to have been a weak point. However, even if attackers do manage to fool users, there should be an element of monitoring user activity and detecting anomalies.

How Compliance Frameworks Can Help Prevent These Breaches

These are weaknesses that ISO 27001:2022, SOC 2, and NIS 2 explicitly address through access control, supplier oversight, and configuration management requirements. Companies should look to these operating standards to improve their stance and avoiding becoming another in a list of pwned brands.

For example, the access control series A.5.15 requires establishing documented access control policies by implementing need-to-know and need-to-use principles. A.5.16 handles identity management, while A.5.17 explores the management of authentication information, requiring secure storage and transmission, encryption at rest and in transit, and regular rotation.

A.5.18 covers access rights. It requires formal processes for provisioning, modifying, and revoking access rights, with authorisation from asset owners, and regular reviews at least annually. Compliance managers could also look at A.8.2, governing privileged access rights.

These controls require centralised registries, regular audits, and validation of legitimacy before granting access. Those are precisely the measures that would have prevented social engineering victims from authorising malicious apps.

This isn’t the first time we’ve seen companies suffer from breaches because of their own configuration choices (or ignorance of such choices). The string of breaches affecting Snowflake customers in 2024 springs to mind, stemming as it did from stolen credentials and a lack of MFA (even though Snowflake offered MFA). As companies rely increasingly on SaaS and put their most sensitive data into these infrastructures, the onus is on them to ensure they guard their own digital gates to these systems properly.