Salesforce MFA Enforcement in 2026: What Admins Must Verify and Do

TL;DR

• Salesforce required MFA contractually from 2022, but the technical lockout for the core platform lands in mid-2026, not earlier.
• Two bars apply on two dates: standard MFA for all internal users (sandboxes 22 June 2026, production 20 July 2026), and phishing-resistant MFA for admins and privileged users (sandboxes 22 June, production 1 July).
• For admins, TOTP apps and push notifications no longer count. Only security keys, built-in authenticators, passkeys, and certificate-based auth qualify.
• The "Waive Multi-Factor Authentication for Exempt Users" permission stops exempting UI logins. API-only integration users are unaffected.
• You can verify exactly what your identity provider asserts from your own browser, without any access to the IdP admin console.

What You'll Learn

• The four phases of Salesforce's MFA programme and why 2026 is the one that matters
• How to check whether your org already complies, using Salesforce's own tools
• How to find every user in scope for each tier with verified SOQL
• Which verification methods and SSO signals actually satisfy the phishing-resistant requirement
• How to inspect your SAML or OIDC assertion without identity-provider admin access

The Problem

Most teams believe Salesforce "made MFA mandatory in 2022" and assume they are already done. That belief is the risk. The 2022 requirement was contractual, a clause in the agreement that nobody enforced at the login screen. What changes in mid-2026 is that Salesforce begins enforcing MFA technically: the org-wide setting locks on, the old exemption permission stops working for interactive logins, and any internal user without a sufficiently strong verifier is prompted to enrol or is blocked at login. On top of that, Salesforce adds a second, stricter tier for admins where the authenticator app most orgs rolled out in 2022 no longer qualifies.

Common Questions This Article Answers:

• What exactly is Salesforce enforcing in 2026, and on which dates?
• How do I check whether my org and my admins already comply?
• How can I verify what my SSO identity provider is telling Salesforce without IdP admin rights?

Quick Answer

From mid-2026 Salesforce enforces MFA in two layers. Every internal user (direct UI or SSO) must use multi-factor authentication, enforced in sandboxes from 22 June 2026 and production from 20 July 2026. Separately, every privileged user, meaning anyone with the System Administrator profile or the Modify All Data, View All Data, Customize Application, or Author Apex permission, must use a phishing-resistant method (security key, built-in authenticator, passkey, or certificate), enforced in sandboxes from 22 June and production from 1 July 2026. To comply, an admin should confirm the org-wide setting is on, run SOQL to find who falls into each tier, make sure every in-scope user has a qualifying verifier registered, and for SSO orgs confirm the identity provider sends a strong enough signal. Salesforce does not ask you to certify compliance; it simply enforces it.

How Salesforce got to hard enforcement

The programme has run in four phases, and conflating them is the most common source of confusion.

The first phase was the contractual requirement on 1 February 2022. Every customer became obligated to use MFA, but nothing blocked a login. The second phase was auto-enablement, rolled out across releases from Spring '23 through Spring '24, where Salesforce switched on the org-wide setting for direct logins but left admins able to turn it back off. The third phase, in Summer '24, was widely misread: rather than making the setting impossible to disable, Salesforce shifted to in-app notifications for the core platform, because adoption was already high. Admins who disabled MFA got repeating warnings, not a lockout.

The fourth phase is the one happening now. In mid-2026 Salesforce enforces MFA technically, brings sandboxes and SSO logins into scope, retires the main exemption, and introduces the phishing-resistant tier for privileged users. This is the first time the core platform genuinely prevents a non-compliant login rather than nagging about it.

Step 1: Check whether you already comply

Start with Salesforce's own self-assessment. The MFA Requirement Checker is a short questionnaire that asks how users access Salesforce, whether SSO carries a strong method, whether direct logins require a verifier on every login, and whether you rely on trusted devices or networks. It returns a pass or fail with next steps. There is nothing to submit; Salesforce explicitly does not require customers to certify compliance.

Next, check whether enforcement has already reached a given org. In Setup, open Identity Verification at [MyDomain]/lightning/setup/IdentityVerification/home. If "Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org" is selected and greyed out so you cannot deselect it, enforcement is active for that environment. If the box is still editable, you are pre-enforcement and should turn it on yourself, ideally in a sandbox first.

To see who is actually enrolled, install the Multi-Factor Authentication Dashboard from Salesforce Labs. It reports who is enrolled rather than who is not, so plan to customise the reports to surface the gap. The built-in Identity Verification Methods report shows which methods users are using.

Step 2: Find who is in scope

You cannot remediate a population you have not measured. Two groups matter: privileged users who need the phishing-resistant tier, and users who rely on the exemption that is going away.

Find privileged users with the queries Salesforce publishes in its own enforcement article. A user is in scope through either a profile or a permission set, so run both paths.

Where do you run these? Open the gear icon in the top right, choose Developer Console, and use the Query Editor tab along the bottom: paste a query, click Execute, and read the rows. If you would rather export the results to a spreadsheet, run the same query in Workbench (workbench.developerforce.com), log in to your org, and use Queries then SOQL Query. You need no special setup for either; the System Administrator profile already has access.

-- Privileged permissions via permission sets
SELECT AssigneeId, Assignee.Name, Assignee.Email, Assignee.Username,
       Assignee.IsActive, PermissionSet.Name
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsModifyAllData = true
   OR PermissionSet.PermissionsViewAllData = true
   OR PermissionSet.PermissionsCustomizeApplication = true
   OR PermissionSet.PermissionsAuthorApex = true

-- Privileged permissions via profiles
SELECT Id, Name, Email, Profile.Name, IsActive
FROM User
WHERE Profile.PermissionsModifyAllData = true
   OR Profile.PermissionsViewAllData = true
   OR Profile.PermissionsCustomizeApplication = true
   OR Profile.PermissionsAuthorApex = true

Find users holding the exemption that stops working. The "Waive Multi-Factor Authentication for Exempt Users" permission maps to the API field PermissionsBypassMFAForUILogins.

-- Waive-MFA holders via permission sets
SELECT AssigneeId, Assignee.Name, Assignee.Email, Assignee.Username,
       Assignee.IsActive, PermissionSet.Name
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsBypassMFAForUILogins = true

Missing one of the two paths, profile or permission set, is the usual reason an org that believes it is compliant still has blocked admins on enforcement day. If you would rather not run SOQL, the free User Access and Permissions Assistant performs the same audit through a UI.

What counts as phishing-resistant, and what does not

The phishing-resistant tier is narrower than "having MFA." It accepts methods bound to hardware and to the real Salesforce origin, so a fake login page cannot relay them: built-in authenticators such as Touch ID, Face ID, and Windows Hello; FIDO2 or WebAuthn security keys such as YubiKey; cloud-synced passkeys in a manager like 1Password, Bitwarden, or iCloud Keychain; and certificate-based authentication using x.509 client certificates. Passwordless login with passkeys qualifies too.

What does not qualify, in Salesforce's own words, is "Mobile TOTP applications, including Salesforce Authenticator." Push approvals do not qualify either. So an admin whose only registered method is the Salesforce Authenticator app has MFA but is not compliant for this tier. That single fact catches most orgs by surprise, because the authenticator app is exactly what was rolled out in 2022.

Step 3: Turn the methods on, then get them registered

Knowing what qualifies is not the same as having it switched on. Two separate things have to happen: an admin enables the verification methods at the org level, and then each user registers one against their own account. Neither happens automatically.

To enable the methods, go to Setup and open Identity Verification at [MyDomain]/lightning/setup/IdentityVerification/home. Under the heading that begins "Let users verify their identity with...", tick the methods you want to allow. For the phishing-resistant tier the two that matter are Security Keys (USB, Bluetooth, or NFC) and Built-In Authenticators (Touch ID, Face ID, Windows Hello). These are off in most orgs, so you are likely turning them on for the first time. Click Save, and do this in a sandbox before production so you can test a login.

To register a verifier, each user does it from their own account: click your avatar in the top right, choose Settings, then under My Personal Information open Advanced User Details, and use the Register links beside the method you want. Picking a security key or built-in authenticator triggers the browser's own passkey prompt, the user taps the key or uses Face ID once, and Salesforce stores the registration. There are two things a junior admin needs to know here. First, you cannot register a key on another user's behalf, so this step has to be handed to every in-scope user as an instruction, which is what makes it take calendar time rather than effort. Second, once MFA is enforced, any user who has not pre-registered is simply prompted to register at their next login, so nobody is permanently locked out for lack of a method, they are just interrupted until they enrol one.

The efficient sequence for the admin team is: enable the two methods in the sandbox, send a short instruction with the steps above, and ask every admin to register two methods each (a primary key and a backup) before the production date, so a single lost or forgotten key never becomes a lockout.

Verifying your SSO signal

For SSO logins, compliance is decided not by anything registered in Salesforce but by the signal your identity provider sends in the assertion. Salesforce reads the AMR (Authentication Methods Reference) and ACR (Authentication Context Class Reference) values and sorts each login into one of three tiers.

Phishing-resistant AMR values, which pass an admin, include cert, fido, fido2, hwk, passkey, phr, pki, smartcard, swk, and wia, among others. Standard MFA values, which pass a normal user but block an admin, include mfa, multipleauthn, okta_verify, publickey, and rsa. Weak values that block everyone until enrolment are pwd, sms, tel, and email.

The trap worth internalising: a plain mfa signal is enough for a regular user but blocks an admin, because mfa lives in the standard tier. An admin login needs a top-tier value such as fido2, hwk, or passkey. Salesforce notes these values are subject to change, so treat the lists as a guide and confirm against the live article before you act.

Verifying SAML and OIDC without identity-provider admin access

A common blocker is that the Salesforce admin and the IdP admin are different people, or even different organisations. You do not need the Okta, Entra, or Ping console to see what the IdP asserts, because the assertion passes through your own browser during your own login. You are allowed to inspect what is sent on your behalf.

For SAML, capture your own assertion. Install a browser extension such as SAML-tracer, or open the browser developer tools and select the Network tab with "Preserve log" enabled. Log in to Salesforce through SSO as yourself. Find the POST request to your Salesforce login or Assertion Consumer Service URL; it carries a form field named SAMLResponse. That value is base64-encoded XML. SAML-tracer decodes it for you, or you can copy it and base64-decode it. In the decoded XML, read <saml:AuthnStatement> then <saml:AuthnContext> then <saml:AuthnContextClassRef> for the ACR, and look for any attribute whose name contains amr or authnmethodsreferences for the AMR. Compare what you find against the phishing-resistant list. If the only value is mfa, you have confirmed an admin will be blocked even though the login "uses MFA."

For OIDC, use Login History first. Salesforce records the OIDC AMR in Setup under Login History, which needs Salesforce admin rights but no IdP access at all. That is the simplest route. If you want to read the token directly, note that in the standard authorization-code flow the id_token is exchanged server to server, so your browser never sees it; in implicit or hybrid flows the id_token appears in the URL fragment or a network response, and you can paste its middle segment into any JWT decoder to read the amr array and acr claim. For most OIDC setups, Login History is the answer.

For a zero-tooling sanity check, just attempt a login. Enable enforcement in a sandbox, then sign in as an in-scope admin through SSO. If Salesforce accepts the login without forcing you to enrol a native verifier, the signal cleared the bar. If you are prompted to register a Salesforce MFA method, the IdP signal did not qualify. This needs no extensions, no decoding, and no IdP access whatsoever, which makes it the most reliable check to hand to a non-technical admin.

Two cautions. A captured assertion can contain personal data, so do this on your own account and do not share the raw capture. And SAML ACR values are not yet recorded in Salesforce Login History, which is precisely why the browser-capture method matters for SAML where it is optional for OIDC.

Before each deadline: a short checklist

Before 22 June 2026, enable MFA and the phishing-resistant methods (which are off by default) in your sandboxes, run the scope queries above, and have every admin register at least two phishing-resistant methods so a lost key is not a lockout. Before 1 July, confirm every privileged user has a working security key or built-in authenticator in production and that admin SSO logins return a phishing-resistant signal. Before 20 July, confirm the org-wide setting is on, every interactive user has a registered verifier, and the Waive-MFA holders are either remediated or moved to API-only integration users. After each date, watch Login History for anyone still failing and recover them through the documented procedure.

Frequently Asked Questions

Q: Does Salesforce Authenticator satisfy the 2026 requirement?

A: It depends on the user. For a standard internal user, yes, Salesforce Authenticator satisfies the MFA requirement. For a privileged user or admin, no. Salesforce states that mobile TOTP applications, including Salesforce Authenticator, do not meet the phishing-resistant bar. Admins need a security key, a built-in authenticator such as Touch ID or Windows Hello, a passkey, or certificate-based authentication.

Q: We enforce MFA at our identity provider already. Are we compliant?

A: Only if the IdP transmits a recognised signal. Salesforce now inspects the AMR or ACR value on each SSO login. If the value indicates strong MFA the login passes; if not, the user is prompted to enrol a native Salesforce verifier. For admins specifically, the signal must indicate a phishing-resistant method, so a generic mfa signal is not enough.

Q: How do I check what my IdP sends without access to the IdP console?

A: Capture your own login. For SAML, use a browser SAML-tracer or the developer tools Network tab to read the SAMLResponse, base64-decode it, and inspect AuthnContextClassRef and any AMR attribute. For OIDC, read the AMR in Salesforce Login History. As a no-tooling check, attempt an admin SSO login in a sandbox with enforcement enabled and see whether Salesforce forces native MFA enrolment.

Q: What happens to integration users and API logins?

A: The requirement targets interactive UI and SSO logins. System integration logins through the API are not affected, and the "Waive Multi-Factor Authentication for Exempt Users" permission continues to apply only to those API-only users. A human signing into an integration account through the UI, however, is in scope.

Q: What if an admin gets locked out?

A: Another org admin can generate a temporary identity verification code, disconnect the old method, and have them re-register. If there is no second admin, recovery runs through Salesforce Support, which is why registering at least two phishing-resistant methods per admin in advance matters. Note that a sandbox refresh wipes MFA verifiers, so plan ahead before refreshing.

Key Takeaways

• 2026 is the real deadline: the contractual requirement existed since 2022, but the technical lockout for the core platform is mid-2026.
• Two tiers, two dates: standard MFA for everyone, and phishing-resistant MFA for admins where authenticator apps no longer count.
• Measure scope with SOQL: run both the profile and permission-set queries, or blocked admins will surface on enforcement day.
• Verify the signal, not the intent: an SSO login that "uses MFA" can still block an admin if the AMR value is only mfa.
• You do not need IdP admin to verify: your own browser capture or Salesforce Login History shows exactly what the identity provider asserts.

What's Next?

Recommended Reading:

• Why Salesforce Health Cloud Needs Its Own Security Review
• Mapping Salesforce security to NZISM, the NZ Privacy Act and ISO 27001

Action Items:

1. Run the privileged-user and Waive-MFA scope queries today and share the lists with the affected teams.
2. Enable the phishing-resistant methods in a sandbox and have every admin register two of them.
3. Capture one admin SSO login and confirm the asserted signal is phishing-resistant, not just mfa.

Resources & References

• Prepare for MFA Enforcement for All Employee Users (Salesforce Help, 005321561)
• Prepare for Phishing-Resistant MFA Enforcement for Privileged Users including Admins (005321563)
• Security-Related Product Updates to the Salesforce Platform (005317465)
• MFA Requirement Checker
• Everything You Need to Know About MFA for Salesforce Orgs (000389361)
• Verification Methods for Multi-Factor Authentication
• AMR values, RFC 8176