What's Changing

Salesforce is enforcing phishing-resistant Multi-Factor Authentication (PR-MFA) for all privileged users. This goes beyond the standard MFA you may already have in place. Tools like Salesforce Authenticator, Google Authenticator, Authy, and SMS codes no longer qualify for privileged users under this new requirement.

‍

The only accepted methods going forward are:

Built-in authenticators - Touch ID, Face ID, Windows Hello, Android biometrics

Hardware security keys - YubiKey or any FIDO2/WebAuthn-compatible key

Cloud-synced passkeys - via 1Password, Bitwarden, or iCloud Keychain (confirmed compliant as of June 2026)

‍

Enforcement Timeline

Environment

Enforcement Start

Sandboxes: June 22, 2026 (rolling ~7 days)

Production: July 1, 2026 (rolling ~30 days)

There is no grace period. Once enforcement reaches your org instance, privileged users without a compliant MFA method registered will be blocked at login.

‍

Who's Affected

You are in scope if you have any of the following in a production or sandbox org:

‍

• System Administrator profile
• Modify All Data permission
• View All Data permission
• Customize Application permission
• Author Apex permission

‍

This applies whether those permissions are assigned via Profile or Permission Set.

Step 1: Identify Your Affected Users

Run these SOQL queries in Developer Console or Query Editor to pull your full list.

Do this before anything else.

Via Profiles

SELECT Id, Name, Email, Profile.Name, IsActive
FROM User
WHERE Profile.Name = 'System Administrator'
  OR Profile.PermissionsModifyAllData = true
  OR Profile.PermissionsViewAllData = true
  OR Profile.PermissionsCustomizeApplication = true
  OR Profile.PermissionsAuthorApex = true

‍

‍

Via Permission Sets

SELECT AssigneeId, Assignee.Name, Assignee.Email, Assignee.Username,
      Assignee.IsActive, PermissionSet.Name
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsModifyAllData = true
  OR PermissionSet.PermissionsViewAllData = true
  OR PermissionSet.PermissionsCustomizeApplication = true
  OR PermissionSet.PermissionsAuthorApex = true

‍

Watch out for shared/service accounts, integration users with elevated permissions, and Permission Set Groups. These are the most common sources of post-enforcement lockouts and require an interim access strategy since passkeys are device-bound and cannot be shared.

‍

Step 2: Enable phishing-resistant methods in your org (admin task)

Before users can register passkeys, you need to enable the verification methods at the org level. Do this in Sandbox first.

‍

1. Go to Setup → Identity Verification
2. Enable Built-In Authenticators
3. Enable Security Keys (U2F/WebAuthn)
4. (Recommended) Toggle on Allow passwordless login with passkeys for a faster login experience

‍

Once enabled, these options are available to all users in the org. There is no way to restrict them to only privileged users.

‍

Step 3: Register Your Passkey (Every Privileged User)

Each privileged user must complete this themselves on their own device.

This cannot be done centrally.

Option A: Built-In Authenticator (Touch ID, Windows Hello, Face ID)

1. Log in to Salesforce → click your avatar → Settings
2. Navigate to Advanced User Details
3. Find Built-In Authenticators → click Register
4. When Salesforce prompts you, click Register
5. Authenticate with your biometric or PIN when your browser or OS prompts you
6. Give it a recognizable name (e.g. MacBook Pro - Touch ID) → Save

Option B: Hardware Security Key (YubiKey, etc.)

1. Log in to Salesforce → click your avatar → Settings
2. Navigate to Advanced User Details
3. Find Security Key (U2F/WebAuthn) → click Register
4. Re-authenticate when Salesforce prompts you
5. Insert or tap your security key when prompted
6. Name the key (e.g. YubiKey 5) → Save

‍

Cloud-synced passkeys stored in 1Password, Bitwarden, or iCloud Keychain are also compliant as of June 2026, provided the password manager is FIDO2/WebAuthn-compliant.

‍

Step 4 : If You Use SSO, Don't Assume You're Safe

This is the most commonly misunderstood aspect of this change. SSO does not automatically exempt you.

For Salesforce to accept your IdP's MFA as phishing-resistant, your Identity Provider must transmit the correct AMR (Authentication Methods Reference) or ACR (Authentication Context Class Reference) signals in the SAML assertion or OIDC token. If those signals are missing or classify as standard MFA, Salesforce will either challenge users again at login or block access after enforcement.

What qualifies as phishing-resistant at the SSO level

Accepted AMR/ACR signal values include: fido, fido2, fpt, hwk, passkey, phr, pki, swk, wia, and others. Standard MFA signals like mfa, timesynctoken, or okta_verify are not sufficient for privileged users.

What to do

• Engage your IdP team now to confirm the correct signals are being emitted
• Test your SSO configuration in a sandbox with a mirrored setup before Production enforcement

‍

Step 5: What If Someone Gets Locked Out?

• Another org Admin can generate a temporary identity verification code, disconnect old verification methods, and assist with re-registration
• If you are the only admin in the org, contact Salesforce Support immediately. They can assist with recovery
• After a sandbox refresh, MFA verifiers do not carry over. Log in directly with username and password first, register a new phishing-resistant verifier, then reconfigure SSO

‍

Avoid these pitfalls:

"Waive MFA for Exempt Users" no longer works. After enforcement, this permission will no longer bypass MFA. Users with this permission will be prompted to enroll. Contact Salesforce Support if you have a legitimate use case (e.g. automated testing tools) that requires an exemption.

‍

Standard MFA is not enough for privileged users. TOTP apps, push notifications, and SMS are classified as standard or weak MFA. They remain available for non-privileged users but will block privileged users after enforcement.

‍

Shared accounts need a separate strategy. Passkeys are tied to a specific device. If multiple people share a Salesforce login, you cannot register a single passkey and distribute it. Plan for this now.

‍

Test in Sandbox before Production. Enforcement hits sandboxes first. Use that window to validate your configuration and run users through the registration flow before it matters in Production.

‍

Before July 1: your checklist

✓ Run both SOQL queries and export your full list of affected users

✓ Enable Built-In Authenticators and Security Keys in org Setup

✓ Every privileged user registers a compliant method on their own device

✓ If using SSO, confirm your IdP is emitting phishing-resistant AMR/ACR signals and validate in sandbox

✓ Identify any shared or service accounts and put an interim access strategy in place

‍

Need Help?

If you're unsure where to start, or want a hand running the scope assessment and validating your org's configuration ahead of the enforcement window, reach out to your Go Nimbly team. We're actively helping customers work through this and can move quickly given the timeline.

‍

Note: This post reflects Go Nimbly's interpretation of Salesforce's published enforcement guidance as of June 2026.