Topic starter
23/06/2026 7:22 pm
TL;DR: Unosecur says recent Salesforce intrusions against organisations including Google, Workday and Adidas relied on vishing, malicious connected apps, and modified Data Loader tools rather than any platform flaw. Shared responsibility fails when social engineering turns user consent into durable access that governance never revalidates.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “Salesforce Breach 2025: What Happened and How to Stop It”.
Key questions
Q: What breaks when users can approve Salesforce connected apps without review?
A: The governance boundary breaks first.
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.
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.
Practitioner guidance
- Tighten connected-app approval controls Require secondary review for new Salesforce OAuth grants, especially where apps request broad read access or offline access.
- Add help-desk verification for support requests Treat any request to install a data tool or authorise an app as a high-risk event.
- 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.
Bottom line: The Salesforce breach wave was enabled by social engineering and malicious app authorisations, not by a disclosed flaw in the platform itself.
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
👉 Read Unosecur's analysis of the Salesforce breach wave and shared responsibility failures →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 3:20 am
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.
A question worth separating out:
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.
👉 Read our full editorial: Salesforce breach 2025 shows where shared responsibility fails