This article provides the official, validated solution for the user experience impact caused by the recent Salesforce security change for SAML Single Sign-On (SSO) logins. This impacts all Salesforce integrations, including the standard Salesforce, Salesforce Portal, Salesforce (Federated ID), and Salesforce (Non-Profit) applications.
As of March 26, 2026, Okta is deploying a permanent, platform-level fix for users of our official OIN applications, which resolves the "double prompt" issue automatically. However, manual action is still required for customers using custom-built applications to connect to Salesforce.
This FAQ provides the necessary steps
This solution applies to all customers using SAML-based Single Sign-On (SSO) for Salesforce federation.
This includes, but is not limited to, the following Okta Integration Network (OIN) applications:
- Salesforce
- Salesforce Portal
- Salesforce (Federated ID)
- Salesforce (Non-Profit)
Table of Contents
- Action Recommended Based on Your Configuration
- The short term workaround Okta Solution to Fix the "Double Prompt"
- What is the Salesforce change, and how will it affect my end users?
- Will users be blocked or lose access to Salesforce?
- Why am I still seeing the double prompt after adding the AMR attribute?
- What is Okta's long-term plan for this feature?
- I am using a custom SAML app; will this work for me too?
- Is there an alternative to the AMR attribute solution?
Action Recommended Based on Your Configuration
Please review the two scenarios below and follow the guidance that applies to your organization.
1. For Customers Using Official Okta Integration Network (OIN) Apps
No action is required from you.
On March 26, 2026, our platform update will automatically resolve the "double prompt" issue for the official Salesforce OIN apps. If you previously implemented the manual workaround by adding the custom AMR attribute, it will cause no conflict. You may remove this attribute at your convenience after March 26th for configuration cleanup.
2. For Customers Using a Custom-Built Salesforce App (SAML or OIDC)
The automatic platform fix does not apply to custom applications. To resolve the "double prompt" issue, your Okta Administrator must add a custom SAML attribute / OIDC token to your application's Sign-On configuration.
Please follow the steps in Configure custom claims for app integrations and use the specific values below:
-
Attribute name - AMR
-
Attribute expression - session.amr
Once saved, users who complete MFA in Okta will no longer be prompted for the secondary email verification by Salesforce.
Rollback: If you need to reverse this change for any reason, you can simply delete the custom AMR attribute you added.
The short term workaround Okta Solution to Fix the "Double Prompt"
We have tested and confirmed that the following configuration change will resolve the "double prompt" issue for your users. This is the official, recommended action for all impacted customers.
Action Required: Okta administrators must add a custom SAML attribute to the configuration of each of their impacted Salesforce applications.
- In the Okta Admin Console, navigate to your impacted Salesforce application (e.g., Salesforce, Salesforce Portal, Salesforce (Federated), Salesforce (Nonprofit), etc.).
- Go to the Authentication/Single Sign On tab.
- Click Edit in the "Sign on Settings" section.
- Scroll down to the Attributes (Optional) section.
- Add a new attribute statement:
-
-
- Name:
AMR - Name format:
Unspecified - Value:
session.amr
- Name:
-
- Click Save.
Once saved, users who complete MFA in Okta will no longer be prompted for the secondary email verification by Salesforce for that application.
If the above option for step 5 was set up but still does not work and Salesforce continues to request MFA on their end, it might be because the tenant sends the AMR claim as a multi-value single line comma-delimited string while Salesforce expects it as an array or a single value. The following expression can be used to send a singular claim of 'mfa' if the claim is present in the session.amr.
Arrays.contains(session.amr, "mfa") ? "mfa" : null
What is the Salesforce change, and how will it affect my end users?
As of February 9th, 2026, Salesforce now requires a "Device Activation" prompt (an email-based code) for SSO logins from new devices.
Because Okta's standard Salesforce Integrations did not dynamically signal that MFA had been completed, this resulted in a "double prompt" experience for users on new devices. They would authenticate with Okta MFA and then be prompted by Salesforce for email verification. The solution provided above resolves this issue.
Will users be blocked or lose access to Salesforce?
No. This remains a key point: users are NOT blocked, do not lose access, and there is no service outage. The impact was to the user experience, not service continuity.
Why am I still seeing the double prompt after adding the AMR attribute?
This is the expected behavior if the authentication method used for the login does not meet Salesforce's requirements for a secure session.
The AMR attribute solution works by signaling the authentication strength to Salesforce. If Salesforce considers the method to be low-assurance, it will correctly prompt for device activation as part of its new policy.
Action Required: Please ensure your Okta App Sign-On Policy for Salesforce requires an authentication method that is on Salesforce's list of approved methods. Review the Salesforce official requirements in their Changes to Device Activation for Single Sign-On (SSO) Logins documentation.
What is Okta's long-term plan for this feature?
The AMR attribute described above is the official and fully supported immediate solution.
In parallel, our product and engineering teams are actively working on a permanent, fully integrated solution that will automatically meet Salesforce's new security requirements directly within the OIN applications. This will make the manual configuration unnecessary in the future. We will provide updates on the timeline for this long-term enhancement as they become available.
I am using a custom SAML app; will this work for me too?
Yes, follow the steps in Configure custom claims for app integrations.
-
- Attribute name - AMR
- Attribute expression - session.amr
Is there an alternative to the AMR attribute solution?
Yes. While the AMR attribute is the recommended Okta-side solution, mitigation can also be implemented on the Salesforce side.
Set Up Trusted IP Ranges in Salesforce
Provide Salesforce with a list of your company's trusted IP addresses (e.g., your corporate offices). This will bypass the device prompt for any user logging in from those pre-approved locations.
-
- How to do it: Your Salesforce Administrator can configure this at the organization level and/or on specific user profiles.
- Salesforce Documentation:
- Limitation: This is highly effective for on-premise users but will not cover your remote or traveling workforce.
