Salesforce is splitting its MFA requirements into two tiers, and if you or anyone on your team has admin-level access, the change is more significant than most upgrade notices suggest. The authenticator app you've been using — Google Authenticator, Salesforce Authenticator, Authy — will no longer satisfy the MFA requirement for users after July 1, 2026 in production (June 22 in sandboxes). Admins who haven't switched to a phishing-resistant method by that date will be blocked from logging in until they do.
We've been working through this with our own team and across client accounts over the past several weeks, and the setup is more manageable than it sounds, but there are a few places where Salesforce's guidance is easy to misread.
What "Phishing-Resistant MFA" Means And Why TOTP Doesn't Make the Cut
The standard MFA most Salesforce admins use today is TOTP: a time-based one-time password from an authenticator app. You log in, get prompted for a code, type in the six digits, and you're in. It's better than no MFA. It is not, however, phishing-resistant.
Here's how an attack works: a bad actor sets up a fake Salesforce login page. You enter your credentials. The fake page relays them to the real Salesforce in real time, then relays the TOTP prompt back to you. You type in your code. The attacker captures it and uses it before it expires (typically within 30 seconds). From Salesforce's perspective, the login succeeded normally.
Phishing-resistant MFA closes this attack vector at the protocol level. A WebAuthn credential, which includes passkeys stored in a password manager, is cryptographically bound to the specific domain where it was registered. If someone lands on a fake login page, the credential simply doesn't activate. There's no code to intercept, and no window of time to exploit.
Salesforce has confirmed in their knowledge articles (KA 005321561 and 005321563, updated May 2026) that TOTP apps do not meet the new phishing-resistant requirement even though they continue to qualify as standard MFA for non-admin accounts. This is not a gray area. If the account has admin permissions and the only registered MFA method is an authenticator app, that account will be blocked at the July 1 enforcement date.
Who This Actually Affects
Salesforce defines a "privileged user" as any user who has the System Administrator profile, or any of the following permissions:
- Modify All Data
- View All Data
- Customize Application
- Author Apex
For Salesforce partners and implementation consultants, this covers virtually every admin-side login used during implementations and managed services work. Our own team's shared admin logins all fall squarely in the privileged user bucket, and the July 1 production deadline is the one that matters.
For clients, the population of affected users is often broader than it first appears. Permission sets that grant Modify All Data or Author Apex are sometimes assigned as part of a project-era change and never pulled back. It's worth auditing which users actually carry these permissions before assuming the change only affects a handful of org admins.
Three Compliant Options And How to Choose
Salesforce accepts three categories of phishing-resistant MFA for privileged users, and the right choice depends almost entirely on whether the account is shared.
Built-in authenticators (Touch ID, Face ID, Windows Hello) deliver the smoothest login experience and require no additional hardware or apps. The limitation is that they are device-bound: a credential registered from one person's MacBook cannot be used by a teammate on a different machine. For individual accounts on personal devices, this is the simplest path. For shared admin accounts, it doesn't work — one person's biometric registers, and no one else can use it.
Hardware security keys (YubiKey and similar FIDO2 devices) are also device-bound, but the physical token can change hands. This makes them a reasonable option for high-compliance environments — HIPAA, SOC 2, financial services clients — where there's a security argument against cloud-synced credentials. The tradeoffs are cost, the risk of physical loss, and the coordination overhead that comes with managing physical tokens across a distributed team.
Passkeys stored in a FIDO2-capable password manager (Bitwarden, 1Password, and others) are synced passkeys that live in the vault and travel with the vault's access controls. Salesforce has confirmed via Product Management that a passkey stored in a FIDO2/WebAuthn-capable password manager satisfies the phishing-resistant MFA requirement. When Bitwarden registers a passkey in Salesforce, it presents as a WebAuthn Security Key in the registration flow, which is the compliant credential type.
For partner teams managing shared admin logins, the Bitwarden path is the right call. It's low cost, shareable via Organization collections, sync across every teammate who has vault access, and don't require any physical hardware to buy, ship, or track. Every shared Salesforce admin account in our practice is moving to this method, and each org takes about ten minutes to set up.
The SSO Trap: Why "We Use Okta" Doesn't Automatically Mean You're Covered
This is the part of Salesforce's guidance that has generated the most confusion in client conversations, so it's worth pausing on.
If an organization logs into Salesforce through an SSO provider (Okta, Azure AD/Entra, or a similar IdP) Salesforce evaluates authentication strength based on AMR (Authentication Methods References) signals that the IdP passes in the SAML assertion, not based on what authentication method the user completed at the IdP.
The non-obvious detail: the AMR signal values passkey and webauthn are classified by Salesforce as standard MFA, not phishing-resistant. This means an SSO user who authenticated with a passkey at their IdP will still fail the phishing-resistant check for privileged Salesforce access unless the IdP is configured to send a different, recognized signal.
The AMR/ACR values Salesforce recognizes as phishing-resistant include fido, fido2, hwk, pin, sc, smartcard, and several others. Whether any given IdP sends one of these depends on its specific configuration, not on what authentication method the end user sees on screen.
In practice, this means that when a client says "we use SSO with MFA enabled," that's not the same as "our privileged Salesforce users are covered." We've already reviewed several SSO configurations that use phishing-resistant authenticators at the IdP level but send signal values Salesforce doesn't recognize for privileged access. Those users will be blocked on July 1 unless the IdP configuration is updated and the fix happens on the identity provider side, not in Salesforce setup.
If you manage SSO clients, audit the AMR signal values their IdP is actually sending before assuming they're compliant.
How to Register a Salesforce Passkey Using Bitwarden
The steps below assume the Bitwarden browser extension is installed and active, and that the shared Salesforce admin login already lives in a Bitwarden Organization collection, not a personal vault. If it's in a personal vault, move it to a shared collection before registering the passkey. Otherwise the registered credential stays attached to a personal vault item that teammates can't access.
Step 1: Enable passkey support in the org
Log in as a Salesforce admin, go to Setup, and search for Identity Verification. Enable "Let users verify their identity with a physical security key (U2F or WebAuthn)." While you're there, optionally enable "Allow passwordless login with passkeys" for a smoother future login flow. Save.
Step 2: Navigate to Advanced User Details
Click your avatar in the top right → Settings → Advanced User Details. Scroll to find the "Security Key (U2F or WebAuthn)" row and click Register.
Step 3: Register the passkey via Bitwarden
Salesforce will re-authenticate you, then display the passkey registration screen. Bitwarden will pop up and ask which vault item to associate the passkey with, then select the Salesforce org login. Give the passkey a name, save, and Bitwarden stores the credential. The "Register" button on the Advanced User Details page changes to "Remove," confirming the passkey is active.
Step 4: Confirm the vault item is in a shared collection
Open Bitwarden, find the Salesforce item, and verify it lives in an Organization collection rather than My Vault. If it's in your personal vault, edit the item, change ownership to the Organization, assign it to the correct shared collection, and re-register the passkey so it's attached to the updated item.
Step 5: Test the login with a second team member
Have a colleague log in to the org from their own machine. When Salesforce prompts for MFA, Bitwarden should surface the passkey automatically. If it doesn't appear, clicking the Bitwarden extension icon manually will trigger the passkey prompt. Once a second person confirms successful access, you're done with that org.
What to Do Before July 1
For any Salesforce account carrying System Administrator access or any of the privileged permissions listed above, the production deadline is July 1. Sandboxes moved to enforcement on June 22, so if you're already hitting MFA prompts in a sandbox that your authenticator app can't satisfy, that's this change and production is a few weeks behind.
The most efficient path for a team managing multiple client orgs is to work through each shared admin account, confirm the Salesforce login lives in a Bitwarden Organization collection, and register a passkey using the steps above. For SSO clients, pull the AMR signal configuration from the IdP before assuming they're covered. The check takes 20 minutes and has caught issues we wouldn't have otherwise found until after enforcement.
If you run into questions about whether specific permission assignments put a user in the privileged bucket, need help auditing SSO signal configuration, or are working through an org where shared credentials add complexity to the setup, we're happy to dig into it.
.png)
