Editor's Note: This blog post was updated in October 2024 with the latest resources and information.
One of the most well-known cybersecurity best practices is the “Principle of Least Privilege”, which recommends that organizations limit user account privileges (and periodically review such privileges) to only those necessary to perform their job functions. Enforcing least privilege helps reduce security risk and minimize business disruption, and is also a foundational part of zero-trust strategies.
Within Salesforce, a platform we support at Own, users are granted privileges using Profiles, even if a Profile doesn’t match their job function. Unfortunately, this mismatch often results in Salesforce users being able to see and do things they shouldn’t, increasing risks like accidental deletion or corruption of data and unauthorized access to sensitive information. In addition, embedding access privileges within Profiles makes it difficult to determine who sees what in Salesforce, making it harder to review and manage user access and permissions.
The persistent over-assignment of permissions and access facilitated by Profile-based assignments is one of the most common findings in our Salesforce Security Risk Assessments and is a direct violation of the Principle of Least Privilege.
How does over-assignment of permissions and access typically happen?
Profiles are often used to group people (e.g. Sales, Customer Support), which makes sense. However, rather than building Profiles with the least common denominator set of permissions and access and then using Permission Sets to selectively grant additional access or permissions in accordance with the different roles or process requirements personnel may have in a group (e.g., Support Agent, Support Team Lead, Call Center Manager, etc.) many orgs take a different approach. Instead, they grant additional access or permissions to the group’s Profile, resulting in everyone in the group automatically having the same permissions and access, despite not requiring either.
The Principle of Least Privileged Access does not address assignment mechanisms (e.g., Profiles, Perm Sets, ACLs, etc.), which will vary widely amongst applications, platforms, and systems. It simply states that each user should have the minimum amount of access and permissions required to perform their role. The Principle of Least Privileged Access is a widely recognized principle that is directly referenced in the Zero Trust initiative, all security frameworks, and many regulations. It is essential in minimizing the “blast radius” should a breach or incident occur.
What does Salesforce say about permissions on profiles?
Early in 2023, Salesforce announced that permissions on profiles would have a Spring '26 end-of-life date. The planned changes involved shifting the granting of permissions and access from Profiles to Permission Sets, which was meant to simplify user management for Salesforce Admins.
However, early in 2024, Salesforce reversed course and decided not to enforce the 2026 end of life date. Here's what Cheryl Feldman, Director of Product Management at Salesforce, said about the decision:
Hey, #AwesomeAdmins, I wanted to update you on the End of Life of Permission on Profiles.We are no longer going to enforce the Spring ‘26 end-of-life date. However, I still wholeheartedly recommend you operate with a permission set-led security model. All of our investments are very mission set and permission set group focused from a permissions standpoint.
Despite the fact that Salesforce decided to pause the enforcement of the end-of-life of permissions on profiles, they won’t be enhancing profiles and recommend using a permission set-led security model, as Cheryl states above.
Using a permission-set-based security model continues to be a best practice, as you can apply permission sets to users based on what job they do versus their specific role. This practice also saves you from creating hundreds of different profiles and allows maximum reusability, since one permission set can be reused in multiple permission set groups.
How Own Secure can help
Making the change from a profile-based security model to a permission set-led security model will take time, particularly in more mature Salesforce orgs with a higher likelihood of complexity sprawl. The good news? Own Secure’s Who Sees What (WsW) module can make the transition much more manageable. Within the WsW module, you can easily observe and export both the permissions and access granted by Profiles / Permission Sets / Permission Set Groups, thereby facilitating the inevitable straddling of multiple assignment mechanisms while transitioning.
Once permissions and access have been migrated to Permission Sets, the Own Secure WsW module can help you maintain and audit your improved security posture resulting from the transition.
We believe that this change, coupled with thoughtful implementation processes by customers to get ready for it, will result in vastly improved org security postures from organizations using Salesforce/
Ready to save hours of time?
It can take hours looking through Salesforce Profiles, Permission Sets, and Permission Set Groups to understand a single user’s rights and how they got them. Learn how Own Secure can simplify and automate this process. Request a demo today.
.png){kind=logo}
