Salesforce's security roadmap for 2026 mandates stricter Multi-Factor Authentication (MFA), particularly phishing-resistant MFA for administrator users. Recent guidance clarifies how password managers can now satisfy this requirement.
Clarification on Password Managers and Phishing-Resistant MFA
Salesforce updated its guidance in June 2026 to confirm that cloud-synced passkeys stored in FIDO2/WebAuthn-compliant password managers (such as 1Password, Bitwarden, and iCloud Keychain) meet the phishing-resistant MFA requirement. This update addresses prior confusion that suggested password managers were non-compliant.
What Changed?
Previously, password managers were often assumed to be non-compliant. The critical clarification is that cloud-synced passkeys, when stored in a FIDO2/WebAuthn-compliant password manager, fulfill the phishing-resistant MFA mandate. The key is the password manager's compliance with FIDO2/WebAuthn standards.
The Important Nuance: Passkeys vs. Credentials
It is crucial to understand that using a password manager solely for storing traditional credentials alongside a separate Time-based One-Time Password (TOTP) code (e.g., from Google Authenticator or Salesforce Authenticator push notifications) does not meet the phishing-resistant requirement. The password manager must be used to generate and store an actual FIDO2/WebAuthn passkey.
When a password manager is used to store a passkey, it registers with Salesforce as a Built-in Authenticator, similar to Touch ID or Face ID. This is distinct from a security key or a TOTP code.
Understanding Phishing-Resistant MFA
Traditional MFA methods like TOTP codes, push notifications, and SMS are vulnerable to phishing attacks. Phishing-resistant MFA leverages asymmetric cryptography to prevent interception.
When a user authenticates with phishing-resistant MFA, their device generates a key pair tied to the legitimate website's domain. If a fake phishing site attempts to intercept the authentication, the device recognizes the domain mismatch and refuses the login. This prevents users from being tricked even if they fall for a convincing fake website.
Therefore, methods like Google Authenticator codes and Salesforce Authenticator push notifications are no longer sufficient for privileged users due to their TOTP basis.
Compliant Methods for Phishing-Resistant MFA:
- Built-in authenticators: Touch ID, Face ID, Windows Hello.
- Hardware security keys: YubiKey and similar FIDO2/WebAuthn-supporting physical keys.
- Cloud-synced passkeys: Passkeys stored in FIDO2/WebAuthn-compliant password managers (e.g., 1Password, Bitwarden, iCloud Keychain).
Methods that do not qualify include Salesforce Authenticator (push notifications), Google Authenticator, Authy, Microsoft Authenticator (TOTP), and SMS codes.
Password Managers Not Explicitly Listed
If your organization uses a password manager not explicitly mentioned, verify its FIDO2/WebAuthn compliance. This is the primary criterion for meeting the requirement.
Affected Users and Enforcement
This requirement applies to users with the System Administrator profile, or those with the following permissions:
- Modify All Data
- View All Data
- Customize Application
- Author Apex
This applies to both direct UI logins and Single Sign-On (SSO) logins across production and sandbox orgs.
- Sandbox Enforcement: Started June 22, 2026.
- Production Enforcement: Starts July 1, 2026.
Users with privileged access who do not have a compliant MFA method registered may be blocked from logging in once enforcement is active for their instance.
SSO Logins
For SSO logins, Salesforce relies on your Identity Provider (IdP) sending standard signals like AMR (Authentication Methods Reference) and ACR (Authentication Context Class Reference) to confirm phishing-resistant MFA usage. If these signals are not correctly transmitted, Salesforce may prompt users to enroll in a compliant method or block them.
Consult with your IdP team to ensure the correct signals are emitted. Alternatively, privileged users can enroll in a Salesforce-native phishing-resistant method as a fallback.
Shared Accounts
Shared Salesforce logins cannot use a single passkey distributed among users. For shared accounts, the recommended approach is to store a passkey in a shared password manager vault (e.g., a 1Password shared vault) accessible by all authorized users.
Waiving the MFA Requirement
The "Waive Multi-Factor Authentication for Exempt Users" permission will no longer automatically exempt users after enforcement. For valid use cases requiring exemption (e.g., automated testing tools), contact Salesforce Support for approval.
Key Takeaways
- FIDO2/WebAuthn-compliant password managers storing passkeys satisfy Salesforce's phishing-resistant MFA requirement.
- Using a password manager for traditional credentials alongside TOTP codes does not meet the mandate.
- Phishing-resistant MFA uses asymmetric cryptography to prevent interception, unlike TOTP-based methods.
- Affected users include those with System Administrator profiles or specific elevated permissions.
- Enforcement for sandboxes began in June 2026, with production enforcement starting July 1, 2026.
- Verify your IdP's SSO signal transmission or ensure users have a Salesforce-native fallback method.
- Shared accounts should utilize shared password manager vaults for passkey storage.
- The "Waive MFA" permission is no longer a viable workaround; contact Salesforce Support for official exemptions.
Leave a Comment