Multi-Factor Authentication (MFA) is one of those Salesforce features that sounds simple on paper: add an extra step at login, improve security, job done.
In reality, most admins quickly discover that MFA isn’t really a “feature implementation” project – it’s a people, process, and identity project wrapped in a security checkbox.
Yes, Salesforce makes it relatively easy to enforce MFA. But making it work smoothly in a live org with real users, real integrations, and real identity flows? That is where things get interesting.
There is also a renewed sense of urgency here. Salesforce is actively enforcing MFA adoption more broadly, with org-wide enforcement rolling out in phases. Sandboxes start June 22, 2026, and production environments begin July 20, 2026.
On top of that, phishing-resistant MFA is becoming required for highly privileged users, including users with permissions such as Modify All Data, View All Data, and Customize Application. For these users, sandbox enforcement begins June 22, 2026, and production rollout begins July 1, 2026.
In other words, this is not just “best practice” anymore. The platform is enforcing it.
This article walks through some of the most common mistakes admins make when rolling out MFA, and how to avoid turning a security win into a support headache.
1. Treating MFA Like a One-and-Done Switch
It’s tempting to think of MFA as something you simply “turn on” and move on from. But that mindset is where many problems start.
MFA isn’t a deployment – it’s a behavioural change. Users need to understand it, adopt it, and continue using it every time they log in.
If you switch it on and assume the job is done, you’ll likely see:
- A spike in login-related tickets.
- Confused users bypassing instructions.
- Shadow workarounds (yes, they happen).
A better approach is to treat MFA like a rollout journey, not a configuration step. Making the case for MFA and communicating the benefits beforehand can significantly help with stakeholder buy-in and user adoption.
2. Poor Communication (or No Communication at All)
This is probably the most underestimated part of any MFA rollout.
From a user’s perspective, MFA can feel like: “Why is Salesforce suddenly asking me to use my phone to verify my login?” Or, “Why do I have to verify my identity EVERY TIME?”
If you don’t explain:
- Why MFA is being introduced.
- When it will be enforced.
- How users should set it up.
…then expect confusion and frustration.
Good communication is simple, human, and repetitive. One email is not enough. Think onboarding guides, reminders, and in-app guidance where possible. If you don’t have the resources or capacity to create training material yourself, Salesforce has a video you can share here.
It can also be beneficial to have a dedicated channel during MFA implementation and onboarding for announcements, queries, and support requests.
3. Forgetting About Backup Authentication Options
This is one of those mistakes that only becomes obvious when something goes wrong.
Users lose phones. Authenticator apps get reset. People upgrade devices and forget to migrate their settings. It’s normal.
If you haven’t planned for backup authentication methods, your admin team becomes the emergency reset button.
That might sound manageable until you’re dealing with dozens of lockouts during peak business hours!
Make sure there are:
- Clear recovery processes.
- Documented admin steps for resets.
- Backup methods communicated to users in advance.
Assume primary authentication will fail at some point – it’s not pessimistic, it’s realistic.
Salesforce has a very helpful article to help you resolve MFA access issues here.
4. Ignoring Integrations and “Non-Human Users”
Admins often focus on people and forget everything else that logs into Salesforce.
But in most orgs, some of the most important logins aren’t human at all:
- Integration users
- Middleware tools
- Data loaders
- Marketing automation systems
- Custom API connections
If MFA or related session policies affect these without proper planning, you don’t get a polite error; you get broken business processes.
Always review:
- Connected apps
- External Client Apps
- API authentication methods
- Integration user setup
If something logs in without a person, it still needs to be part of your MFA conversation.
5. Over-Engineering Security from Day One
When you first enable MFA, it can be tempting to go “all in” with strict policies: frequent re-authentication, tight session controls, and minimal exceptions.
The intention is good. The outcome is often…less good.
Users don’t experience security as a concept. They experience friction.
Too much friction leads to complaints, workarounds, and increased admin overhead.
MFA does not work in isolation. It works alongside other security settings such as login hours, IP ranges, and session timeout policies. While security is essential, it should not come at the expense of usability. If the login experience becomes too frustrating, users will struggle to engage with Salesforce effectively.
Make sure you thoroughly test the full login journey, not just the MFA setup itself, to ensure the user experience remains smooth and predictable.
The goal is for security to feel invisible where possible. Strong, consistent protection is important, but it should not constantly interrupt people as they try to do their work.
6. Ignoring SSO and Identity Architecture Alignment
This is a big one, especially in more mature orgs.
In many Salesforce environments, authentication is handled through Single Sign-On (SSO) and an identity provider like Okta or Azure AD.
If MFA decisions are made only inside Salesforce without considering the wider identity architecture, things can get messy quickly:
- Users may be prompted for MFA twice.
- Authentication policies may conflict between systems.
- Security controls may be inconsistent across apps.
The key question to ask is: where should MFA actually be enforced?
In many cases, the identity provider should own MFA, with Salesforce trusting that authentication. In others, Salesforce MFA still plays a role. But it needs to be intentional, not accidental.
7. Overlooking Phishing-Resistant MFA for Admins
Not all MFA is created equal.
SMS codes and basic authenticator prompts are certainly better than passwords alone, but they are not designed to withstand modern phishing attacks.
This becomes even more important for admin accounts. Phishing-resistant MFA methods, such as hardware security keys or platform-based cryptographic authenticators, significantly reduce the risk of credential theft through social engineering because they bind authentication to a trusted device and verified origin.
However, in many orgs, admin accounts still end up using whichever MFA method was easiest to roll out during the initial implementation. That approach is understandable, but it is also risky.
If an attacker compromises a standard user account, the impact is disruptive. If they compromise an admin account, the impact is catastrophic.
Admin accounts should be protected by stronger authentication by design, not convenience.
And this is no longer just best practice. Salesforce is enforcing phishing-resistant MFA for highly privileged users, including those with permissions such as Modify All Data, View All Data, and Customize Application, starting in June.
8. Not Testing Real-World User Scenarios
Testing MFA in a sandbox with a single admin login is not the same as testing it in production.
Real users behave differently. They:
- Switch devices
- Travel
- Use mobile apps
- Log in under pressure
- Forget instructions (more often than we’d like)
If you don’t test these scenarios, you only discover issues after enforcement begins.
A proper rollout includes testing for:
- Mobile-first users
- High-travel roles
- Shared device environments
- High-volume service teams
In other words: don’t just test the system: test the humans using it.
9. Not Delegating MFA Management Tasks
This tends to show up after go-live, when the helpdesk tickets start rolling in.
MFA issues are rarely complex, but they are urgent. A user cannot log in, they have a new phone, or they have lost access to their authenticator app. Suddenly, everything stops, and if only Salesforce Admins can fix it, you have created an unnecessary bottleneck.
The good news is that Salesforce does allow you to share the load safely.
Rather than keeping all MFA support locked behind full admin access, you can assign the Manage Multi-Factor Authentication in User Interface permission to trusted support staff. This might be your Service Desk team, Tier 1 support, or experienced power users who already help with day-to-day user issues.
With this permission, they can:
- Generate temporary verification codes for users who are locked out.
- Disconnect or reset authentication methods when users change or lose devices.
- Review the identity verification activity to understand what is happening.
- Use reports to see which authentication methods users have registered.
- Create list views to help identify users who may need MFA support.
In other words, they can handle the majority of “I can’t get into Salesforce” scenarios without needing full administrative access.
This is a small change, but it makes a big difference. It reduces pressure on admins, speeds up user recovery, and makes MFA support feel like a shared responsibility rather than a single point of failure.
10. Not Disconnecting Old, Replaced, or Invalid Identity Verification Methods
This one often gets overlooked because everything looks fine on the surface. The user has MFA enabled, they have previously registered a method, and nothing appears broken until they try to log in.
The problem comes when that authentication method is no longer usable. A phone gets replaced, an authenticator app is reset, or a security key is lost. In some cases, users simply switch to a new method, but the old one is still sitting there in their profile.
If those outdated methods are not disconnected, users can end up stuck in a loop where Salesforce keeps prompting for a method they can no longer access. From their perspective, MFA is “broken”, when in reality the configuration just needs a clean-up.
Admins should actively disconnect verification methods when:
- A user loses access to their existing authentication method.
- A user replaces their device and moves to a new method.
- An existing method stops working and needs to be re-registered.
- A user leaves the organization, and their account needs to be fully cleaned up.
Taking this step ensures that users are always working with current, valid authentication methods and removes confusion during login attempts.
It is a simple housekeeping task, but it makes a big difference. Keeping identity verification methods up to date helps prevent unnecessary lockouts, reduces support tickets, and ensures MFA continues to work the way it was intended.
Summary
MFA is one of the most effective security controls available in Salesforce, but it’s also one of the easiest to underestimate.
Most challenges don’t come from the technology itself – they come from assumptions:
- That users will adapt instantly.
- That integrations won’t be affected.
- That identity architecture can be ignored.
- That configuration equals completion.
In reality, successful MFA implementation is about balancing security with usability and configuration with communication.
Get that balance right, and MFA becomes what it should be: a strong, reliable security layer that users barely have to think about.
