Salesforce enforces Multi-Factor Authentication (MFA) for all employee logins across production and sandbox environments. Privileged users require phishing-resistant MFA, while standard users require standard MFA. Administrators must update the Salesforce application configuration in Okta to pass the correct authentication claims and prevent users from receiving double MFA prompts from Salesforce.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Salesforce Integration
• Multi-Factor Authentication (MFA)

Q: What change is happening?

A: Salesforce is enforcing Multi-Factor Authentication (MFA) for all employee logins across both production and sandbox environments. This enforcement applies to direct UI logins and Single Sign-On (SSO) logins. Under this new policy, Salesforce categorizes MFA into specific tiers:

• Privileged Users are required to use Phishing-Resistant MFA (for example, security keys, built-in authenticators, passkeys, Okta FastPass).

• Standard Employee Users are required to use at least Standard MFA (for example, third-party TOTP apps, Okta Verify push), though phishing-resistant methods are highly recommended for everyone.

Q: What defines a "privileged user" within Salesforce?

A: In the context of this stricter MFA enforcement, Salesforce defines a privileged user as anyone assigned the System Administrator profile, or any user assigned with one or more of the following high-level permissions:

• Customize Application
• Modify All Data
• View All Data
• Author Apex

Q: How does this change impact Okta’s integration with Salesforce?

A: Standard Employee Users: These users are not impacted by this change as long as they complete a Multi-Factor Authentication (such as TOTP via Okta Verify or Google Authenticator). Salesforce natively recognizes Okta's standard MFA claims, allowing these users to log in seamlessly without additional MFA.

Privileged Users: There is currently a technical mismatch between how the two systems communicate regarding phishing-resistant MFA. Okta FastPass emits phr (phishing-resistant) claims. However, Salesforce expects specific amr (Authentication Methods References) or acr (Authentication Context Class Reference) signals (like fido2 or webauthn) to confirm this specific MFA tier was used. Because Salesforce does not natively accept the phr claim, privileged users logging in via Okta SSO will not automatically satisfy the new requirements and will be prompted by Salesforce to register for its native MFA.

Q: What is being done to mitigate this change?

A: To bridge this gap, Okta is working on updating the amr or acr claims that Salesforce expects during the SSO flow. By updating this, Okta FastPass (for privileged users) authentications can be translated into the accepted Salesforce formats. This prevents any employee from being double-prompted for MFA by Salesforce.

Q: Are any actions required to leverage these updated configurations?

A: Yes. Okta Administrators must update the Salesforce application configuration in Okta to ensure that privileged users can perform phishing-resistant authentication (Okta FastPass, SmartCard, etc.) and that other users can perform standard multi-factor authentication (Okta Verify, Google Authenticator, etc.). If this step is not completed, all employees will experience friction at login, as Salesforce will require them to register a built-in authenticator, security key, or authenticator app.

Q: How can phishing-resistant authentication be enabled for the Salesforce integration in Okta?

A: The configuration steps depend on whether the Okta tenant is on the Okta Classic Engine or the Okta Identity Engine (OIE).

For Okta Identity Engine (OIE): In OIE, enforce phishing-resistant methods such as Okta FastPass or FIDO2 WebAuthn directly within the app's Authentication Policy.

1. Navigate to Security > Authentication Policies.
2. Select the policy assigned to the Salesforce integration.
3. Add or edit a rule targeting the privileged users.
4. Under Actions, ensure User must authenticate with is set to a 2-factor type (for example, Any 2-factor types or Password / IdP + Another factor).
5. Under the Possession factor constraints are, select Phishing resistant.
6. Save the rule and prioritize it appropriately.
7. For step-by-step guidance, review the Okta documentation: Configure an app sign-in policy for passwordless authentication with Okta FastPass.

For Okta Classic Engine: Okta FastPass is an OIE-exclusive feature, so Classic Engine organizations must use FIDO2 (WebAuthn) (for example, YubiKeys or Windows Hello) to satisfy Salesforce's phishing-resistant requirement.

1. First, ensure WebAuthn is enabled as a factor in Security > Multifactor.
2. Navigate to Applications > Salesforce > Sign On.
3. Scroll down to the Sign On Policy section and add or edit a rule for the Salesforce admins.
4. Under Actions, check Prompt for factor and set the frequency to every sign-on.
   • Because the Classic Engine manages specific allowed factors at the enrollment level rather than the app sign-on rule level, it must enforce WebAuthn for these users via the MFA Enrollment Policy (disabling weaker factors for the admin group) or by utilizing Factor Sequencing to strictly require WebAuthn.
5. For more details, review the Okta documentation: App sign-on policies (Classic) and About Multifactor Authentication (Classic).

Q: What is the timeline for making these changes?

A: Salesforce is going to enforce these requirements via staggered rollouts, with different timelines for production environments based on the user's privilege tier.

• For Privileged Users (Phishing-Resistant MFA):

  • Sandboxes: Enforcement begins on June 22, 2026 (staggered over ~7 days).
  • Production: Enforcement begins on July 1, 2026 (staggered over ~30 days).

• For Standard Employees (Standard MFA):

  • Sandboxes: Enforcement begins on June 22, 2026 (staggered over ~7 days).
  • Production: Enforcement begins on July 20, 2026 (staggered over ~30 days).

Q: If the release is staggered, when does this change affect the Salesforce tenant?

A: With the current information available, Okta cannot predict that exact timeline. But to be on the safer side, Okta recommends having the necessary policies in place right away.

Q: Which Okta authenticators are compatible with the Salesforce MFA mandate?

A:

Q: How does Okta support the Single Sign-On requirements for both standard employees and admins?

A: Okta can dynamically support both user bases. Standard employees can fulfill their requirement using standard Okta MFA (like Okta Verify TOTP or push notifications), provided those assertions are mapped to Salesforce's "Standard MFA" signals. Privileged users (admins) must use Okta FastPass or FIDO2 WebAuthn options, and their logins must be explicitly mapped to pass the "Phishing-Resistant" amr/acr values Salesforce expects.

Q: Can phishing-resistant MFA be enforced only on Salesforce administrators, while allowing standard MFA for general employees?

A: Yes, specific Okta authentication policies and groups can be created. Salesforce administrators can be targeted to require Okta FastPass or WebAuthn (phishing-resistant), while standard MFA methods can be allowed for the general employee population. However, both Okta and Salesforce strongly recommend enabling phishing-resistant MFA for all users to ensure the highest level of protection against identity-based threats like credential stuffing and MFA fatigue attacks.

Q: Is an extension available for organizations not ready to implement this change?

A: Salesforce is actively enforcing this to mitigate severe account takeover risks, and general extensions are not being offered. Furthermore, the previous "Waive Multi-Factor Authentication for Exempt Users" permission will no longer automatically exempt users. If valid, exceptional use cases exist (such as automated testing tools or RPA accounts) that require an exemption, Salesforce Support must be contacted directly for approval. Immediate preparation is highly recommended.

Q: What is the expected downtime for these changes?

A: No downtime is anticipated.