A wave of attacks has put Salesforce Connected Apps in the spotlight - here’s what’s changing.
Salesforce takes security seriously, continually investing in research, development, and acquisitions to strengthen data protection. But the cybersecurity landscape never stands still. Malicious actors are constantly evolving their tactics, targeting weaknesses in technology, processes, and people, all with the goal of gaining access to customer environments.
In recent weeks, a threat group tracked as UNC6040/UNC6240 (also known as ShinyHunters) has targeted and successfully compromised several high-profile Salesforce customers, including Adidas, Google, Qantas, Allianz Life, and more. Their entry point? Malicious use of Connected Apps. Once inside, the group exfiltrated sensitive data before moving to extortion.
Salesforce is responding swiftly, hardening Connected App security and moving quickly to close off one of the key attack vectors exploited in these incidents. This post explains what’s changing, why it matters, and the steps you need to take to prepare.
🔍 Background: What’s Changed?
A connected app integrates an application with Salesforce using APIs. Connected apps use standard SAML and OAuth protocols to authenticate, provide single sign-on, and provide tokens for use with Salesforce APIs. In addition to standard OAuth capabilities, connected apps allow Salesforce admins to set various security policies and have explicit control over who can use the corresponding apps.
Salesforce is an API-first platform. Its flexibility and ability to integrate with other solutions is one of its greatest strengths, empowering businesses to connect data across systems. But that power comes with responsibility, and care is needed to ensure the integrations do not become weak points.
Connected Apps have long been a key part of Salesforce’s integration landscape. They provide a framework for external applications to access Salesforce efficiently and securely, using standards such as SAML and OAuth. Their flexibility makes them invaluable – powering a variety of third-party and Salesforce owned integrations, such as Salesforce’s Data Loader.
The challenge is where threat actors, such as ShinyHunters, exploit Connected Apps to gain access. In their recent attacks, they were able to use Connected Apps as an entry point by tricking users. Depending on security settings, this can result in a significant risk of data exposure.
These incidents have brought the risks of Connected Apps into the spotlight; requiring swift action from Salesforce and customers to tighten security.
🤝Shared Responsibility
Salesforce follows the Shared Responsibility Model for security and compliance. The UK’s National Cyber Security Centre (NCSC) defines this as:
Security and availability … [are a joint responsibility] … that is shared between the cloud provider, and the customer of that service. The amount of responsibility that each party must own will depend on the type of service, and how the service provider has chosen to implement it
Before we explore what’s changing, it’s crucial to recognise that security is a team sport. Salesforce, as a cloud service provider, invests heavily in platform security and provides powerful tools. But customers also play a key role. Each org’s security teams, admins, and developers must apply the right controls – such as IP restrictions, access levels, and the principle of least privilege. At the same time, end users must be aware of threats like phishing and vishing and know how to respond.
As Google’s threat analysis into the recent attacks highlights:
In all observed cases, attackers relied on manipulating end users, not exploiting any vulnerability inherit to Salesforce
Recent breaches were not caused by flaws in the Salesforce platform. Connected Apps themselves are secure. The weakness arose by attackers using social engineering techniques to trick users into approving malicious apps; particularly via the OAuth 2.0 Device Flow.
The good news: both Salesforce and customers have controls available to mitigate the risk.
✅ Connected Apps: User-Authorised vs Admin-Authorised
Before we look at Salesforce’s response, it’s important to understand the difference between user-authorised (not reviewed by an admin) and admin-authorised (installed) Connected Apps.
| Type | Definition | Risk Level | Example |
|---|---|---|---|
| User-Authorised (uninstalled connected apps) | User authorised connection without admin approval or visibility. | Elevated – minimal admin visibility, broader token scopes, and limited policy enforcement. | An unvetted third-party integration, e.g. a malicious ‘fake’ Data Loader. |
| Installed (Admin-Authorised) | Admin authorised and ‘installed’ connection with policies configured. | Lower – apps vetted, and explicit access controls and policies can be applied. | An official Salesforce product, e.g. the standard Data Loader app. |
While any integration can introduce risk, ensuring your internal team vets and approves a Connected App, and explicitly determines who can use it, significantly reduces exposure.
⏭ Salesforce’s Response: What’s Next?
Salesforce is introducing changes to strengthen Connected App security. These measures will roll out in new orgs from 28 August 2025, with a phased rollout to existing orgs beginning 2 September 2025 (expected to last around two weeks).
| Change | Considerations |
|---|---|
| Restricting usage of uninstalled connected apps |
|
| Restricting usage of uninstalled apps using OAuth 2.0 device flow |
|
| Data Loader |
|
By introducing these measures, Salesforce is aiming to close off common attack vectors, while minimising disruption.
⚠ – To avoid disruption, each org must act before the rollout begins.
🚀 What do you need to do?
With Salesforce tightening Connected App security, every org must prepare ahead of the rollout. Follow these five steps to minimise the risk of disruption and strengthen your defences:
1. Audit
Review existing user-authorised apps.
- Check usage data (first/last use, who’s using it, number of logins, etc).
- Confirm if the app is known/trusted.
- Look for anomalies (e.g. unusually high traffic associated with the app).
The goal is to determine whether to keep or block the app. This step also ensures you know who may be impacted if access is revoked. Detailed instructions here.
2. Act
Either block the connection or install the app:
- If installing, configure settings and policies (e.g. OAuth scopes, session settings, access policies, etc).
- If blocking, current and future sessions are disabled.
More detailed information is available here.
3. Data Loader Changes
Review who currently uses Data Loader.
- A new Data Loader version will be available before the 2nd of September 2025. Ensure all users download the latest version.
- After the 2nd of September, OAuth 2.0 Device Flow will be disabled. Users must use either Password Authentication (username, password and security token if required) or OAuth 2.0 User-Agent Flow.
- Communicate these changes early to prevent disruption and apply the Principle of Least Privilege to ensure only team members who really need access have it.
More detailed information on the Data Loader changes is available here.
4. Educate Users
Prepare users for potential error messages when attempting to set up a Connected App without approval. Given the rise in attacks, reinforce phishing/vishing awareness – attackers rely on tricking users into granting access.
5. Governance
Ensure governance processes are aligned for the upcoming changes. For example:
- Who (if anyone) should be granted the ‘Approve Uninstalled Connected Apps’ permission. This is available on the standard System Administrator Profile by default. Access beyond this should be kept to a minimum.
- Define how users can request access to Connected Apps in future.
- Ensure clear ownership of Connected Apps and engage security teams to align policies (i.e. determining who should have access, and appropriate policies for each Connected App).
Collectively, these five steps will help prepare your org for the changes and reduce risk exposure.
💰 Bonus: What else can be done?
There’s always more you can do to harden your security posture. The following are not exhaustive, but each helps to safeguard your environment:
- Review API Enabled access. Minimise access to the API Enabled permission.
- Enable API Access Control. Additional access controls can be enabled by contacting Support. This feature provides greater control over API access.
- Audit Installed Connected Apps. Check OAuth scope, permitted users, IP restrictions and refresh token policies. Keep as restricted as possible.
- Enforce Multi-Factor Authentication. Enforce Multi-Factor Authentication where appropriate to add additional barriers for attackers.
- Apply the Principle of Least Privilege. Only give users the minimum level of access needed to complete their work.
- Restrict access by IP ranges. Define your Trusted IP Ranges (to challenge) and use Profiles to restrict login IP ranges (to block) requests outside of the range.
- Tighten Session Settings. Pay attention to Session Settings. Consider locking sessions to the IP address they originated or enforcing login IP ranges on every request.
- Explore Salesforce Shield. Salesforce Shield provides add-ons such as event monitoring, threat detection and transaction security policies. These monitor, track and act when unusual activity is detected (e.g. block actions or alert).
- Add Security Contacts. Premier Success and Signature Support customers can add Security Contacts to ensure they are notified if an incident is detected.
- Explore External Client Apps. These are the next generation of Connected App. They provide enhanced security and improved packaging. Where possible, explore External Client Apps instead of Connected Apps moving forward.
Remember, security is not a one-off task and one-size does not fit all. Review what suits your org and build security checks into your processes to help keep your org safe.
Summary
Connected Apps are powerful and secure, but without training and proper controls, they can become an attack vector. Recent breaches at high-profile companies show how attackers can use phishing and vishing to trick users into approving malicious apps, giving them access to Salesforce orgs.
Security is a shared responsibility. Salesforce is introducing new safeguards – restricting user-authorised apps and removing OAuth 2.0 Device Flow from Data Loader. But it’s up to Salesforce teams to apply these controls effectively.
This post has outlined five key steps to prepare: audit usage, act on findings (install or block), prepare for Data Loader changes, educate users and realign governance.
Salesforce’s changes begin on 28 August 2025 (new orgs) and 2 September 2025 (existing orgs, phased over ~2 weeks).
By acting now, you’ll minimise disruption and make your org a harder target.
Found this useful? Share it with your security and Salesforce teams.
Want more deep-dives and insights? Be sure to follow SFDC Penguin on LinkedIn and X.
Until next time, thanks for reading 
Bonus Penguin Fact 🐧
Penguins worry more about fishing than phishing – but security matters for them too. In Antarctica, emperor penguin chicks form crèches for safety, but sometimes rely on unlikely guardians. Check out this video!
Want More?
Found this article useful? Why not share!
Or check out some of our other articles: