Who Should Have Admin Access in Your Salesforce Org — And Why It Matters More Than Ever
Most businesses don’t have a clean answer to this question. Admin access in Salesforce tends to accumulate over time — granted quickly when someone needs it, rarely revisited once it’s in place. A user needed to do one thing, got elevated permissions to make it happen, and those permissions are still there two years later even though the need is long gone.
That pattern has always been a security risk. The Summer ’26 release makes it a more urgent one. Salesforce is now requiring a stricter form of authentication for users with elevated access, and those users will face an additional step every time they log in. That’s a reasonable price for someone who genuinely needs admin-level access. For someone who doesn’t, it’s unnecessary friction and an unnecessary exposure.
This is the moment to get your access model right.
What Admin Access Actually Means in Salesforce
In Salesforce, not all users are equal. Most users have access to the records and functions relevant to their role — a sales rep sees their accounts and opportunities, a service agent sees cases, a manager sees their team’s data. That’s how the system is designed to work.
Admin access is different. It gives users the ability to change how the system works, not just use it. A system administrator can create fields, modify page layouts, adjust permissions, build automations, and in some configurations access all records in the org regardless of sharing rules.
Salesforce also designates a broader category of privileged users — anyone with permissions to modify all data, view all data, customize the application, or write Apex code. These users may not have the full system administrator profile, but they have enough access to significantly affect how your Salesforce environment functions.
Both groups are now subject to phishing-resistant MFA under the Summer ’26 release. And both groups represent a meaningful security exposure if the access hasn’t been thought through carefully.
How Access Gets Out of Hand
It usually starts with a reasonable decision. A department head needs to be able to run a report that requires view all data. A power user needs to build a list view that requires a permission they don’t have. A consultant needs admin access to complete a project. Each of these decisions makes sense in context.
The problem is that access granted for a specific reason rarely gets revoked when that reason goes away. The department head still has view all data six months after the report was run. The power user still has the permission they got for that one list view. The consultant’s access is still active even though the project wrapped up.
Over time, the list of privileged users in a Salesforce org bears little resemblance to the list of people who actually need elevated access. And every person on that list who doesn’t need to be there is a potential entry point for a security incident.
Why the Summer ’26 Release Makes This Urgent
Salesforce is enforcing phishing-resistant MFA for all privileged users this summer. For users who genuinely need elevated access, that means setting up either a hardware security key or biometric authentication — Touch ID, Windows Hello — before the enforcement deadline hits.
That setup takes time and requires communication. If you have fifty users on your privileged list and half of them shouldn’t be there, you’re creating unnecessary work for your administrator, unnecessary friction for users who don’t need elevated access, and unnecessary complexity in your environment.
Getting the list right before enforcement hits means your administrator is only setting up phishing-resistant authentication for the people who actually need it. It means users who shouldn’t have admin access stop having it. And it means your security posture reflects your actual organizational structure rather than the accumulated decisions of the past several years.
The Right Way to Think About Admin Access
The principle is straightforward: users should have the minimum access necessary to do their jobs effectively. In practice, applying that principle requires answering a few specific questions for each user or role.
What does this person actually do in Salesforce day to day? If the answer doesn’t include configuring the system, building automations, or managing permissions, they probably don’t need admin access.
Why do they have the permissions they currently have? If the answer is “I’m not sure” or “they needed it for something a while back,” that’s a flag worth investigating.
What would break if you reduced their permissions? This is the practical test. If a user’s day-to-day work doesn’t require elevated access, reducing their permissions shouldn’t affect anything they do regularly. If it would break something, that’s useful information — it tells you the access is actually being used and the conversation becomes about whether it’s the right way to structure that workflow.
What a Permission Audit Actually Looks Like
Your Salesforce administrator can pull a report showing every user with system administrator access and every user with the specific permissions that qualify as privileged. That list is the starting point.
From there, the review is a conversation between your administrator and whoever owns each business function represented on the list. The goal isn’t to take access away from people who need it. It’s to confirm that everyone on the list is there for a reason, and to remove access for the ones who aren’t.
For users who lose elevated access, the process is straightforward. Your administrator adjusts their permissions and confirms they can still do everything their role requires. In most cases, this takes a few minutes and the user doesn’t notice a difference in their day-to-day work.
For users who need to keep their elevated access, the next step is making sure they’re set up for phishing-resistant MFA before the enforcement deadline. Your administrator should walk them through the setup process and confirm it’s working.
Making This a Regular Practice
The access audit you do this summer shouldn’t be the last one. Access creep is a persistent problem in any system that’s actively used and evolving. People change roles, projects end, consultants come and go, and permissions don’t always keep up.
A lightweight access review once or twice a year — just a check on who has elevated permissions and whether the list still makes sense — is enough to stay ahead of the problem. It doesn’t require a significant investment of time. It just requires someone to own it and a process for following through.
If your business doesn’t currently have a process for reviewing Salesforce access, building one now is a reasonable outcome of the work you’re doing to prepare for the Summer ’26 enforcement. You’re already looking at the list. Setting a calendar reminder to look at it again in six months costs nothing.
Listen to the full podcast episode here.