FAQs About MFA for SSO Logins to Salesforce Products
Talk to your SSO provider about using their MFA service.
For products that are built on the Salesforce Platform, you can use the free MFA functionality provided in Salesforce instead of enabling MFA at the SSO level. See Use Salesforce MFA for SSO Logins in Salesforce Help for details.
Keep in mind that all of your Salesforce users must use MFA. If you have any users, such as Salesforce admins, who log in directly to your products, enable Salesforce's MFA to secure these accounts. Check out this video.
With a well-implemented SSO strategy, you can reduce some of the risks associated with weak or reused passwords, and make it easier for your users to log in to frequently used applications. But if your SSO implementation relies on user credentials alone, it can leave user accounts vulnerable to common attacks such as phishing or credential stuffing.
As a steward for your organization’s security, you play a critical role in safeguarding your sensitive business and customer data, including names, email addresses, and other personally identifiable information. With threats like phishing attacks, credential stuffing, and account takeovers on the rise, MFA is one of the most effective ways to prevent unauthorized account access. We encourage you to work with your Security and IT teams to align the MFA requirement with your company’s overall security objectives, and to get their help on satisfying the requirement.
If you do not implement MFA for users who access Salesforce via SSO, you’ll be at increased risk for cyberattacks that could harm your business and customers.
No. If MFA is enabled for your SSO identity provider, you don’t need to enable Salesforce’s MFA for users who log in via SSO. But if you have admins or other privileged users who log in to your Salesforce products directly, you do need to set up Salesforce’s MFA for these users.
The crux of the MFA requirement is that all of your Salesforce users must provide a strong verification method in addition to their password when they access Salesforce products. If needed, you can accomplish this by deploying multiple MFA solutions. For example, if you have a mix of SSO and non-SSO users, ensure that MFA is enabled for your SSO users and turn on your Salesforce product’s MFA functionality for the users who log in directly.
Here’s a common scenario: We recommend setting up most Salesforce users to log in with SSO and MFA. But for admin accounts that don’t use SSO, you can enable MFA in your Salesforce products so admins have an extra layer of protection when they log in directly with their username and password.
For products that are built on the Salesforce Platform, you can use the MFA functionality provided in Salesforce instead of using your SSO provider’s MFA service. With this approach, users log in via your SSO login page. Then they’re directed to Salesforce, where they’re prompted to provide their MFA verification method to confirm their identity.
Note: This option isn't available for other Salesforce products.
To learn more, see Use Salesforce MFA for SSO Logins in Salesforce Help.
Let’s start with verification methods that don’t satisfy the requirement, whether you’re using your SSO identity provider’s MFA services or Salesforce’s MFA for direct logins.
- Delivering one-time passcodes via email messages, text messages, or phone calls isn’t allowed because these methods are inherently vulnerable to interception, spoofing, and other attacks.
- Used on their own, trusted devices or trusted networks aren't adequate verification methods for the MFA requirement. (But used in combination, these methods can achieve MFA and satisfy the requirement. See "Do trusted corporate devices meet the MFA requirement?" and "Does restricting logins to trusted networks meet the MFA requirement?" in the MFA FAQ for more details.)
To satisfy the MFA requirement, you must use verification methods that are more resistant to cyberattacks (such as phishing and man-in-the-middle attacks). These types of methods help provide high assurance that users accessing Salesforce products are who they say they are. For SSO implementations, with the exception of the options listed above, use any method that is supported by, or integrated with, your identity provider’s MFA solution.
Risk-based authentication, also known as adaptive authentication or Continuous Adaptive Risk and Trust Assessment (CARTA), is an authentication system that continually analyzes the risk associated with a user by monitoring multiple signals coming from the user, the user’s device, and how and when the user accesses services. If the level of risk in a given situation warrants, the identity provider or authentication service automatically requires the user to satisfy additional security challenges. To learn more, see this article.
If you've already integrated a risk-based authentication system with your SSO solution, your implementation complies with the MFA requirement. If you'd like to consider this type of solution, there are a number of technology providers that you can work with.
We strongly recommend configuring the MFA service for your SSO identity provider so that users are required to provide a strong verification method in addition to their username and password every time they log in.
If you use a third-party identity provider (IdP) to access your Salesforce products, Salesforce has limited visibility into your MFA implementation. To ensure we have the necessary insight to manage the MFA requirement, we’re planning to leverage standards-based attributes in SSO protocols that describe the authentication method used during an SSO login.
Most SSO providers support two primary attributes: OpenID Connect (OIDC) uses Authentication Method Reference (amr) and SAML uses Authentication Context (AuthnContext). Currently, OIDC amr is available in products built on the Salesforce Platform, and you can see the values in LoginHistory when you export the data. In future releases, we’re looking to expand OIDC amr to other Salesforce products, and add support for SAML AuthnContext to all products.
Keep in mind that enabling MFA is a contractual requirement, per the Salesforce Trust and Compliance Documentation.
Salesforce won’t take action on your behalf to enable MFA for your SSO identity provider. Nor do we have plans to block access to Salesforce products, or trigger MFA challenges, if your SSO service doesn't require MFA. This policy could change in the future.
But remember that the MFA contractual requirement, per the Salesforce Trust and Compliance Documentation, does apply to all internal Salesforce users who access your Salesforce products via SSO. If you're not able to enable MFA by February 1, 2022, speak with your legal team to understand the implications of being out of compliance.
Our goal in requiring MFA is to give you the incentives and tools to prioritize strengthening the security of your Salesforce environments. We encourage you to work with your Security and IT teams to align the MFA requirement with your company’s overall security objectives, and to get their help on satisfying the requirement. And if you're concerned about satisfying the requirement, reach out to your Salesforce representative. We'll work with you to find a solution.
Admins should always be able to log in directly to your Salesforce products using their username and password. We don't recommend enabling SSO for Salesforce admins because they won't be able to log in if there's an outage or other problem with your SSO implementation. For example, if your third-party SSO provider has a sustained outage, admins can use your Salesforce product's standard login page to log in with their username and password, then disable SSO until the problem is resolved. Instead of using SSO for Salesforce admins, we recommend enabling MFA for administrator accounts directly in your Salesforce products.
If your company uses SSO to access Salesforce, we recommend disabling direct logins for all standard users. Preventing logins with a Salesforce username and password ensures that users can’t bypass your SSO system. Make sure affected users know the URL where they can access your SSO login page. For the steps to do this, see Disable Logins with Salesforce Credentials for SSO Users in Salesforce Help for more information.