Enforcement is complete. Salesforce rolled out its new authentication requirements to production orgs by release group from 20 July 2026 onwards, and on 3 September 2026 the last group had its turn. Salesforce MFA being mandatory in 2026 is no longer an announcement, then. It is the current state of your own org. This article covers what applies and how to check you meet it.

What now applies in every org

Two requirements run alongside each other and followed the same calendar: preview sandboxes from 10 July 2026 and production from 20 July 2026, rolled out by release group through 3 September 2026.

  • MFA for all employee accounts. Every internal user who logs in, through the user interface or single sign-on, has to use an MFA method.
  • Phishing-resistant MFA for privileged users. For that group, the ordinary methods are no longer enough.

A user falls into the second category through the System Administrator profile, or any of the Modify All Data, View All Data, Customize Application and Author Apex permissions. In practice that is wider than your admins alone: a developer or consultant holding Author Apex belongs to it too.

Which methods still count

At Salesforce, phishing-resistant means built on FIDO2 and WebAuthn. These methods qualify:

  • security keys, such as a hardware token;
  • built-in authenticators, such as Windows Hello, Touch ID and Face ID;
  • passkeys synced through a password manager;
  • certificate-based authentication using an x.509 client certificate.

What no longer counts for privileged users: the Salesforce Authenticator app, codes from a TOTP app such as Google Authenticator or Microsoft Authenticator, and verification by SMS or email. A privileged user without a valid method is locked out until they register one. There is no grace period.

Three things that fail quietly

  • Single sign-on does not cover this automatically. If your org signs in through an external identity provider, you are only exempt when that provider actually passes the MFA signal using the ACR or AMR standard. If not, Salesforce asks for verification itself.
  • The Waive Multi-Factor Authentication for Exempt Users permission no longer exempts anyone. Users holding it are still prompted to enrol. If you need a genuine exception, for test automation for instance, it has to be approved through Salesforce Support.
  • Integrations run into the network block. Salesforce blocks connections made through anonymising VPNs, proxies and IP addresses with a poor reputation, and since 24 April 2026 that covers all connected app and API traffic too. The account is then frozen and its OAuth refresh tokens revoked. Recovering takes more than unfreezing the account: the connected app has to be authorised again.

On top of that, Salesforce can ask for additional verification on sensitive actions when it detects unusual behaviour, exporting a report being the clearest example. So make sure every user has at least a registered verification method or a current email address on file, or such an export stalls the moment the system sees something out of the ordinary.

How to check this now

Start with the list of privileged users and ask yourself, user by user, whether those permissions belong there. Author Apex or View All Data granted temporarily at some point now raises that person’s login requirement too. Next, look at which verification methods are registered per user, and whether your service accounts and integrations still have a valid authorisation path.

Would you rather have this reviewed systematically than wait until someone is locked out? Our consultancy works through how permissions and authentication are set up in your org and records what does and does not hold up. If you also run public portals, look at the permissions of your Experience Cloud guest users: a different review, with a different risk.

Not sure whether your org meets the requirements? Get in touch and we will work through it with you.