Security in Salesforce is one of those topics that is easy to assume is “handled somewhere else”, but in reality, it sits right at the heart of every org. After all, Salesforce often contains highly sensitive customer and business data, which makes it a natural target when we look at broader enterprise security risks.
The challenge is that governance has not quite kept up with how quickly platforms are adopted and adapted. According to the SF Ben 2026 Salesforce Admin Survey, only 20% of organisations report very effective enforcement of the Principle of Least Privilege, while 45.5% describe their approach as moderate, 24% as partial, and 10.6% either admit to over-permissioning users or are unsure of their approach altogether.
As orgs grow, things rarely get simpler. Permissions tend to accumulate over time through changing roles, quick fixes, and configuration decisions made under pressure. This leads to permission sprawl and, in some cases, more access than users really need. We can see this reflected in how slowly security models are evolving in practice, with just 20.5% of organizations fully transitioned to a Permission Set-led approach and 10.8% still relying primarily on profiles.
Even among those moving in the right direction, 43.6% are only partway through the transition, meaning legacy approaches are still heavily embedded in day-to-day admin work. All of this reinforces why Least Privilege is not just a nice-to-have principle, but something that needs to be actively designed, applied, and maintained inside Salesforce.
What is the Principle of Least Privilege?
The Principle of Least Privilege, often shortened to PoLP, sounds like one of those intimidating enterprise security concepts that only CISOs and compliance teams worry about. But in reality, it’s something every Salesforce Admin should understand and actively implement.
At its core, the Principle of Least Privilege means users should only have the minimum level of access needed to do their job. Nothing more. Simple in theory. Surprisingly difficult in practice.
In Salesforce, over-permissioning often happens gradually. Someone needs temporary access to troubleshoot an issue. A user changes departments but keeps their old permissions. A profile gets cloned years ago and slowly expands over time. Before long, users can view, edit, export, or administer far more than they actually need. Least privilege helps prevent that.
It reduces security risks, limits the impact of compromised credentials, improves audit readiness, and gives organizations clearer visibility into who can access what. Just as importantly, it creates a cleaner, easier-to-manage Salesforce org. And the good news is this: Salesforce gives admins plenty of tools to implement it well!
What Does the Principle of Least Privilege Look Like in Salesforce?
Applying least privilege in Salesforce is really about intentional access design.
That means:
- Users only see records relevant to their role
- Permissions are granted for specific responsibilities
- Elevated access is temporary and controlled
- Access is reviewed regularly
- Automation runs with the appropriate level of privilege
It also means moving away from the old habit of “just give them access so they can do their job quickly”, as quick fixes have a habit of becoming permanent security gaps.
Start With an Access Audit
If you’re not sure where to begin, start by understanding your current state. Most orgs already have over-permissioned users. The challenge is identifying where the biggest risks are hiding.A good audit usually focuses on three areas:
1. Identify Over-Permissioned Users
Look for users with permissions they rarely or never use. Some common red flags include:
- Users with “Modify All Data”
- Large numbers of System Administrators
- Users with API Enabled access granted unnecessarily
- Export permissions granted broadly
- Access to objects unrelated to a user’s role
- Old users retaining legacy permissions
This is often where admins discover permission creep.
You may find sales users with marketing access, support agents with setup permissions, or contractors with permanent elevated privileges long after projects ended.
2. Review Profiles and Permission Sets
Next, examine how access is being granted across the org. Many Salesforce environments evolve over years of quick fixes, cloned profiles, and one-off permission requests. Over time, this creates bloated profiles and inconsistent access models.
Look for:
- Multiple cloned profiles with only minor differences
- Permission Sets that duplicate profile permissions
- Broad object access granted “just in case”
- Users assigned to unnecessary combinations of Permission Sets
- Inactive or unused Permission Sets
This review helps identify opportunities to simplify your security model and move toward a more scalable permission strategy.
3. Audit Data Visibility and Sharing
Least privilege is not just about what users can do. It is also about what users can see. Review your:
- Organization-Wide Defaults
- Role Hierarchy
- Sharing Rules
- Public Groups
- Manual sharing practices
Ask whether users genuinely need visibility into the records currently accessible to them. For example, should all sales reps see every opportunity across regions? Does a contractor need visibility into customer support cases?
Reducing unnecessary visibility lowers compliance risk and limits exposure if accounts are compromised. Now that you have a better idea and understanding of potential problem areas, let’s take a look in more detail at changes we can make in our Salesforce org to implement the Principle of Least Privilege.
Profile, Permission Sets, and Permission Set Groups
One of the biggest shifts in modern Salesforce security design is moving away from heavy use of profiles.
Historically, profiles handled almost everything. The result was often dozens or even hundreds of cloned profiles with inconsistent access.
Today, Salesforce recommends a different approach:
- Keep profiles minimal
- Use Permission Sets to grant additional access
- Group permissions logically using Permission Set Groups
This model aligns much more closely with Least Privilege principles.
Why Minimal Profiles Matter
Profiles should ideally handle only the baseline requirements:
- Login hours
- IP restrictions
- Default apps and tabs
- Basic object access
Everything else should be layered through Permission Sets. This makes access easier to understand, easier to audit, and much easier to revoke when responsibilities change.
For example, a sales operations user may need:
- Standard sales access
- Delete permission for opportunities
- Export permission for reports
Instead of creating a custom “Sales Ops Plus Delete Plus Export” profile, you can assign:
- Base Sales Profile
- Opportunity Delete Permission Set
- Data Export Permission Set
Cleaner. Safer. Easier to manage.
Build a Transition Strategy
For many orgs, Least Privilege cannot happen overnight. Especially in mature Salesforce environments, permissions are deeply embedded in business processes, integrations, and automation. That’s why a phased transition strategy works best.
Step 1: Minimize Existing Profiles
Start simplifying profiles gradually. Remove unnecessary object permissions, field access, and system permissions wherever possible.
Avoid making large changes all at once unless you have extensive testing coverage. A practical approach is:
- Freeze profile creation
- Consolidate duplicate profiles
- Reduce admin-level access first
- Shift incremental permissions on Profiles into Permission Sets
Even small improvements can significantly reduce risk.
Step 2: Introduce Permission Set Layering
Permission Set layering is one of the most effective Least Privilege strategies available to Salesforce Admins. Think of access like building blocks.
A user receives:
- A minimal baseline profile
- Core job-function permissions
- Additional temporary or specialist permissions only when needed
This structure gives you flexibility without permanently expanding access. It also improves visibility during audits because you can clearly see why a user has a particular permission.
Step 3: Use Permission Set Groups
Permission Set Groups make scaling access management much easier. Instead of assigning five separate Permission Sets to every sales user, you can bundle them into a single group.
For example:
- Sales Core Access
- Support Agent Access
- Marketing Operations Access
You can also mute permissions inside groups when needed, which helps fine-tune access without creating unnecessary complexity. This is especially useful in larger organizations where users share similar responsibilities but need small variations in access.
Review Your Role Hierarchy and Sharing Model
Least privilege is not just about permissions. It is also about data visibility. It can be very easy to unintentionally expose too much data through overly broad sharing settings.
Review:
- Organization-Wide Defaults
- Role Hierarchy structure
- Sharing Rules
- Teams and manual sharing
- Territory Management access
Don’t forget that your org-wide default needs to be your most restrictive use case. If there’s even one user who shouldn’t see other people’s records, then the default sharing should be Private!
Ask yourself: “Does this user genuinely need visibility into this data?”
A marketing user probably does not need access to every support case. A regional sales manager may not need visibility into global opportunities. Keeping data visibility intentional reduces both security and compliance risk.
Reports and Dashboards
One commonly overlooked area of Least Privilege in Salesforce is report and dashboard folder access. Even if object permissions are configured correctly, users may still gain visibility into sensitive business information through shared reporting folders.
Folder access is typically controlled at three levels:
- View: Users can see reports and dashboards within the folder
- Edit: Users can modify existing reports and dashboards
- Manage: Users have full control, including managing folder sharing and access permissions
The “Manage” permission is particularly powerful because it allows users to decide who else can access the folder. In practice, this can unintentionally expand visibility far beyond what was originally intended.
As part of your Least Privilege strategy, review:
- Who owns critical reporting folders
- Which public groups or roles have access
- Whether users truly need Edit or Manage permissions
- Whether sensitive reports should be restricted to smaller audiences
This is especially important for folders containing financial reporting, customer data, forecasting dashboards, or compliance-related metrics. A good rule of thumb is simple: most users only need View access.
Flows and Automation
This is where least privilege becomes especially important. Flows can run in system context, which means they may bypass user-level permissions entirely. That can be useful. It can also become dangerous if not carefully controlled.
Admins should understand:
- Whether a Flow runs in user or system context
- What records the Flow can access
- Whether sensitive fields are exposed unintentionally
A Flow designed for convenience can accidentally create privilege escalation risks. For example:
- Updating fields users normally cannot edit
- Exposing confidential data in screen flows
- Triggering actions beyond intended user permissions
Always test automation from the perspective of the actual end user.
Apex Running Context
The same principle applies to Apex. By default, Apex runs in system context, meaning it ignores object and field-level security unless explicitly enforced.
Developers should use:
- WITH SECURITY_ENFORCED
- Security.stripInaccessible()
- User-mode database operations where appropriate
Admins may not write the code themselves, but understanding these concepts helps during security reviews and project planning.
If custom Apex bypasses your carefully designed security model, least privilege quickly falls apart.
User Access Policies
A common challenge with least privilege in Salesforce is keeping access aligned as users join, move roles, or leave the organization. User Access Policies help address this by automating user access based on predefined criteria, such as assigning or removing Permission Sets or Package Licences. Once enabled in Setup, Admins can define rules that ensure users consistently receive the right access at the right time, reducing manual work and the risk of over-permissioning.
Policies can target users using filters like Profile, Role, Permission Sets, or other User fields, and each policy can trigger actions such as granting or revoking access. Admins also need to consider the order of policies, especially when criteria overlap, as this determines how they are applied.
Policies can run automatically when users are created or updated, or be applied manually for one-off changes. Every action is logged, giving admins full visibility into what changed, when, and why, which makes it easier to audit and maintain least privilege over time.
Audit, Monitor, and Adjust Regularly
Least privilege is not a one-time project. Salesforce orgs are constantly evolving as users change roles, new features are introduced, and temporary access becomes permanent through oversight.
That’s why regular auditing, monitoring, and adjustment are essential.
Schedule recurring access reviews to identify unused permissions, excessive access, and outdated assignments before they become security risks. Monitor high-risk permissions such as “Modify All Data”, API access, and report exports, and review who has access to sensitive folders, objects, and automation.
Most importantly, build permission reviews into your operational processes, especially during onboarding, offboarding, and role changes. A clean security model only stays clean when it is actively maintained.
Final Thoughts
Security is strongest when it’s deliberate. The Principle of Least Privilege is not about making Salesforce harder to use. It’s about making access intentional, manageable, and aligned to real responsibilities. For Salesforce Admins, that means designing security with care instead of convenience.
Least Privilege can feel overwhelming at first, especially in older orgs with years of accumulated permissions. But you do not need to fix everything immediately. Progress matters more than perfection. Every unnecessary permission removed is one less security risk to worry about.
