This year’s SF Ben Admin Survey has a lot to say about the state of the ecosystem for admins, including workload, AI adoption, technical debt, and more. However, given the actions Salesforce has taken and the changes it has been rolling out in recent months following the breaches, one section from the survey stands out as more urgent than ever: security.
In this article, we’ll dive into the insights from the security section of the admin survey, as well as the three fundamental principles you should familiarize yourself with if you want to improve your security posture in next year’s survey.
The Current State of Security in Salesforce
According to the survey, the skill that ranked #1 among the least confident skills across admin respondents of all experience levels is security. That says a lot.
It’s also interesting when you zoom out a bit. Topics such as new features, career advice, and especially Flow tend to get the most attention and engagement across the ecosystem – whether that’s articles, LinkedIn posts, or community discussions in general. Security, on the other hand, is rarely labeled as an “exciting” topic that people actively seek out, even though it’s foundational to everything else.
At the same time, we’re already in the era of AI, proven by how Agentforce adoption has doubled compared to last year. AI tools in general are also becoming more and more embedded in the day-to-day workflows of the average Salesforce Admin, with 44% of the SF Ben Admin Survey respondents reporting they are now using AI tools daily or regularly, nearly double the 24.7% reported the previous year. This actually raises the stakes for security in ways that go beyond the familiar.
Maximizing the use of agents is being strongly encouraged by Salesforce itself (when used appropriately), and understandably, anything involving agentic behaviors and automated actions tends to move faster than traditional human oversight can comfortably keep up with.
Currently, it seems that innovation is accelerating so fast while security practices struggle to evolve at the same pace. With that in mind, it’s worth grounding ourselves in a few fundamentals.
1. The Shared Responsibility Model
If you’re already familiar with this principle, then you’re part of the 46.2% of admins who are. That’s not too bad considering the improvement from last year’s survey, where 73.5% of respondents were unfamiliar with it. But when you really think about it, it still isn’t the majority. More than half of admins are still unaware of this principle, and given what it actually means, that can be a little alarming.
The Shared Responsibility Model means that everything built on top of the Salesforce platform – your data, user access, custom configurations, integrations, etc. – is ultimately your responsibility to secure. Salesforce is responsible for securing the platform and infrastructure itself, but how your org is configured and accessed falls on your side.
It’s deceptively simple and easy to overlook in practice because when something goes wrong with data security in an org, it’s easy to direct the blame toward Salesforce itself. After all, the platform powers the whole experience from users logging in to the data that it houses. However, that does not change the fact that responsibility for how that data was configured, who has access to it, and how it was exposed still rests with the customer.
A simple example would be an overly permissive permission set or a user falling victim to phishing. While Salesforce provides the tools and security controls, customers are responsible for implementing and maintaining them correctly.
2. The Principle of Least Privilege
Are you part of the 20% who say they very effectively enforce the Principle of Least Privilege? If not, then this should absolutely be the goal. According to the survey, 45.5% reported only moderate reinforcement, while and 23.9% admit to only partially enforcing it. Another 10.6% either provide broader-than-necessary access or aren’t entirely sure of their approach. Granted, 10.6% may not sound especially alarming at first glance, but if you feel like you fall into this category, this is something worth addressing sooner rather than later.
The Principle of Least Privilege is built around a very simple idea: Users should only have access to what they absolutely need to do their job – nothing more.
In practice, giving broad access is often the path of least resistance. What’s easier than simply giving someone admin access so they can get to whatever you need them to access? It’s definitely faster than carefully figuring out the right permission set combination.
If “agent sprawl” refers to the uncontrolled growth of overlapping AI agents and automations across an org, then permission sprawl (also called privilege creep or access sprawl) is its equivalent in the security context. Picture overlapping access that accumulates over time through overlapping profiles, roles, permission sets, and temporary exceptions that were never cleaned up. Eventually, it becomes more and more difficult to track and control, which makes it one of the most common security risks in mature Salesforce orgs.
Another finding from the survey ties directly to this, showing only 20.5% of orgs have fully transitioned to a Permission Set-led security model and moved away from Profiles as the primary access mechanism. This means that most orgs are still stuck somewhere in the middle: partially transitioned, managing hybrid models, or struggling with the complexity of untangling years of layered access configurations.
3. Zero Trust
From the name itself: don’t trust! Have absolutely none of it…zero. (I see you, those with trust issues, as I do. Kidding.)
Well, mostly kidding. The principle runs on the same idea.
Zero Trust should be considered the standard in modern cloud security. No user, device, or system should be inherently trusted – yes, even if they’re already inside your network. Access should be continuously verified rather than assumed based on location or previous authentication. This is why features such as MFA, Trusted IP Ranges, session security settings, and identity verification exist in Salesforce.
Zero Trust flips the old assumption that once someone is trusted, they should continue to have uninterrupted access to everything they need. Instead, verification should happen continuously, every layer should have limited access, and your security model should be designed around the possibility that any user or device could be compromised at any time.
The survey shows that only 16.7% of respondents are very familiar with Zero Trust and are actively applying it in their orgs. That’s a relatively small number, especially considering that an even larger portion of respondents (27% to be exact) aren’t even familiar with the concept at all.
This concept matters more these days, because modern Salesforce orgs are no longer simple internal systems with a handful of users logging in from office laptops. The rollout of Headless 360 this year is positioning the platform as highly connected environments that involve more integrations, AI agents, mobile access, remote work, and more, thanks to the “API-first” framing. And of course, the more connected an org becomes, the less viable “implicit trust” becomes as a security strategy.
Final Thoughts: Security Starts With the Basics
I know, I know. Security isn’t sexy. Compared to flashy new features or learning how to configure agents, it rarely gets the same level of excitement or attention (unless you’re a security fanatic, of course, in which case this article was probably your Super Bowl). However, that doesn’t make this topic any less important, and understanding at least these three foundational principles should be considered ground zero.
The three principles mentioned above are not independent. Instead, they reinforce each other. The survey paints a picture of a community that’s actively grappling with increasing complexity on the platform and rising AI adoption, which inevitably grows expectations placed on admins. Keeping pace with all of that is understandably difficult, especially when time, resources, and organizational support are already limited to begin with.
At the end of the day, knowledge gaps in security are more often an organizational risk than a lack of skill.
So if you haven’t revisited your org’s security posture recently, now is a great (and perfectly reasonable) time to do so. Start with the fundamentals and ask yourself questions around how your org currently approaches each of these three principles. The answers might end up being more reassuring than the survey numbers suggest – but the only way to know is to check.
