Salesforce breach 2025 shows where shared responsibility fails

At a glance

What this is: This analysis argues that the 2025 Salesforce breach wave was driven by social engineering and abused app authorisations, not a Salesforce software vulnerability.

Why it matters: It matters because IAM teams must govern connected apps, OAuth consent, and identity behaviour inside SaaS platforms, not assume the provider owns the full control surface.

👉 Read Unosecur's analysis of the Salesforce breach wave and shared responsibility failures

Context

The core problem is a governance gap, not a software defect. In these Salesforce-linked incidents, attackers used voice phishing and impersonation to get employees to authorise malicious connected apps or install fraudulent Data Loader software, which converted a human trust decision into application access.

That pattern exposes a shared responsibility blind spot in SaaS environments. The platform can be sound while the customer still leaves app authorisation, entitlement scope, and user verification insufficiently controlled across CRM workflows and downstream integrations.

Key questions

Q: What breaks when users can approve Salesforce connected apps without review?

A: The governance boundary breaks first. A malicious OAuth grant can look like normal business authorisation while actually creating durable access into CRM data, downstream APIs, and other cloud services. That is why connected-app approvals need the same scrutiny as privileged account changes, not the same treatment as ordinary productivity consent.

Q: Why do Salesforce connected apps and vishing create such high breach risk?

A: Because the attacker does not need to defeat the platform if they can persuade a legitimate user to grant access. Vishing turns a trust relationship into authorisation, and that authorised path can outlive the moment of deception. The risk grows when scopes are broad and app review is weak.

Q: How do security teams know when a connected-app approval is going wrong?

A: Watch for new app grants followed by unusual exports, access to unfamiliar records, or login and API activity from atypical locations. Those are signs that consent has been converted into attacker-controlled access. The most useful signal is not the grant itself, but the behaviour that follows it.

Q: What should teams do if a Salesforce app approval has already been abused?

A: Revoke the app grant, invalidate related sessions and tokens, and inspect adjacent cloud services that may share trust with the compromised identity path. Then review what data was accessed and whether the same authorisation pattern exists elsewhere. Containment has to reach beyond Salesforce if lateral movement has started.

Technical breakdown

How malicious connected apps turn consent into access

Salesforce connected apps are an OAuth-based integration path, so once a user authorises a malicious app, the attacker can inherit access that looks legitimate to the platform. The risk is not a code exploit in the SaaS core, but abuse of delegated trust and over-broad scopes. If the app can read CRM records or call APIs, the attacker can automate collection at scale after a single successful consent event. In practice, the control boundary is the authorisation event, not the login screen.

Practical implication: govern connected-app consent as a privileged access event and review scope assignments before users can approve them.

Why vishing succeeds against SaaS identity controls

Voice phishing works because identity controls often assume the user is the right party when a session is active. Attackers impersonate IT support, create urgency, and move the victim toward an authorisation action that appears routine. This bypasses many technical checks because the compromised step is behavioural, not cryptographic. Once the user installs a modified tool or approves the OAuth request, the attacker is operating through a valid identity path with attacker-chosen intent.

Practical implication: pair identity controls with help-desk verification and user education that specifically addresses consent-based abuse.

How lateral movement follows initial CRM access

The article says some intrusions extended beyond Salesforce into other cloud services and extortion attempts. That means the first access event was only the start of a broader identity chain, likely involving tokens, linked applications, or reused trust relationships across SaaS platforms. When CRM data is exposed, it can seed further targeting, credential abuse, and pressure campaigns. The technical lesson is that delegated SaaS access can become a pivot into adjacent business systems if scope and telemetry are weak.

Practical implication: monitor downstream integrations and revoke high-risk app paths before stolen CRM access turns into cross-cloud movement.

Threat narrative

Attacker objective: The attacker objective was to obtain Salesforce data through trusted app and user pathways, then use that access for follow-on extortion or broader cloud compromise.

1. Entry occurred through vishing and impersonation of IT support, which persuaded employees to install a modified Data Loader tool or authorise a malicious connected app.
2. Credential or token-like access was then obtained through OAuth consent or fraudulent app installation, giving the attacker a legitimate-looking path into Salesforce data.
3. Escalation followed when the attacker used that access to steal CRM records and, in some cases, pivot into other cloud services.
4. Impact included data theft and extortion attempts that leveraged the stolen information against the affected organisations.

Breaches seen in the wild

• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shared responsibility fails when authorisation is treated as routine user behaviour: This breach wave shows that SaaS governance cannot stop at platform security statements. When a user can be convinced to approve a malicious connected app, the control failure sits at the identity governance layer, not in the application stack. Practitioners should treat app consent as a security decision with blast-radius consequences, not as a normal productivity step.

Connected app trust is a privileged access problem, not an integration convenience: OAuth consent can create durable access that survives the moment of deception. That means app onboarding, scope review, and third-party verification belong in the same governance model that handles elevated human or machine access. IAM teams that separate integrations from privilege management leave a gap attackers can exploit with social engineering.

Identity timelines matter more than point-in-time authentication: The article’s lateral movement detail shows that the first compromise was not the end state. Once Salesforce access existed, attackers could leverage linked services and stolen data to widen impact. The named concept here is consent-driven blast radius: one deceptive approval can expose multiple cloud systems if connected apps and downstream entitlements are not continuously constrained.

Voice phishing is an identity control failure, not only a user-awareness problem: The article shows that attackers targeted employees through believable support impersonation because the organisation’s controls allowed human trust to override identity proof. Training alone is insufficient when the approval path itself is too permissive. The practical conclusion is that governance must narrow what a user can authorise without secondary verification.

Machine and service identities can become the second-stage payload: The article notes misuse of API keys, bots, and other non-human identities in highly integrated environments. That is a sign that once one trusted path is compromised, adjacent automation can amplify the breach. IAM and NHI governance need to be joined at the integration layer, because the attacker does not respect organisational boundaries between people, apps, and workloads.

What this signals

Consent-driven blast radius: This breach pattern shows that one deceptive approval can expand from CRM access into adjacent cloud services if connected apps are not governed as privileged pathways. The reader’s programme should therefore treat OAuth consent, support-led approvals, and downstream integration scope as one control surface, not three separate ones.

A SaaS provider’s security posture does not eliminate the customer’s obligation to control app authorisation, user verification, and entitlement scope. For IAM and NHI teams, the practical shift is to assume that trust can be weaponised at the approval layer long before any technical anomaly appears.

For practitioners

• Tighten connected-app approval controls Require secondary review for new Salesforce OAuth grants, especially where apps request broad read access or offline access. Block unverified apps until their publisher, scope, and business justification are validated.
• Add help-desk verification for support requests Treat any request to install a data tool or authorise an app as a high-risk event. Force out-of-band verification before a support-driven change can proceed.
• Continuously review delegated SaaS scopes Track which connected apps can reach CRM data, other cloud services, or sensitive APIs, and revoke access when the business need disappears or the scope is wider than intended.
• Detect abnormal identity behaviour after consent Alert on new authorisations followed by unusual export volume, unfamiliar IPs, or access to adjacent SaaS systems so containment can begin before lateral movement completes.
• Separate production support from user self-service Restrict who can approve security-sensitive changes in Salesforce and require privileged workflows for app installation, token issuance, and integration changes.

Key takeaways

• The Salesforce breach wave was enabled by social engineering and malicious app authorisations, not by a disclosed flaw in the platform itself.
• The reported impact extended beyond CRM data theft in some cases and included lateral movement into other cloud services and extortion attempts.
• The control gap was shared responsibility without tight governance over connected apps, OAuth consent, and support-driven access changes.

Key terms

• Connected App: A connected app is a third-party integration that is granted access to a SaaS platform through APIs and OAuth permissions. From a governance perspective, it is an identity-bearing access path that needs ownership, scoping, and periodic review like any other non-human identity.
• Consent-driven access: A control model where a machine or partner may access data only within an explicit approved scope. In banking APIs, this replaces credential replay with auditable permissions that can be revoked, reviewed, and limited to the exact data and actions required.
• Shared Responsibility Model: A shared responsibility model divides security duties between the cloud provider and the customer. For NHI governance, the provider supplies the platform controls, but the organisation still owns configuration, privilege review, secret handling, monitoring, and lifecycle management of its identities.
• Voice Phishing: Voice phishing is social engineering conducted by phone, usually by impersonating support, IT, or another trusted function to extract credentials or approvals. In identity governance, it is dangerous because it targets the human decision step that can create valid access without technical exploitation.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• Specific prevention ideas for Salesforce connected-app abuse and malicious OAuth approvals
• The vendor's description of how its identity fabric and native Salesforce connectors would detect abuse at runtime
• A fuller breakdown of the mitigations it associates with ITDR, entitlement drift, and non-human identity governance
• The article's own FAQs on responsibility, attack methods, and governance considerations

👉 The full Unosecur blog covers the breach methods, control gaps, and identity governance implications in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.