It’s no secret that Salesforce security is currently struggling with a reputation problem. And it’s not because the platform is insecure – most organizations just don’t really know how to secure it properly.
Over the past year, we’ve seen a plethora of Salesforce-related breach incidents, extortion attempts, and high-profile companies completely exploited. Yet when you look “behind the scenes”, the same pattern emerges. According to Beech Horn, a Technology Engagement Manager and Architect at Banham Patent Locks, we’re seeing more security teams that don’t understand Salesforce, and more Salesforce teams that don’t understand security. The overlap – people who can speak both languages – barely exists.
“You don’t know what you don’t know,” Beech explained. “Security teams can’t speak the language of Salesforce… and teams only realize once an extortion email lands and the data is already leaked.”
It shouldn’t come as a surprise, then, that organizations only discover their exposure after the fact – when the audit logs aren’t enough, the monitoring wasn’t in place, or technical debt has been quietly stacking up over a long period of time. Salesforce has become the mission-critical architecture in many enterprises, but the way its security is architected still lags far behind the threats targeting it.
I sat down with Beech to discuss this further, looking into where architects are going wrong, the blind spots attackers are exploiting, and how to really design a Salesforce org that is secure and usable.
The Missing Skillset Nobody Is Hiring For
As aforementioned, if you look at the root of most Salesforce org security failures, the pattern is painfully consistent: companies lack people who understand both Salesforce and security. Many usually have two strong teams that never quite meet in the middle, and attackers can slip straight through the gap.
“You have experienced security teams who do not understand the way Salesforce, MuleSoft, Slack, Marketing, or Commerce operate – who cannot speak the language of those teams, who do not know where to dig,” Beech detailed. “Meanwhile, you have teams experienced with those products who typically know some security, but do not have the wealth of experience a security professional may have to consider implications and threats.”
“Regrettably, where it’s showing up, even for large companies, is in their inbox as an extortion demand after the event. Only then do you have the process of scant audit data and consideration of data exposure. Only then do you have the realization of technical debt.”
Of course, we’ve been keeping track of Salesforce data breach victims on Salesforce Ben, many of which are high-profile companies. 14 of the involved parties have actually taken Salesforce to court in the aftermath, with 23 plaintiffs reportedly being named. But are these companies really finding the root cause by doing this?
Beech mentions that of all the companies named or involved in breach incidents, few are actually resolving the problem effectively, which should be to fill the knowledge gap properly.
“I was looking at the list of companies that got released – how many of them have actively posted jobs looking for Salesforce security experts? The number is zero.
“I don’t think there’s recognition from teams that you need individuals who have the overlap of the two that can communicate. There’s such a divide between them, and the same concepts of security apply. The ways you implement it are completely different with Salesforce compared to other products, but you can still take those learnings and apply them.”
And this absence of knowledge, experience, and expertise is costly, leading to later discovery and more time on the cleanup job. “Companies are discovering this way afterwards and then are going, ‘Oh, we don’t have the auditing in place. We don’t have the security measures in place. We’re not sure of the size of the breach!’ We’ve seen this played out a lot this year, even in large companies that should really know better.”
With a lack of hybrid skillset and proper visibility, we’re seeing this cycle everywhere. Beech’s hope is that the ecosystem finally starts to close the gap before attackers do – otherwise, architecture will always have holes, and attackers will continue to find them first.
“With the community sharing knowledge and events like the Salesforce Ben Security Month, we can get both sides to address these issues, identify the security technical debt, and get moving before an event.”
The Blind Spots Audits and Monitoring Always Miss
Even when companies try to audit Salesforce security, they can often miss the parts that matter most. The biggest issue isn’t that organizations don’t want to monitor their org; it’s that the tools, documentation, and visibility simply don’t keep up with the threats.
For Beech, several blind spots repeatedly expose companies without them realizing it. The first is the belief that Salesforce’s native tooling already provides strong coverage.
“Event monitoring’s got a bit of a misnomer,” Beech explained. “It doesn’t actually do the monitoring of events. It just allows you to use additional tooling to monitor the events. So, it’s not only the cost for people to put in event monitoring. It’s also the cost to implement the monitoring that you need on top.”
In other words, you can buy the feature, but that does not mean you’re protected. Without additional systems, Event Monitoring becomes a bucket of logs waiting for someone to sift through them manually – and that assumes that companies can even afford the Shield tier in the first place.
“You’ve still got to do a lot of work on top of that. Things like data detect, which allows you to see when there’s vulnerable data in fields you didn’t expect that you might give people permission to, that requires you to buy the big 40% of your license cost of Shield – that’s really expensive for customers.
“Out of the tools that Salesforce provides that people would want for their auditing and monitoring, it’s out of reach for a lot of people. Not just for the license cost, but also the implementation cost.”
Then there are the risks organizations can’t see, as according to Beech, Salesforce doesn’t document them. This is where hackers have been operating most effectively over the past few years.
“There are a lot of things people don’t realize,” Beech said. “You’ve got things like public links, Chatter groups, even Lightning APIs that aren’t documented.”
These areas don’t appear in admin screens or security checklists, nor do they surface in the user interface (UI). The only way to really know or learn about them is through the community.
“You’ve got to speak to the community… to actually understand what the risks are because they’re not risks that are visible.”
There’s also an entire category of threats Salesforce doesn’t scan for at all and may never scan fully. Many modern attacks work through content ingestion, automation entry points, or file processing.
“There are third-party risks where there’s no Salesforce offering or way of dealing with it directly,” Beech noted, referencing “phishing links that have arrived from email-to-case… malicious images that hit an image processing library in a PDF or even just plain malware.”
In essence, there really isn’t any room for complacency when it comes to Salesforce architecture – blind spots are everywhere, and diligence is required.
Why Zero Trust and Least Privilege Principles Struggle in Real Life
One of the most common phrases in security conversations is “zero trust”, followed closely by “least privilege”. Many organizations try to uphold these principles, but few manage to implement them in a way that doesn’t collapse under pressure.
Beech argues that the issues and challenges are cultural just as much as they are technical. “The easy go-to is speaking to companies that say: we trust all of our users, why wouldn’t we set org-wide sharing of accounts to public read/write?” he said.
Many businesses really don’t want to slow down workflows in the name of security. If a new control or feature starts creating friction for users, it’s usually the security that gets altered or completely removed.
“When security measures are demonstrably performance drama or hoop jumping… you’re inviting circumvention,” Beech explained.
In turn, this circumvention sometimes leads to people not reporting suspicions to IT to avoid additional hassle. It can also encourage people to share shortcuts, quietly disable some controls, or even form their own private channels. Beech said: “Your coworkers will actively avoid reporting suspicious behavior to avoid the grief, and private WhatsApp groups share how to bypass the measures you’ve implemented.”
The solution, according to Beech, is to stop treating least privilege as an access-restriction exercise and start treating it more like a user experience design problem.
“Least privilege should feel more zen for users. Only seeing what they need to at a given moment and no more. It should feel like walking down the street with close protection officers moving potential threats out of your way and making sure you can keep your cadence – no matter how busy the street is.”
And if access needs to be granted, it should happen as seamlessly as possible.
“You don’t want people fumbling with the buttons on the ticket machine. What you really want is them to arrive at the platform when the train is pulling in and the doors open.” Beech Horn
For most companies, the failures of zero trust are centered more around a lack of design than a lack of policy. Security becomes visible when it should be invisible, obstructive when it should be frictionless, and rigid when it should adapt. And once users feel blocked, they’re going to try and find ways around it.
How to Learn the Right Parts of Salesforce Security
When Beech first stepped into a major Salesforce security project, he wasn’t satisfied with how the system had been built. The security architecture wasn’t holding up, but for an important reason – the people responsible for the org didn’t have the Salesforce knowledge to ensure it was properly secured.
“It’s been rapid learning,” he said. “For anyone going through the same passage, the bits I’d recommend are learning Shield and learning Data Cloud because it’s showing you the gaps and the way the systems join together.”
Beyond Salesforce itself, many of the most valuable insights come from the community, such as insights from peripheral systems and specialist experts.
There’s a MuleSoft course called the DEX660, which Salesforce offers with a lot of information… you’ve got Lawrence Newcombe, who’s done a wonderful diagram for figuring out visibility. Matt Meyers has also done a lot on digital experience security and the hidden APIs.”
And then there’s the logging and monitoring side: “There’s a lot of SIEM training… DataDog and Fortinet both offer courses.”
All the different learning resources should help complete a full picture of how data moves, which entry points matter the most, and what attackers can realistically reach, ultimately transforming your full understanding of the platform.
“Salesforce becomes like a playground of figuring out how to put things together… there’s a whole wealth of really, really cool and exciting tools,” he said. “You’ve got to have the right resources.”
This is also why Beech encourages people not to begin their journey with the usual starting point.
“I strongly encourage heading to Data Cloud first because it’s that nexus of everything connecting,” he explained. “You can see how the whole system’s been built together.”
What works in the long run is a system built by someone who deeply understands the relationships, the layers, the flows, and the non-obvious attack paths – bridging security and Salesforce effectively.
Final Thoughts
The Salesforce platform has never been more powerful – and now, more targeted. While the platform itself isn’t inherently insecure, most organizations don’t yet have the architectural depth, monitoring capabilities, or cross-disciplinary talent required to defend it properly.
As Beech consistently emphasized, the industry’s biggest weakness is the missing people in the middle who can interpret threats through the lens of Salesforce architecture, user behavior, automation pathways, integrations, and platform quirks.
Equally, the biggest risks aren’t the ones listed on security checklists – they’re the undocumented links, the forgotten APIs, the unseen flows, and the features Salesforce never intended to be targets.
The companies that will stay secure aren’t the ones that simply “lock things down.” They’re the ones who learn the platform deeply, design with users in mind, invest in proper monitoring, and understand threat personas. Salesforce’s threat landscape has changed, and the approach to security needs to change with it.
