This is shadow IT in its modern form. Not consumer apps on corporate laptops, but a quiet accumulation of third-party connections sitting inside your most sensitive business system, largely unmonitored, and in many cases entirely unknown to the security team.
How the attack surface grows
Salesforce is designed to connect. The AppExchange alone lists thousands of third-party applications, and most enterprise orgs run a significant number of integrations alongside it, including marketing platforms, data enrichment services, CPQ tools, customer success software, custom-built middleware, and more. Each connection is legitimate when it’s made. The problem is what happens next.
OAuth tokens – the credentials that allow third-party apps to access Salesforce on behalf of a user – don’t expire by default. They persist unless explicitly revoked. In a large org with high staff turnover and a long history of integration projects, the gap between ‘connected apps in use’ and ‘connected apps that exist’ can be substantial.
An integration authorized by a user with broad permissions carries that same access level regardless of whether the tool is still in active use, whether the vendor has since been acquired, or whether anyone in your organization still knows it exists.
Each dormant connection is a potential entry point. If a third-party vendor is compromised, every customer whose Salesforce org that vendor can access is exposed. The attack doesn’t need to target you directly. It only requires the targeting of the weakest point in your integration ecosystem.
“Almost every time we run a connected-app assessment, the biggest surprise isn’t a new vulnerability – it’s the sheer number of OAuth tokens nobody remembers granting. Integrations get built for a project, the project ends, and the token just keeps working. Visibility is the first real security win most teams get,” says Tapas Tripathi, Salesforce Architect at Cloud Protection for Salesforce.
Why security teams miss it
Traditional security monitoring isn’t built for this problem:
- Endpoint detection tools watch devices.
- Network monitoring watches traffic.
- SIEM platforms correlate events across infrastructure.
None of them have native visibility into what is authorized to access your Salesforce data at the application layer.
Within Salesforce itself, connected app management is an administrative function, not a security one. It falls to Salesforce admins to review what’s authorized, but without automated alerting or scheduled review processes this rarely happens proactively. The information exists inside the platform, but it isn’t surfaced in a way that makes risk visible. An admin would need to know to look for it, know where to look, and have the time to act on what they find.
The result is a class of risk that sits in a gap between security, IT, and Salesforce administration: owned by no one, reviewed by no one, and growing with every new integration that gets added.
The data exposure
The stakes are high because of what your Salesforce contains. A connected app with read access to your org can see your full customer list, pipeline, account history, and contact details. One with modify access can alter or delete records. The permission scope granted to third-party integrations is often broader than necessary – because it’s easier to grant wide access and move on than to carefully scope permissions at the point of integration.
When a third-party vendor suffers a breach, the question isn’t just what data they held on your behalf. It’s what their platform credentials could access in your systems. For organizations that haven’t audited their connected apps, the answer to that question is often uncomfortable.
“Supply chain risk isn’t just about the code you didn’t write – it’s about the access you didn’t revoke. A single over-permissioned connected app from a vendor you barely think about can be the difference between a contained incident and a full breach,” Tripathi concludes.
The takeaway
Getting visibility into your connected app landscape is the starting point. That means:
- A complete inventory of every application authorized to access your Salesforce org
- The permissions each holds
- The last time each was used
- Whether the user who authorized it is still with the organization
From there, you need a process: a regular review cycle that revokes access for dormant or decommissioned integrations, enforces least-privilege scoping for new connections, and ensures that offboarding a user also means reviewing the integrations they authorized.
The connected app problem is solvable. But it only gets solved once someone is responsible for both solving it and putting the right tooling in place to make the invisible visible.