If by this time you have already read and worked through Salesforce’s security roadmap for 2026, then you most probably have also done the required security updates for your org. If not, you’d better start now – updates in Production will start getting out on July 1st. And as we know, one of the biggest changes revolves around MFA, specifically around phishing-resistant MFA, as added protection for admin users.
Amid all this, there is one question kept coming up from users who rely on password managers: does your password manager setup actually count? The answer is yes. Salesforce updated its guidance in June 2026 to confirm that cloud-synced passkeys stored in FIDO2/WebAuthn-compliant password managers (like 1Password, Bitwarden, and iCloud Keychain) meet the phishing-resistant MFA requirement.
But if you’re confused about why earlier guidance implied the opposite, or you’re not sure whether your password manager setup actually qualifies, you’re not alone. In this article, we’ll break down what changed, what the nuance is, and what you actually need to do.
What Changed?
Salesforce updated its guidance in June 2026 to confirm that cloud-synced tools such as 1Password, Bitwarden, and iCloud Keychain can be used to store passkeys and meet the phishing-resistant MFA requirement. Before that update, password managers had been understood or assumed as non-compliant, which caused a fair bit of panic in the ecosystem, especially for partners and consultancies managing multiple orgs.
There’s a key clarification, though: cloud-synced passkeys are FIDO2-compliant and meet the phishing-resistant MFA requirement, provided the password manager itself is FIDO2/WebAuthn-compliant. It’s a small but critical distinction.
The Important Nuance
Before everyone breathes too deep a sigh of relief, here’s the thing to keep in mind:
Using a password manager strictly for credentials alongside a standard 6-digit TOTP code is not compliant under the phishing-resistant mandate. So, say for example, if your current setup involves 1Password auto-filling your Salesforce username and password, and then you open a separate authenticator app for a six-digit code, that does not count. In this case, the password manager is just the one doing credential management, and it is not acting as a passkey authenticator.
So, what counts? An example is using your password manager to generate and store an actual FIDO2/WebAuthn passkey. Taking the same password manager, for example, 1Password, and using that to generate and store an actual passkey (not a text code), that passkey then fully satisfies the phishing-resistant MFA requirement.
A passkey stored in your password manager registers in Salesforce as a Built-in Authenticator, which is the same category as Touch ID – worth noting that it is not a security key or OTP.
What Qualifies as Phishing-Resistant MFA?
We’re all familiar with traditional MFA such as TOTP codes, push notifications, and SMS. While these seem pretty safe, they can unfortunately still be intercepted by a convincing phishing page. Phishing-resistant MFA attempts to solve that using asymmetric cryptography. Authentication is tied to the exact domain of the legitimate site, so a fake page cannot intercept it.
When you log in, your authenticator device talks directly to the website’s server, generating a key pair that’s tied to the website’s exact domain. If it happens to be a fake phishing site, your device will then recognize that the domain doesn’t match the registered key and will refuse the login attempt.
The technology handles the verification, so you can’t be tricked even if you have fallen for the fake website (it’s scary how domains can really look like the real one at first glance).
This is why Google Authenticator codes (and even Salesforce Authenticator push notifications) won’t cut it anymore for admins. They’re TOTP-based, and TOTP can be intercepted.
Here’s the full list of compliant methods for phishing-resistant MFA:
- Built-in authenticators: Touch ID, Face ID, Windows Hello (these are free and already on most modern devices).
- Hardware security keys: YubiKey and similar physical keys that support FIDO2/WebAuthn.
- Cloud-synced passkeys: Passkeys stored in a FIDO2/WebAuthn-compliant password manager like 1Password, Bitwarden, or iCloud Keychain.
This means Salesforce Authenticator (push notifications), Google Authenticator, Authy, Microsoft Authenticator (TOTP), and SMS codes do not qualify.
What About Password Managers Not on Salesforce’s List?
Only three password managers were mentioned here. If your org is using other password managers, you may want to reach out to Salesforce Help to confirm, but the key criterion here is simply that it must be FIDO2/WebAuthn-compliant.
Who Are the Affected Users?
This requirement applies to all users with the System Administrator profile, or any one of these permissions: Modify All Data, View All Data, Customize Application, or Author Apex. It covers both direct UI logins and SSO logins, across both production and sandbox orgs.
Sandbox enforcement started June 22, while Production enforcement starts July 1, 2026. It seems there will be no grace period, so once enforcement reaches your org instance, privileged users without a compliant MFA method registered may be blocked at login.
What About SSO Logins?
For SSO logins, Salesforce relies on your Identity Provider sending industry-standard signals. AMR (Authentication Methods Reference) and ACR (Authentication Context Class Reference) confirm that a phishing-resistant MFA method was used at the IdP level. If those signals aren’t being passed correctly, Salesforce will either prompt the user to enroll in a compliant method directly or block them.
It would be good to check with your IdP team to confirm the right signals are being emitted. If they’re not, you have the option to either configure your IdP to pass phishing-resistant signals or have your privileged users enroll in a Salesforce-native phishing-resistant method like passkey or hardware key as a fallback.
What If You’re Using a Shared Account?
If multiple people share a Salesforce login, you cannot register a single passkey and distribute it among users. This is one of the trickier cases, especially for partners and consultancies. The recommended approach for shared accounts is to store a passkey in a shared password manager vault (for example, a 1Password shared vault) so that anyone with vault access can use it to authenticate.
Can Some Users Be Waived from This Requirement?
You might remember the “Waive Multi-Factor Authentication for Exempt Users” user permission, and think, why not just use this in the meantime? Unfortunately, this permission will no longer automatically exempt users from MFA after this security requirement’s enforcement on your org/instance. Users with this permission will still be prompted to enroll and use an MFA verifier at login.
To retain the exemption for valid use cases like automated testing tools, you’ll need to contact Salesforce Support for approval.
Summary
It’s a relief that password managers count, but keep in mind that’s only true if you’re using them to store an actual FIDO2 passkey, and not just credentials alongside a TOTP code. I believe this is the nuance that tripped most people up, and why the slight panic in the community earlier made sense.
If you haven’t set this up yet, the window is closing fast. Sandbox enforcement is already live, and Production rolls out July 1st. “Waive MFA” permissions aren’t a valid workaround, so get your passkey set up, check your SSO signals if relevant, and make sure shared accounts have a shared vault strategy.
You’ve got this. Just don’t wait until July 1st to find out.
