Most MFA advice tells you to flip the setting on, enrol everyone, and report 100% enrollment as proof you're secure. That advice is backwards. Enrollment tells you who registered a method once. It says nothing about whether a rep who loses a phone on quarter-end gets back in safely, whether your SSO provider proves MFA ran, or whether a departing contractor still holds a working authenticator.
For Multi Factor Authentication Salesforce work, I'd start with recovery, offboarding, and sandbox proof, then work backwards to enrollment. That's where Canadian B2B teams break things in practice, and it's where your RevOps audit should spend its time across Sales Cloud, Account Engagement, Service Cloud, and Revenue Cloud.
Why MFA Is Now Required for Salesforce Access
On February 1, 2022, Salesforce made MFA a contractual requirement for internal users signing in to a Salesforce user interface. The Salesforce MFA requirement notice covers username-and-password logins and SSO, including production and sandbox UI access. API-only logins are outside this requirement, but integration accounts still need a documented authentication plan.
MFA combines two different factor types, such as something you know (a password) and something you have (an authenticator approval or security key). Two passwords do not count as two factors. Adding a second factor substantially reduces the risk of account compromise, though it does not make an account immune to phishing or recovery failures.
A compromised Salesforce account can expose customer records, pipeline, marketing history, service cases, and reports. Adversary-in-the-middle phishing can target cloud identity sessions, so a password plus a typed code is only a baseline control. For broader context beyond CRM, security insights from RDE Technologies explain why adding a second factor matters.
Which Verification Methods to Allow and Why
Allow-list choices determine how users sign in and what support must handle. Enabling every method Salesforce supports can leave the team troubleshooting methods nobody selected for a clear reason.
Salesforce verification methods compared
| Method | Factor type | Phishing-resistant | Best fit |
|---|---|---|---|
| Salesforce Authenticator (push approval) | Possession, after password | No | Sales and service users with company phones |
| Built-in device authenticator (Face ID, Windows Hello) | Possession and inherence | Device-bound, confirm per device | Users with compatible laptops or phones |
| FIDO2 security key or passkey | Possession | Yes | Administrators, developers and privileged users |
| Third-party OTP app (TOTP) | Possession | No | Fallback where other methods are unsupported |
What each method costs you in support
Salesforce Authenticator fits sales and service users who need quick approval without typing or carrying extra hardware. Push approval is not phishing-resistant: a convincing fake login page can still prompt a user to approve a request. Keep that trade-off in view when assigning methods to privileged accounts.
Built-in authenticators such as Face ID and Windows Hello are tied to a device. Replacing a laptop means registering a new device, so hardware refreshes can add work to the support queue.
FIDO2 keys and passkeys bind the credential to the legitimate domain, preventing a fake page from reusing it. For system administrators, developers, and anyone with View All Data or Modify All Data, they are the phishing-resistant choice. TOTP apps provide a fallback when other methods are unsupported, but typed codes can be phished and manual entry can fail.
Practical rule: Require at least two registered methods per user. A second method gives someone another way to sign in if their primary device is lost, but enrollment alone does not prove that recovery will work.
Test FIDO2 and WebAuthn browser and operating-system support on the laptops your team uses before enforcement. A specification sheet cannot confirm how a particular device and browser will behave. API-only integration users do not face the UI prompt, so document a connected-app or certificate design for them. Make a separate MFA decision for Experience Cloud external users. For a plain-language factor primer to share with non-technical staff, account protection for home users explains the basics.
How to Enable MFA and Set Up SSO Paths
Work through these steps in order. Skipping ahead, especially on SSO signalling, is how teams enforce MFA on paper while half their logins bypass it.
Prepare before you touch a setting
Confirm edition, admin permissions, and a current sandbox. Verify you hold the permissions needed to change identity settings, and refresh a sandbox so testing reflects production profiles and permission sets. Changing authentication in production first leaves you debugging live logins.
Turn on MFA for direct UI logins in Setup, with enforcement off. Open the identity verification settings and enable MFA for direct logins, but don't enforce it until sandbox testing passes. This lets early users register methods without locking anyone out.
Select allowed verification methods to match your allow-list. Enable built-in authenticators and security keys if privileged users will use them, and leave unsupported methods off. Every method you enable becomes a method your support team must troubleshoot.
Fix the SSO gap most teams miss
- Confirm your identity provider sends the authentication signal Salesforce needs. Your IdP must pass AMR or ACR signals confirming MFA already ran during SSO. SSO on its own doesn't satisfy the requirement, and this is the most common gap in Canadian B2B orgs. If the signal is missing, Salesforce will prompt SSO users for its own second factor, which surprises everyone on go-live morning.
If your IdP can't prove MFA ran, your SSO users don't have MFA. They have a redirect.
- Set up break-glass administrator accounts before enforcement. Give each emergency account documented custody, a named owner, a strong method stored offline, and alerting on every use. Test that the account works. A break-glass account nobody has tested is a hope, not a control.
Prove it on your own account first
Register a method on your own admin account and complete a full login. Log out completely, then sign back in through both the direct path and the SSO path if you use both. You'll catch prompt wording, browser quirks, and registration dead ends your users would otherwise report on day one.
Save the configuration and schedule enforcement for the first rollout phase. Name a rollback owner who can disable enforcement without a meeting. Direct logins and SSO logins behave differently, so confirm both paths for each profile type, including sales, service, marketing operations, and administrators, before you announce a date.
One trade-off deserves honesty. Enforcing through your IdP gives users one consistent prompt across Salesforce, Account Engagement, and the rest of the stack, but it makes your IdP configuration the single point of failure. Enforcing inside Salesforce gives you direct control, but users may face a second prompt after SSO if signals aren't passed. Either design works. What doesn't work is assuming your current SSO setup already does this correctly without checking the signal.
How to Test MFA in a Sandbox Before Go-Live
MFA prompts fail without notice. Scheduled jobs, mobile logins, and integrations expecting a password-only flow can break without a visible error, so prove each path in a sandbox first. If your testers need the entry point, the Salesforce sandbox login guide covers access basics.
Sandbox MFA test matrix
| Test case | Path tested | Pass condition |
|---|---|---|
| Admin with direct login | Username and password, then MFA | Prompt appears and access succeeds |
| Sales rep via SSO | Identity provider with MFA signal | Salesforce recognises MFA ran and grants access |
| Service agent on new device | Device registration | New method registers and login succeeds |
| External user | Experience Cloud login | Expected MFA path works without blocking access |
| Integration user | API-only login | Integration runs unaffected by UI prompts |
| Expired code | OTP entry | Clear error appears and a new code works |
| Lost key | Recovery drill | Temporary code issued and replacement key registered |
Refresh the sandbox from production, mask customer personal data, and turn MFA on before anything else. Run each case in two browsers with one tester per profile type, logging browser, device, and timestamp. Then run the full recovery drill, time it, disable enforcement, and confirm rollback works. Exit only when every case passes, recovery meets your target, and no integration fails across a complete sales cycle.
Recovery, Offboarding and Failed Login Fixes
Write the recovery procedure down before enforcement day, because ad hoc recovery is where controls get waived under pressure. Name who may approve emergency access, set a target restore time for sales-critical users, and define how a replacement device is verified, for example through a manager call-back on a number already on file.
The recovery sequence to document and test
- Verify identity first: Confirm the person through a channel independent of the lost device before issuing anything.
- Issue a temporary verification code: Give short-lived access so the user can register a replacement method.
- Disconnect the lost method and terminate sessions: Remove the missing authenticator and end active sessions so a found phone can't be reused.
- Audit unusual activity: Check login history for the account before and after the reported loss.
- Log every action: Record approver, timestamp, and method disconnected for audit purposes.
Offboarding rules that close the loop
Disable the Salesforce user on the last working day, not at the next monthly cleanup. Remove permission sets, disconnect their verification methods, and rotate any integration credentials the departing person held or could view. Contractor accounts get end dates at creation, so access expires by default rather than by memory.
Failed login symptoms, causes and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Correct code rejected | Expired code or typing error | Check device clock, re-enter code, then issue a new one |
| Security key not recognised | Unsupported browser or device | Switch to a supported browser and confirm FIDO2 compatibility |
| Built-in authenticator missing on a new laptop | Built-in authenticators are device-specific | Register on that device or use a security key |
| User locked out after phone change | Lost authenticator | Verify identity, issue temporary code, disconnect lost method, register new device |
| Integration user suddenly blocked | Service account not covered by an approved exception | Use the documented exception path, not a permanent exemption |
| Spike in failed logins after enforcement | Policy-driven denial or IP restriction | Review login history, adjust IP ranges, roll back if criteria are breached |
100% enrollment doesn't prove recovery works. Only a tested drill, with a timed result, proves that.
Start triage in login history and sort each failure into one of five causes, which are enrollment error, unsupported browser or device, expired code, lost authenticator, or policy-driven denial. That sorting turns a noisy support queue into a short list of fixes.
Baseline and Weekly Metrics
Export login history and authentication-event data for the most recent full month before you start the inventory phase. Segment users by role, region, device, login method, and privileged status, so you can compare like with like after enforcement. For ongoing visibility into those events, event monitoring in Salesforce is worth setting up alongside this work.
For the first 30 days after each enforcement step, track weekly:
- Enrollment completion: Shows coverage across each user group.
- Challenge success rate: Shows whether enrolled users can sign in.
- Recovery events and lockouts: Shows where your procedure carries load.
- Anomalous logins and support tickets: Shows whether something is breaking.
Investigate every failed challenge against your five cause categories and compare each week against the baseline, not against a target you never measured. Save each weekly report with the phase it covers, so rollback decisions rest on evidence rather than whoever complains loudest.
Phased Rollout and User Communication Plan
Roll out by risk, not by org chart. Privileged accounts and users with broad access to accounts, opportunities, and customer data go first because a compromise there does the most damage and because that group is small enough to support closely.
Phased MFA rollout and exit criteria
| Phase | Scope | Exit criterion |
|---|---|---|
| 1. Inventory | Direct logins, SSO flows, sandboxes, integration and external identities | Signed-off list from RevOps and IT |
| 2. Privileged users | System administrators, developers and integration owners | 100% enrolled with phishing-resistant methods |
| 3. High-value data users | Users with broad access to accounts, opportunities and customer data | 100% enrolled, exceptions documented |
| 4. All internal UI users | Sales, marketing, service and executive accounts | 100% enrolled, zero unresolved exceptions at enforcement |
| 5. Review | Sandbox drills, recovery times and rollback criteria | Stable for 30 days after enforcement |
Each phase moves only when its exit criterion is met. If privileged users aren't fully enrolled with phishing-resistant methods, you don't have a delay, you have an unfinished phase.
Communication timeline that prevents lockout tickets
- 30 days out: Announce the change with the reason, the enforcement date, and the enrollment deadline.
- 14 days out: Send step-by-step enrollment instructions and brief managers so they can chase their own teams.
- Final week: Run office hours where users register methods live with an admin present.
- Day before: Send a reminder naming the support channel and the lost-phone procedure.
- First five business days: Give the support queue a named owner with authority to issue temporary codes.
Every message answers four questions, which are what changes, what the user must do, where to get help, and what happens if a phone is lost. Treat this as change management, not an IT notice, and the change management strategy guide offers a useful frame for sequencing those messages.
Run a formal exception process alongside the rollout. Each exception needs a named approver, a business reason, and an expiry date. Undocumented exceptions become permanent by neglect, and permanent exceptions for executive or service accounts are exactly where auditors look first.
Best Practices and Your Next Step
Set rollback criteria before enforcement and name who can trigger them. A rise in support volume, failed logins above baseline, or a business-critical integration failure can signal that the rollout needs to pause. The Salesforce supported verification methods documentation lists the methods your org can enable as you set those criteria.
Enrollment alone does not prove users can regain access. Review exceptions monthly and set expiry dates, run recovery drills quarterly, and review permission sets after org changes. Apply device or IP conditional access where feasible, while documenting how users can recover access if those controls block a legitimate login.
Enrollment shows coverage. Recovery and successful authentication show whether MFA works.
Start with an MFA readiness audit covering identity lifecycle, permission sets, SSO and direct-login paths, emergency access, and recovery evidence. MarTech Do's RevOps System Audit can assess those areas and provide a prioritised fix list. Visit MarTech Do to book an audit before your next enforcement date.
