.png)
Salesforce’s Phishing-Resistant MFA Enforcement: What Organizations Need to Do Now
Salesforce recently announced a major upcoming security enforcement requiring phishing-resistant multi-factor authentication (MFA) for privileged users, including System Administrators and users with elevated permissions.
While this may initially sound like a routine security update, the operational and technical impact for many organizations could be significant, especially for organizations with integrated applications, shared administrative access, or large numbers of privileged users.
This enforcement represents more than just a new login requirement. It reflects a broader shift happening across the technology landscape: organizations are increasingly being expected to treat identity, access, and CRM governance as critical operational infrastructure rather than secondary IT concerns.
For many organizations, Salesforce has become the operational heartbeat of their business - powering customer relationships and executive decision-making. As the platform becomes more central to daily operations, the expectations around securing that system are increasing rapidly.
What Salesforce Is Enforcing
Salesforce will require phishing-resistant MFA for users with elevated or privileged access, including users with permissions such as:
- System Administrator
- Modify All Data
- View All Data
- Customize Application
- Author Apex
This enforcement applies to Production orgs and Sandbox orgs.
Sandboxes: Starting June 22, 2026, staggered over approximately 7 days
Production: Starting July 1, 2026, staggered over approximately 30 days
Traditional MFA methods that many organizations currently rely on will no longer satisfy the requirement for privileged users, including:
- Push notifications
- SMS codes
- Authenticator app codes
Instead, privileged users will need to authenticate using phishing-resistant methods such as:
- Hardware security keys (YubiKey, Google Titan, etc.)
- Built-in biometric authenticators like Touch ID, Face ID, or Windows Hello
Why Salesforce Is Making This Change
The cybersecurity landscape has changed dramatically over the last several years.
Many of the most damaging breaches across the technology industry have not occurred because organizations lacked MFA. They occurred because attackers successfully bypassed traditional MFA methods using:
- Social engineering
- MFA fatigue attacks
- Weak administrative controls
- Overprivileged access
- OAuth token abuse
The operational and financial consequences of these breaches have been substantial:
- Exposure of customer data
- Operational downtime
- Regulatory scrutiny
- Legal liability
- Loss of customer trust
- Significant remediation costs
Salesforce is effectively acknowledging that older credential-based security models are no longer sufficient for protecting highly privileged access. In many ways, this enforcement is Salesforce saying: enough is enough.
The Biggest Risks Organizations Should Be Paying Attention To
For many organizations, the biggest challenge will not be registering hardware keys. The real challenge will be uncovering years of accumulated access, integration, and governance issues that this enforcement exposes.
Below are the areas we believe organizations should prioritize immediately.
1. Overprivileged Users
One of the most common issues we encounter is users having far more access than they actually need.
Over time, permissions tend to accumulate:
- Temporary admin access becomes permanent
- Permission sets are layered repeatedly
- Former operational needs are never cleaned up
- Users inherit access through role changes
This enforcement creates an important opportunity to audit:
- Who truly needs administrative access
- Which users require elevated permissions
- Whether legacy admin assignments still make sense
Many organizations will likely discover that a significant percentage of users currently classified as “privileged” do not actually need those permissions today.
2. Shared Administrative Accounts
Organizations still using shared administrative accounts should pay close attention to this change.
Shared accounts create several major problems:
- No individual accountability
- Limited auditability
- Increased security exposure
- Difficulty offboarding consultants or staff
- Challenges managing phishing-resistant authentication methods
Salesforce’s direction is clearly moving toward:
- One user
- One identity
- One auditable authentication method
Organizations relying heavily on shared admin access should begin planning for named-user administrative models now. We understand that we fall into this category as a Salesforce Consulting Partner. Here is the main option(s) we are considering:
- Keep one System Administrator user in Production. This member of the team will be responsible for setting up phishing-resistant MFA. This member of the team will also be responsible for deploying changes in Production.
- Maintain System Administrator privileges in Sandbox environments. We would create new user accounts in these environments for each Summit One team member that needs to configure and deploy changes.
- Drawbacks to this approach:
- Multiple team members may need access to Production to support with troubleshooting and adding additional redundancy.
- Sharing settings and permission sets may need to be modified in order to properly diagnose or repurpose bugs and defects.
- Deployments could be delayed due to the one System Administrator not being available.
This approach is not set-in-stone or one-size-fits-all. We are always committed to providing a personalized approach that meets the needs and demands of our clients.
Our core objective with this change is to maintain the continuity of our services without an increase in time spent or additional cost for individual Salesforce licenses.
3. Integrations Connected With Username & Password Authentication or a System Admin User
This may be one of the most disruptive areas for organizations.
We regularly encounter:
- Legacy middleware integrations
- ETL jobs
- Connected Apps
- Warehouse syncs
- Custom scripts
- Automation tools
that still authenticate using:
- A staff member’s username/password
- A non-dedicated integration user license
- Shared service accounts
- Basic authentication methods
Organizations should immediately inventory:
- Connected Apps
- Integration users
- Middleware platforms
- External API connections
- Scheduled sync jobs
and begin transitioning toward:
- External Client Apps
- Named Credentials
- Dedicated integration users
- Modern token-based authentication patterns
This work should begin well before enforcement deadlines.
4. SSO Misconfiguration Risk
Many organizations assume that because they use Okta, Microsoft Entra ID, Ping, or another identity provider, they are already covered.
That assumption can be dangerous. Organizations should validate:
- MFA is actually enforced for Salesforce
- Privileged users are not exempted unintentionally
This is an area where organizations often discover gaps they were previously unaware of.
5. Operational Readiness & User Support
The technical configuration is only one piece of the rollout.
Organizations should also plan for:
- User communication
- Training
- Hardware key distribution
- Backup authentication methods
- Lost/stolen device procedures
- Help desk readiness
- Executive stakeholder alignment
For organizations with distributed teams, contractors, or multiple regions, this can quickly become a meaningful operational initiative.
What Organizations Should Be Doing Right Now
We strongly recommend organizations begin taking the following steps immediately:
Immediate Action Items
- Inventory all privileged users and elevated permissions
- Reduce unnecessary administrative access
- Audit integrations and service accounts
- Validate SSO enforcement policies
- Eliminate shared administrative access where possible, Summit One included
- Identify users who will require phishing-resistant methods
- Procure and test hardware security keys if needed
- Develop backup access and recovery procedures
- Build a communication and rollout plan
- Begin testing in sandbox environments early
Organizations that begin now will have the ability to approach this transition thoughtfully and strategically.
Organizations that wait until enforcement windows approach will likely experience:
- Login disruptions
- Integration failures
- User frustration
- Increased support burden
- Emergency remediation work
- Rushed decision-making
Our Perspective
In our experience, changes like this rarely create problems on their own. They usually expose problems that were already there - excessive permissions, legacy integrations, and unclear ownership of systems.
For many organizations, this enforcement will expose operational and security gaps that have quietly accumulated for years. The organizations that start preparing now will have time to address those issues thoughtfully instead of reacting under pressure as enforcement deadlines approach.
Resources
What is Phishing-Resistant MFA?
Prepare for Phishing-Resistant MFA Enforcement for Privileged Users including Admins
How to Prepare for Salesforce’s Mandatory MFA Changes in 2026
