--- title: "MFA: what is required and what satisfies it" url: "https://trailassembly.com/salesforce-mfa-requirements/" topic: "Admin and Permissions" published: "2026-09-16T12:11:53+00:00" updated: "2026-10-06T13:56:43+00:00" --- # MFA: what is required and what satisfies it **Every human who logs in to Salesforce directly needs a second factor, and Salesforce now enforces that rather than asking.** What counts is an authenticator app, a security key, or a built-in device authenticator. What does not count is an emailed code, a text message or a security question. Integration users are the real exemption, and single sign-on is not MFA, it just moves the obligation to your identity provider. ## What is actually required MFA for direct logins moved from a contractual requirement to a platform-enforced one in stages. Salesforce added it to the terms of service, then auto-enabled it, then removed the ability to switch it off. The position today: if a person types a username and password into a Salesforce login page, they are asked for a second factor, and no org-wide setting makes that go away. The requirement covers internal users of the core products. Experience Cloud customers and partners sit outside it. That does not mean leaving them on passwords alone, only that Salesforce is not forcing the change for you. ## What satisfies it - **Salesforce Authenticator.** Push notification with approve or deny, and it can be set to auto-approve from a trusted location. The lowest-friction option for most workforces. - **A TOTP authenticator app.** Any standard one generating six-digit codes. Works offline, no push dependency. - **A security key.** WebAuthn or U2F hardware keys. The strongest option and the right one for administrators and anyone with [Modify All Data](https://trailassembly.com/view-all-modify-all-explained/). - **A built-in authenticator.** Fingerprint or face recognition on a laptop or phone, registered through WebAuthn. What does not satisfy it: codes by email, codes by SMS, voice calls, and security questions. Those are identity verification methods, used when Salesforce challenges an unrecognised device or browser. Users treat them as the same thing and they are not, which causes a specific confusion worth heading off in your comms: being asked for an emailed code is device activation, not MFA, and it will continue happening alongside MFA. ## Exemptions, and how to apply one The exemptions are narrow and deliberate: - **Integration and API-only users.** No human, no interactive login, no second factor to provide. This is the main one. - **Automated test users** driving UI automation, which cannot answer a push notification. - **Users who only ever authenticate through SSO**, where the identity provider does the MFA. Applying one means assigning the permission that waives MFA for exempt users, through a permission set, to the accounts that qualify. Use a dedicated permission set named for the purpose, so an audit can see who is exempt and why. Then compensate. An exempt integration user with a password and no second factor is a credential waiting to be used, so take the password out of the picture: authenticate with [JWT](https://trailassembly.com/salesforce-oauth-flows-compared/) bearer or client credentials rather than a password, set login IP ranges on the profile, and use a Salesforce Integration licence where the user needs nothing but API access. ## MFA and SSO are different things Single sign-on federates authentication. One set of credentials, held at your identity provider, used across many systems. On its own that is still one factor, and a stolen password there now opens more doors than before, not fewer. MFA adds a second, different factor to that authentication. The two are complementary, and Salesforce’s position is straightforward: if your users reach Salesforce through SSO, enforce MFA at the identity provider, because Salesforce cannot see whether you did. Two settings connect them on the Salesforce side. You can require a high assurance session level for sensitive operations, so an SSO session that was not multi-factor gets challenged when it tries to open Setup or export a report. And you can prevent logins through the generic login page so nobody bypasses SSO with a password at all. Both are worth turning on, and they are what turns “we have SSO with MFA” from a claim into something you can demonstrate. ## Frequently asked **Can I make a specific profile skip MFA?** Only through the exemption permission, and only for genuinely exempt users. It is not a way to spare an executive the inconvenience. **What happens when someone loses their phone?** An administrator disconnects the registered method from the user record, and the user registers a new one at next login. Make sure more than one person can do that, or you have built a single point of failure into your access process. **Do sandboxes require MFA?** Sandbox logins follow the same identity rules as the production org they came from, so plan registration for anyone working in sandboxes too. **Does MFA apply to the CLI?** Authorising the `sf` CLI runs a browser login, so a human doing `sf org login web` completes MFA the normal way. A JWT-based CI connection does not, because there is no user session. --- Source: https://trailassembly.com/salesforce-mfa-requirements/ Trail Assembly — independent Salesforce write-ups.