Salesforce published June 2026 MFA guidance for employee and privileged users. Here is what admins should audit before access breaks.
Key takeaways
- Export active users and identify privileged permissions.
- Confirm SSO policies meet the required MFA strength.
- Test privileged login in production and sandbox.
- Document break-glass access before enforcement starts.
- Separate integration users from human login patterns.
Salesforce published new MFA enforcement guidance on June 5, 2026. The practical issue is access: admins, developers, and privileged users may need stronger authentication than they use today.
Salesforce’s Help article, Prepare for phishing-resistant MFA enforcement for privileged users including admins, says phishing-resistant MFA applies to users with the System Administrator profile, Modify All Data, View All Data, Customize Application, or Author Apex permissions. It applies to direct Salesforce logins and SSO logins, across production and sandbox orgs.
A related Salesforce Help article, Prepare for MFA enforcement for all employee users, says Salesforce is enforcing MFA for all employee logins, including direct UI and SSO, across production and sandbox orgs.
For mid-market teams, the risk is not the MFA setting itself. The risk is the access inventory behind it. Many orgs still have old admin accounts, shared integration users, over-permissioned managers, and sandboxes that are treated less carefully than production.
This guidance puts those habits under pressure.
What is Salesforce phishing-resistant MFA?
Salesforce phishing-resistant MFA means MFA methods based on WebAuthn, including security keys and built-in authenticators. Salesforce also refers to these methods as passkeys.
That is different from one-time codes or push prompts. Salesforce’s June 5 guidance says privileged users must use phishing-resistant MFA. It also says Salesforce recommends phishing-resistant methods for all users.
For admins, the important word is “privileged.” This is not limited to people with the System Administrator profile. The Salesforce guidance also names permissions that often appear in cloned profiles and broad permission sets:
- Modify All Data
- View All Data
- Customize Application
- Author Apex
If a user has one of those permissions, treat them as in scope until your org proves otherwise.
This matters because many Salesforce orgs have permissions spread across profiles, permission sets, and permission set groups. A user may not look like an admin on the User record. They may still have View All Data through a reporting permission set, or Author Apex through a developer permission set assigned years ago.
Who is affected by Salesforce MFA enforcement?
All employee users are affected by MFA enforcement, and privileged users have the stricter phishing-resistant requirement. Salesforce’s guidance says the enforcement covers production and sandbox orgs.
For mid-market teams, the affected population is usually wider than the admin team expects. Check these user groups first:
- Salesforce admins and delegated admins
- Developers with Author Apex
- Operations users with broad reporting access
- RevOps users with View All Data
- Data migration users with Modify All Data
- Managed package support users
- Contractors who log in through SSO
- Sandbox-only users
- Break-glass admin accounts
The sandbox point matters. Many companies protect production well, then leave sandboxes full of active users, weak passwords, and old permission sets. Salesforce is making sandbox access part of the same identity control conversation.
Do not assume a partial sandbox is out of scope. Do not assume a developer sandbox is out of scope. If employee users can log in, review it.
Does Salesforce SSO satisfy the new MFA requirement?
SSO may satisfy the MFA requirement only if the identity provider enforces the right MFA strength. Salesforce’s guidance says the requirement applies to direct UI logins and SSO logins.
Do not assume SSO is enough. Confirm what your identity provider requires for privileged Salesforce users. If admins sign in through Microsoft Entra ID, Okta, Google, or another identity provider, the Salesforce side still needs validation.
The practical check is straightforward:
- Export privileged Salesforce users.
- Map each user to their identity provider group.
- Confirm which MFA policy applies to that group.
- Confirm whether the method is phishing-resistant.
- Test login with one admin account in production and one sandbox.
If admins are grouped into a general “Salesforce users” policy with standard MFA, they may not meet the stronger requirement.
Also check direct login paths. Some orgs use SSO for employees but still allow direct Salesforce login for admins, support users, or integration accounts. Those exceptions are where access problems usually appear.
What should Salesforce admins do now?
Start with a permission audit, not a hardware key purchase. You need to know who is actually in scope.
A practical sequence:
- Export active users.
- Identify users with the System Administrator profile.
- Identify users with Modify All Data, View All Data, Customize Application, or Author Apex.
- Separate human users from integration users.
- Check whether each human user logs in through SSO or direct Salesforce login.
- Confirm the MFA method assigned to each privileged user.
- Test the same pattern in at least one sandbox.
This is also a good time to remove permissions that users no longer need. A sales operations user may need export access for a defined process. They may not need View All Data permanently. A developer may need Author Apex in a sandbox. They may not need broad production access every day.
Do not clean permissions casually. Use a change log. Confirm business owners. Test reports, flows, integrations, and support processes before removing broad access.
For example, removing View All Data can affect executive dashboards, cross-record reports, duplicate management, list views, and support escalation workflows. Removing Customize Application can affect admins who manage custom objects, fields, record types, page layouts, and automation.
Treat the audit as a controlled change, not a cleanup task.
What can break if Salesforce MFA changes are missed?
The most common failure is admin lockout. The second is a delayed deployment because a developer cannot access a sandbox or authorize a tool.
Watch for these patterns:
- Admins relying on an unsupported MFA method
- Sandbox users without enrolled authenticators
- Shared admin accounts with no clear owner
- SSO policies that do not distinguish privileged users
- Contractors excluded from standard identity policies
- Integration users treated like human users
- Emergency access accounts with no tested login path
Integration users deserve separate handling. They should not be shared human accounts. They should have named owners, documented authentication methods, and the least access required for the integration.
If an integration still depends on a username and password pattern, review it before the identity change becomes the outage. Check connected apps, named credentials, API-only users, managed package users, middleware accounts, and scheduled jobs.
For regulated teams, this is also an audit issue. If you run financial services, healthcare-adjacent operations, or insurance workflows in Salesforce, admin access is part of your control environment. Document the users reviewed, the permissions removed, and the MFA policy confirmed.
How should mid-market teams plan Salesforce passkeys?
Plan passkeys like an access management project. Do not treat them as a personal device preference.
For each privileged user, decide which method they will use:
- Built-in authenticator, such as device biometrics
- Security key
- Both, when backup access is required
Then document what happens when a laptop is replaced, a phone is lost, or a contractor leaves. Smaller teams often skip the recovery path. That is where a security change becomes an operations problem.
LOVALTO recommends a one-page access runbook with seven items:
- Who approves privileged Salesforce access
- Which permissions make a user privileged
- Which MFA methods are approved
- How sandbox access is handled
- How emergency admin access is tested
- How integrations are excluded from human login patterns
- How access changes are recorded
Keep it short. The goal is a process an admin can follow during a release week, not a policy nobody reads.
What should you verify before publishing an internal Salesforce MFA plan?
Verify the exact enforcement schedule in Salesforce’s security roadmap and your own org notices. Salesforce Help confirms the June 5, 2026 guidance and the scope of the requirements, but each org should still check its own alerts and release update status.
Before you communicate to users, confirm:
- Which orgs are affected
- Which users are in scope
- Which MFA methods are accepted
- Whether SSO policies meet the requirement
- Whether direct Salesforce login is still allowed
- Whether sandboxes have the same controls
- Who owns break-glass access
This is not a large implementation for every org. For many teams, it is a focused access cleanup. The hard part is finding exceptions before Salesforce finds them for you.
Audit privileged Salesforce users this week. Start with System Administrator, Modify All Data, View All Data, Customize Application, and Author Apex.