Salesforce breach 2025 shows where shared responsibility fails

At a glance

What this is: This is an analysis of the 2025 Salesforce breach wave, showing how voice phishing, malicious connected apps, and over-scoped access enabled data theft and lateral movement.

Why it matters: It matters because Salesforce, SaaS, and cloud-integrated environments depend on identity controls that must constrain both human decisions and non-human access paths.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Unosecur's analysis of the 2025 Salesforce breach wave

Context

Salesforce breach 2025 is a shared responsibility problem, not a platform defect. In the incident wave described by the source article, attackers used voice phishing to persuade employees to authorise malicious connected apps or install altered Data Loader tooling, then used that foothold to pull data from Salesforce environments and, in some cases, move into adjacent cloud services.

For IAM teams, the lesson is that a trusted SaaS platform can still become the stage for identity abuse when app authorisation, OAuth scope, and user training are treated as separate controls. The practical question is not whether the platform was compromised, but whether the organisation can detect and contain fraudulent access before data leaves the environment.

Key questions

Q: How should security teams govern connected apps in SaaS environments?

A: Treat connected apps as privileged identity extensions, not low-risk integrations. Require scope review, restrict who can authorise new apps, and monitor consent events for anomalies. The main control objective is to prevent a single fraudulent approval from becoming durable API access across multiple cloud services.

Q: Why do malicious OAuth apps create more risk than a simple phishing email?

A: A phishing email ends when the user ignores it, but a malicious OAuth app can create valid delegated access that survives after the initial trick. Once authorised, the attacker can use legitimate tokens and API permissions until the grant is revoked, which makes the compromise harder to spot and contain.

Q: What do organisations get wrong about SaaS breach prevention?

A: They often focus on the platform configuration and miss the approval path that gives attackers access in the first place. The common failure is separating user awareness, app governance, and identity telemetry, even though the breach only needs one bad consent event to succeed.

Q: Who is accountable when a malicious connected app is authorised by an employee?

A: The customer is accountable for governing who can approve apps, what scopes are allowed, and how risky integrations are reviewed. The platform may provide the controls, but the operating model determines whether a fraudulent authorisation becomes a breach or is blocked before access is granted.

Technical breakdown

How malicious connected apps bypass normal authorisation controls

Connected apps are trusted integrations that gain access through OAuth authorisation, not password compromise. When an employee approves a fraudulent app, the attacker inherits the app's granted scopes and can call SaaS APIs as that integration until the grant is revoked. The abuse path often looks legitimate in logs because it uses valid tokens, approved consent, and ordinary API activity. The governance failure is not encryption or perimeter defence, but over-broad consent and weak review of third-party app entitlements. In SaaS environments, this makes app governance a first-class identity control, not a procurement afterthought.

Practical implication: review and restrict connected app consent paths before they become durable attack credentials.

Why vishing works against identity controls

Vishing succeeds because identity controls often assume the human verifier will notice abnormal requests, but the attacker is manipulating the verifier itself. A fake support call can push an employee to approve a device, authorise an OAuth flow, or install a modified admin tool under the appearance of routine troubleshooting. Once the user supplies the final consent step, the resulting access is valid from the platform's perspective. This is why social engineering against identity systems is not just a training problem. It is a control-design problem where user intent, not platform weakness, becomes the weak link.

Practical implication: pair identity awareness training with verification and approval controls that do not rely on voice-only trust.

How lateral movement follows from over-scoped SaaS access

After initial access, attackers look for the widest possible API scopes and the most valuable adjacent identities. In SaaS-heavy environments, that often means pivoting from CRM data into email, storage, or other connected cloud services through shared tokens, delegated permissions, or reused admin roles. The technical risk is entitlement drift, where the access path granted for one business function becomes a broader route into the environment. Once lateral movement starts, the attacker can combine SaaS data with other cloud access to increase extortion leverage and operational impact.

Practical implication: map SaaS app permissions to adjacent cloud blast radius and revoke unused or over-scoped entitlements.

Threat narrative

Attacker objective: The objective is to turn user-granted SaaS access into data theft, cross-cloud reach, and ransom leverage.

1. Entry occurs through voice phishing, where attackers impersonate IT support to trick employees into authorising malicious connected apps or installing fraudulent Data Loader tooling.
2. Escalation follows when the malicious app receives valid OAuth scopes or other delegated permissions, giving the attacker normal-looking access to Salesforce data and related cloud integrations.
3. Impact comes from data theft, lateral movement into other corporate cloud services in some cases, and extortion attempts using the stolen information.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shared responsibility only works when identity governance is continuous, not episodic. The Salesforce breach wave shows that cloud platform security can be intact while customer-side identity controls fail at the point of consent. OAuth scopes, app approvals, and connected app review are the real control surface here, and they are often managed as one-time configuration rather than living governance. Practitioners should treat SaaS authorisation as an active security domain, not a static settings exercise.

Connected app abuse is a governance problem with a user-facing attack path. The attacker does not need to crack Salesforce if they can persuade a human to authorise a malicious integration. That means the programme gap sits between human decision-making and delegated machine access, where identity policy, support workflows, and approval telemetry should intersect. Security teams that separate user training from integration governance are leaving the breach path intact.

Identity blast radius is the right named concept for this breach pattern. A single fraudulent consent can expand from one CRM workflow into downstream cloud services, data stores, and extortion leverage. The issue is not just that access was granted, but that the granted access connected multiple systems in a chain the user never intended. The implication is that blast-radius measurement must include SaaS integrations, not only core accounts and endpoints.

Customer-managed SaaS access remains a failure domain even when the vendor platform is secure. The article correctly frames Salesforce as not at fault for the compromise mechanics, but that should not be confused with low organisational responsibility. This is the same governance lesson seen in other cloud incidents: authentication, authorisation, and integration review are only as strong as the customer operating model behind them. Teams should re-evaluate who owns connected app risk end to end.

Identity telemetry needs to catch consent events, not just login events. Login monitoring alone will miss the moment an attacker turns a legitimate session into delegated access. The stronger control signal is the authorisation event itself, especially when an app is new, unverified, unusually scoped, or tied to support impersonation. Practitioners should align detection to approval behaviour, because that is where the attack becomes durable.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• More than 1 in 5 non-human identities are believed to be insufficiently secured across the average organisation, according to The 2024 ESG Report: Managing Non-Human Identities.
• For the wider breach pattern context, see 52 NHI Breaches Analysis for how compromised identities turn into repeat incidents and broader organisational exposure.

What this signals

Identity blast radius: This breach pattern shows why SaaS governance has to measure how far a single app consent can travel across cloud services and data stores. When connected apps can move from CRM access into adjacent systems, the programme has already lost containment before exfiltration begins. Practitioners should treat integration scope as a blast-radius metric, not just an administration detail.

The scale of the NHI problem gives context to why identity compromise remains so persistent. With 72% of organisations saying they have experienced or suspect a breach of non-human identities, the control gap is no longer limited to service accounts and API keys, because delegated access paths are now part of the same attack surface.

The next programme step is to align SaaS consent governance with identity lifecycle controls and entitlement review. Teams that already use 52 NHI Breaches Analysis to understand breach patterns should extend the same thinking to connected apps, support workflows, and cross-cloud trust chains.

For practitioners

• Tighten connected app approval governance Require security review for new OAuth applications, constrain high-risk scopes, and block self-approval for sensitive integrations. Treat any app that can read CRM data or call adjacent cloud APIs as privileged access, not a convenience feature.
• Validate support workflows against voice phishing Create out-of-band verification for any request to install tooling, approve access, or change integration settings. Support teams should never rely on phone-only identity claims when the outcome is delegated access.
• Instrument authorisation events for anomaly detection Alert on new connected apps, unusual OAuth grants, unexpected admin tool installation, and scope changes that increase data access. Prioritise telemetry that shows when access is being created rather than only when it is used.
• Map SaaS integrations to downstream blast radius Identify which connected apps can reach email, storage, and other cloud services, then remove unused trust paths and excessive scopes. A compromised CRM integration should not become a route into the rest of the environment.

Key takeaways

• The Salesforce breach wave was enabled by social engineering that turned user consent into delegated access, not by a platform vulnerability.
• The impact extended beyond CRM data in some cases, showing that one fraudulent authorisation can expand an organisation's identity blast radius quickly.
• Security teams need tighter connected app governance, stronger consent controls, and detection that triggers on authorisation events, not only on logins.

Key terms

• Connected App: A connected app is a third-party or custom integration that is granted access to a SaaS platform through delegated authorisation. In identity terms, it becomes a non-human access path that can read data, call APIs, and persist until the grant is reviewed or revoked.
• OAuth Scope: An OAuth scope defines what a token or connected application is allowed to do after authorisation. In practice, scope is the boundary between a narrow integration and a broad compromise, so governance must treat scope as a security policy, not just a developer setting.
• Identity Blast Radius: Identity blast radius is the amount of system, data, and service exposure that follows from a single identity compromise or delegated approval. It captures how far a malicious token, app, or account can move across connected environments before containment succeeds.
• 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:

• Step-by-step guidance for detecting malicious Salesforce connected apps and suspicious consent events.
• Operational examples of identity threat detection and response for SaaS environments.
• More detail on limiting privilege drift across Salesforce integrations and adjacent cloud services.
• Practical framing for audit-ready reporting after a SaaS identity incident.

👉 Unosecur's full post covers the attack chain, connected app abuse, and response guidance for Salesforce environments.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.