As we move into 2026, Salesforce has never been more central to how organizations run their businesses—or more attractive as a target. The platform holds customer data, revenue data, operational workflows, and in many cases the connective tissue between dozens (or hundreds) of other systems. Over the last two years, we’ve seen a steady escalation in security incidents tied not to Salesforce itself, but to what’s built around it: connected apps, third-party packages, custom code, and OAuth-based integrations.
This is the uncomfortable truth many teams are now grappling with: Salesforce secures the platform, but you are responsible for securing everything that’s added to it. And by 2026, the surface area of that responsibility has expanded dramatically.
This article draws from a recent Hubbl webinar on Salesforce connected app security, informed by ecosystem benchmarks and real-world incidents, to unpack the biggest security challenges Salesforce customers face today—and what practical, non-alarmist steps teams can take to reduce risk.
A useful place to start is clarifying what Salesforce does and does not secure. Salesforce is extremely good at securing the core platform: infrastructure, availability, and baseline application security. But the moment you customize Salesforce—by installing packages, writing Apex, or connecting external applications—you’ve crossed into shared responsibility territory.
Modern Salesforce orgs are deeply customized. The average org contains tens of thousands of metadata components, and more than 90% of customers have at least one AppExchange package installed. Many have dozens. Each of those components represents functionality—but also potential risk if it’s not understood, monitored, and maintained.
Two areas consistently rise to the top in security conversations:
Both are powerful. Both are easy to underestimate.
The AppExchange is one of Salesforce’s greatest strengths. It allows customers to move fast by leveraging functionality that others have already built. AppExchange-listed packages go through Salesforce’s security review process, which is a critical baseline.
But not all packages are created equal.
Beyond AppExchange listings, many orgs contain:
Private packages, in particular, often bypass Salesforce’s formal security review. Salesforce is explicit about this: customers are responsible for reviewing these applications themselves.
What we consistently see across orgs is not malicious intent—but drift. Packages installed years ago by people who no longer work at the company. Packages that haven’t been updated even though newer versions exist. Packages that include automations or API logic that no one remembers touching.
From a security standpoint, outdated packages are a real problem. Vulnerabilities get fixed in newer versions. Permissions models evolve. Platform changes introduce new risks for old assumptions. Yet in practice, most orgs have multiple packages that are both out of date and poorly understood.
The challenge isn’t awareness—it’s scale. Manually auditing 20 or 30 packages across thousands of metadata components simply doesn’t work as a recurring process.
If installed packages represent known, internal risk, connected apps represent something more subtle—and often more dangerous.
Connected apps are external applications that authenticate to Salesforce using standard protocols like OAuth, SAML, or OpenID Connect. They don’t run on Salesforce infrastructure, but they can read from and write to Salesforce data via APIs.
Some examples are obvious:
Others are less visible:
Here’s the key point: end users can often authorize these apps without any administrator involvement.
When a user authorizes a connected app, they aren’t handing over their password—but they are granting scopes that allow the app to act on their behalf. That access persists even when the user isn’t actively using the app.
This is where OAuth-based attacks and social engineering come into play. Attackers don’t need to break Salesforce security; they just need a user to approve the wrong app with overly broad permissions.
When we look across Salesforce orgs at scale, a few patterns show up consistently:
Every one of these scenarios increases attack surface without delivering business value.
The most common reaction to these findings is surprise. Teams assume someone else is monitoring this. In reality, Salesforce provides the raw tools—but not the visibility or prioritization needed to manage connected app risk at scale.
We tackled the benchmarks fueling this data and how to solve these challenges in our latest Hubbl Signals Predictive Pulse:
As the video above shows, Salesforce does provide mechanisms to secure connected apps—but they’re opt-in, and they require deliberate configuration.
At a minimum, administrators should:
This last point is critical. OAuth permissions are bounded by the user who authorizes the app. If that user has excessive privileges, the app effectively inherits them.
This is why the principle of least privilege matters so much in a connected-app world. Permission sets aren’t just an identity-management best practice—they’re a security control.
Salesforce has also introduced newer permissions, such as approving uninstalled connected apps or allowing unrestricted API access. These permissions are powerful and should be assigned sparingly.
None of this is conceptually complicated. The difficulty lies in execution.
Security reviews don’t happen once—they need to happen continuously. New apps appear. New versions are released. Users change roles. Business requirements evolve.
For many teams—especially solo admins or lean platform teams—there simply isn’t enough time to manually track all of this. And when security competes with feature delivery, security usually loses.
This is the gap Hubbl was built to address.
At its core, Hubbl is about visibility and prioritization.
Rather than asking teams to manually comb through setup screens, Hubbl analyzes Salesforce org metadata and surfaces:
The goal isn’t to replace Salesforce’s controls—it’s to make them usable at scale.
By turning raw metadata into actionable insights, teams can focus their limited time on the issues that actually matter. Automated scans, prioritized recommendations, and historical tracking help turn security from a one-time audit into an ongoing practice.
Importantly, this isn’t about locking everything down. Real businesses need integrations. They need flexibility. The objective is informed control—knowing what exists, why it exists, and whether it still deserves access.
Salesforce will continue to innovate, and the ecosystem around it will only grow more complex. OAuth-based integrations aren’t going away. Neither are third-party packages.
In 2026, the organizations that succeed won’t be the ones that avoid customization—they’ll be the ones that understand and govern it effectively.
Security in Salesforce isn’t a single setting. It’s an operating model.
And the sooner teams treat it that way, the better prepared they’ll be for what comes next.
If you’re ready to improve your Salesforce security posture, we’re here to help. You can schedule a custom demo, or sign up for a free trial and scan your org today.
