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 (formerly OwnBackup), 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.
Salesforce plans to retire permissions on profiles
o address these issues, Salesforce will be enforcing some long overdue changes on Profiles and Permission Sets with the arrival of the Spring ‘26 release. This means that permissions and access will no longer be granted through Profiles, but in Permission Sets. This change will surely make user management easier for Salesforce Admins, as Role-based assignment of access privileges makes it easier to manage access to data and is less prone to over permissioning.
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.
How Own Secure can help
Preparing for this change 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 for the Spring ‘26 release. 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 from Salesforce, coupled with thoughtful implementation processes by customers to get ready for it, will result in vastly improved org security postures around the globe.
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.
