As a Salesforce admin, you’ve probably seen the recent notices about multi-factor authentication, or MFA, requirements for privileged users.

At first, it may seem like this does not require much attention. Most Salesforce organizations have already been using MFA for years.

The important detail is that this change is not about MFA in general. It is about phishing-resistant MFA for users with elevated privileges.

That is a big difference, and it is where many organizations are getting confused.

This article walks through who is impacted, which authentication methods meet Salesforce’s requirements, which methods need to be reviewed, and what steps administrators should take before the enforcement deadline.

Who Is Impacted?

Not every Salesforce user requires the same review.

Start with anyone who has one or more of the following:

• System Administrator profile
• Modify All Data
• View All Data
• Customize Application
• Author Apex

One thing that is easy to miss is that these permissions do not have to come from a profile. They can also be assigned through permission sets.

If your organization has been using Salesforce for a few years, it is worth checking both profiles and permission set assignments. Temporary access granted for a project often stays in place far longer than anyone planned.

Why Is Salesforce Doing This?

Administrative accounts carry far more risk than standard user accounts.

A compromised admin can often create new users, change security settings, export data, install packages, modify automation, or make changes that affect the entire Salesforce environment.

Traditional MFA adds important protection, but some methods are still vulnerable to phishing.

Salesforce’s updated requirements are intended to reduce that risk by promoting authentication methods that confirm both the user and the legitimacy of the login request.

Which Authentication Methods Meet the Requirement?

Salesforce supports multiple phishing-resistant authentication methods for privileged users.

If you are using an identity provider such as Microsoft Entra ID, Okta, or Ping Identity, confirm that the authentication method configured for Salesforce meets Salesforce’s phishing-resistant MFA standards.

SSO by itself is not sufficient. The identity provider must enforce a compliant authentication method and pass the appropriate authentication signal to Salesforce.

Which Methods Should You Review?

Many organizations are already using one of these methods:

• Microsoft Authenticator one-time codes
• Google Authenticator
• SMS verification codes
• Email verification codes
• Standard authenticator app codes

These methods may satisfy standard MFA requirements, but they should not automatically be assumed to satisfy Salesforce’s phishing-resistant MFA requirements for privileged users.

If any administrators or privileged users rely on one of these methods today, review Salesforce’s current guidance and move them to a supported phishing-resistant method before enforcement.

How We Recommend Reviewing Your Org

Instead of immediately changing login settings, work through the review in this order.

1. Identify Privileged Users

Export a list of users who have:

• System Administrator profile
• Modify All Data
• View All Data
• Customize Application
• Author Apex

Review both profiles and permission sets.

This step is important because many organizations have users with elevated access who are not assigned the System Administrator profile.

2. Document Current Authentication

For each privileged user, answer the following:

• Do they log in directly to Salesforce or through SSO?
• What authentication method do they use today?
• Do they have a backup authentication method?
• Are they using a company-managed device?
• Do they access both production and sandboxes?

Putting this into a spreadsheet usually makes the rest of the review much easier.

3. Confirm Compliance

Compare each user’s authentication method against Salesforce’s current guidance.

If the current method does not satisfy the phishing-resistant MFA requirement, register a supported method before the enforcement deadline.

4. Test Production and Sandbox Access

A successful registration does not always mean the full login process has been tested.

Have each privileged user test:

• Production login
• Sandbox login
• Login from a different browser
• Login after clearing cookies
• Recovery if their primary authentication device is unavailable

Testing now is much easier than troubleshooting login issues after enforcement starts.

Common Issues We See During Reviews

A few issues come up often during privileged access reviews.

The first is assuming that everyone with administrative access has the System Administrator profile. That is often not the case.

The second is forgetting about permission sets that grant elevated permissions.

The third is assuming SSO satisfies Salesforce’s requirements without confirming the identity provider configuration.

Finally, many organizations do not have a documented recovery process if an administrator loses a security key, replaces a laptop, or no longer has access to their primary authentication method.

All of these issues are fixable. They are just much easier to fix before the deadline than after.

Final Checklist

Before the deadline, confirm that you have completed the following:

• Reviewed all privileged users
• Reviewed profiles and permission sets
• Confirmed current authentication methods
• Registered phishing-resistant authentication where needed
• Tested production and sandbox logins
• Confirmed SSO configuration, if applicable
• Documented a recovery process for administrators
• Removed elevated access that is no longer needed

In Conclusion

Security requirements do not usually create much excitement, but this one is worth taking seriously.

It is also an opportunity.

Organizations can use this requirement to review privileged access, remove unnecessary permissions, and improve documentation around administrator access.

If you are already taking time to review authentication, it is worth taking a few more minutes to review who actually has elevated access in your Salesforce organization.

You will end up with a more secure org, a cleaner permission model, and fewer surprises the next time a security requirement changes.