Passwords and MFA

Module 2 of 5 in the shared chapter The Front Door: Logging In to Salesforce, chapter 2 of Securing Salesforce: Sharing and Visibility and part of the Identity and Access course. Each module stands on its own.

The question this module answers: How does a person prove who they are to Salesforce today, and why is a password no longer enough?

Think about the last time you took money out of a cash machine. You didn’t just walk up and type your PIN. You put in your bank card first. And if someone steals your wallet, the card alone isn’t enough either: they still need the PIN. Card and PIN. That’s always been two factors.

Now think about logging in to most websites. You type a username and a password, and you’re in. That’s one factor. Anyone who gets the password gets in.

That difference is what this module is about.

Three kinds of proof

There are three ways to prove you’re a particular human being:

• Something you know: a password or a PIN, something in your head.
• Something you have: something in your possession, like the bank card, or today, your phone or a security key.
• Something you are: something about you, like a fingerprint or your face.

A password on its own is one factor. Multi-factor authentication, MFA, means proving it with at least two different kinds. The card replaced by an app on your phone, or by the fingerprint reader on your laptop, is the same idea as the bank: one thing you know, plus one thing you have or are.

Click to enlarge

Passwords: still the first factor

Passwords haven’t gone away, so you still need to set their rules. In Salesforce, the password policies cover how long before a password expires, how many old passwords are remembered, the minimum length, how complex it must be, how many wrong attempts are allowed, and how long a user is locked out after that.

You can set those rules for the whole org, and you can set them on a profile. When a profile has its own password policies, Salesforce says they “override the organization-wide Password Policies for that profile’s users” (View and Edit Password Policies in Profiles (opens in a new tab), Salesforce Help, checked 2026-11-01). That matters, because not every user should have the same rules. The number of retries that’s right for a person at a keyboard can be exactly wrong for a program, and module 4 tells the story of what happens when it is.

MFA is no longer optional

When I first demoed MFA on a profile, it was a checkbox. You found the permission, turned it on for the profile, and the next time the user logged in, Salesforce asked them to connect Salesforce Authenticator. The app showed a temporary two-word phrase, you typed it in, and the account was linked.

That checkbox era is over. In Salesforce’s words, it “is enforcing Multi-Factor Authentication (MFA) for all employee logins, including direct UI and Single Sign-On (SSO), across both production and sandbox orgs.” Enforcement started in sandboxes on 10 July 2026 and in production on 20 July 2026, rolling out by release group until 3 September 2026. Some orgs were given a temporary extension, and Salesforce says it will email those orgs their new dates at least 30 days ahead, so check what applies to yours. Once it reaches your org, the org-wide setting that requires MFA for direct logins is on, and admins can’t turn it off. The old “Waive Multi-Factor Authentication for Exempt Users” permission no longer exempts anyone automatically; a real exception, such as an automated testing tool, now needs approval from Salesforce Support, and the permission’s API name is removed from the profile and permission set schema, so code or packages that still reference it stop compiling. Salesforce’s reason is the one you’d expect: to reduce the risk of account takeover “stemming from stolen credentials, credential stuffing, and phishing” (Prepare for MFA Enforcement for All Employee Users (opens in a new tab), Salesforce Help, published 2026-10-14, checked 2026-11-01).

Two groups aren’t forced. External users with Experience Cloud licenses, the customers and partners logging in to a site, keep MFA as a setting the admin chooses. Chatter External and Chatter Free users are excluded. Internal users who log in to an Experience Cloud site, such as an employee community, are still covered.

And notice the word logins. The requirement covers people logging in through the screens. Integrations that log in through the API with the JWT bearer or client credentials flows aren’t covered, so Salesforce’s Well-Architected guidance says to “protect those integrations with certificate management and IP restrictions instead” (Well-Architected: Trust (opens in a new tab), Salesforce Architects, checked 2026-11-01). Module 4 comes back to integration users.

The login page itself changed with the rollout too. It now shows the username field first, then the password or passkey field after the user clicks Log In. Mobile apps built on the Salesforce Mobile SDK keep working without code changes, but automated tests written for the old one-page login need updating (Prepare for MFA Enforcement for All Employee Users (opens in a new tab), checked 2026-11-01). If your team has scripts that log in to an org, check them.

Not every second factor is equal

Here’s where it gets more interesting. Salesforce now sorts the second factors by how strong they are:

• Phishing-resistant MFA: built-in authenticators, like Touch ID, Face ID and Windows Hello, and security keys. Salesforce calls these passkeys.
• Standard MFA: the Salesforce Authenticator app and other authenticator apps that show a code.

Why the difference? A code is something a person reads and types. If someone is tricked onto a fake login page that looks exactly like yours, they can type the code there too. A passkey is tied to the real site, so it doesn’t answer a fake one. And fake pages are getting much better: AI can now write a phishing email and build a convincing login page in minutes.

So the more a user can do, the stronger the proof Salesforce requires. Users with the System Administrator profile, or with Modify All Data, View All Data, Customize Application or Author Apex, must use phishing-resistant MFA, on direct logins and on single sign-on, in production and in sandboxes, on the same July 2026 schedule (Prepare for Phishing-Resistant MFA Enforcement for Privileged Users including Admins (opens in a new tab), Salesforce Help, published 2026-10-14, checked 2026-11-01). For everyone else, Salesforce “strongly recommends” phishing-resistant methods too, and recommends passwordless login with passkeys as “the fastest and most secure authentication flow available” (Prepare for MFA Enforcement for All Employee Users (opens in a new tab)).

I agree with both. The people who hold the keys to the whole building are exactly the people an attacker wants, and module 3 of chapter 1 made the same point about the CEO’s login.

Why a text message isn’t enough

Notice what’s missing from both lists: the code sent to you by text message, phone call or email. Salesforce sorts every login into three tiers, phishing-resistant, standard, and “Weak / No MFA”, and a password, a text message, a phone call and an email code all sit in the bottom tier. When a single sign-on login arrives with only those, Salesforce blocks it until the user enrolls a standard MFA method (Prepare for MFA Enforcement for All Employee Users (opens in a new tab), checked 2026-11-01).

That surprises people, because a text code feels like something you have. Here’s why it isn’t strong enough anymore.

It can be talked out of you. An attacker who already has your password starts a login, and Salesforce, or any site, sends you the code. Then the attacker calls or texts you, pretending to be IT: “We just sent you a code to verify your account. Can you read it back to me?” Or they keep sending login requests until you approve one just to make them stop. The code was real. The person asking for it wasn’t.

It goes to a phone number, not to you. If someone steals your phone, or talks your mobile carrier into moving your number to a new SIM card that they hold, your text codes go to them. Swapping a SIM like this needs no access to your phone at all. And once the codes arrive somewhere else, the “something you have” belongs to someone else.

It can be typed into the wrong page. Like any code you read and type, it works on a fake login page just as well as on the real one, and the fake page passes it straight on.

A passkey avoids all three. There’s nothing to read out over the phone, it isn’t tied to a phone number, and it only answers the real site. To use it on a stolen phone or laptop, someone would still need to unlock the device with your face, your fingerprint or your PIN. That’s the “something you have” working the way it’s supposed to: only you have it.

Click to enlarge

When the company does the checking: single sign-on

Most of the orgs I work with use single sign-on. People log in once at the company’s own identity provider, and that system vouches for them to Salesforce. In that case, the MFA happens at the identity provider, not in Salesforce. But Salesforce still needs to know it happened. It relies on the identity provider sending a standard signal about how the user proved who they are (the ACR and AMR values) in what it sends to Salesforce. Salesforce reads the signal in the same three tiers. If it says phishing-resistant or standard MFA was done, the user is let in with no further prompt. If it says only a password, a text message, a phone call or an email code, the user is asked to set up a Salesforce MFA method, so a missing or weak signal means people get asked twice. Setting that up is a topic for the Identity and Access course; here, just know that single sign-on doesn’t take you out of the MFA requirement.

Click to enlarge

How strong was the proof? Session levels

Every login ends with a session, the wristband from module 1. And the session remembers how strong the proof was. Salesforce gives each session a security level: Standard for a username and password and several other methods, and High Assurance when the user completed MFA. On a profile, you can set the session security level required at login, so users of that profile have to elevate before they get in.

Prove it again when the stakes rise: step-up

The newest idea at the door is that one strong login isn’t always enough for everything. Some actions are risky enough to check again. Since 2026, Salesforce asks users to verify their identity again to view and export reports; in its own example, “Salesforce asks you to use a passkey to export a report.” It was enforced in production from 1 July 2026, staggered over about 30 days. Users who log in through single sign-on can’t use their company’s MFA for this step; they use a Salesforce MFA method or a code sent by phone or email (Security-Related Product Updates to the Salesforce Platform (opens in a new tab), Salesforce Help, published 2026-09-08, checked 2026-11-01). Salesforce’s roadmap also adds step-up when a user’s behavior looks unusual.

Reports are where a lot of data leaves an org in one click. Asking for proof at that moment is defense in depth at the door.

Click to enlarge

Back up your authenticator

One piece of practical advice, from experience. I got a new phone, and one of my authenticator apps didn’t come across properly. I lost a few of my MFA accounts and had to work my way back in.

Now picture that with an admin, after phishing-resistant MFA is required, and no second way to prove who they are. Make sure every user, and every admin above all, has more than one registered method, and that you know how you’d recover a locked-out admin before you need to.

What an architect decides here

• Which password policies apply org-wide, and which profiles need their own.
• Which users count as privileged, and that each of them has phishing-resistant MFA, with a backup method.
• Whether to move everyone toward passkeys and passwordless login, ahead of the requirement.
• For single sign-on users, whether the identity provider sends the signal Salesforce needs.
• Which profiles should require a High Assurance session at login.
• How a locked-out admin gets back in.

Beyond the exam: what AI changes. The exam guides predate all of this: the Sharing and Visibility exam’s questions align to Winter ‘23, and the Identity and Access Management exam’s to Summer ‘23. But this is where AI shows up first at the front door. AI writes better phishing, so Salesforce moved its most powerful users to proof that can’t be phished, and it asks again before data leaves in a report. The trend is clear: stronger proof, asked for more often, where the stakes are highest.

Explore

• Prepare for MFA Enforcement for All Employee Users (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Well-Architected: Trust (opens in a new tab), Salesforce Architects (checked 2026-11-01)
• Prepare for Phishing-Resistant MFA Enforcement for Privileged Users including Admins (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Security-Related Product Updates to the Salesforce Platform (opens in a new tab), Salesforce Help (checked 2026-11-01)
• View and Edit Password Policies in Profiles (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Modify Session Security Settings (opens in a new tab), Salesforce Help (checked 2026-11-01)