If Your Organization Uses SSO for Salesforce, You Need to Read This
Part of our ongoing coverage of Salesforce's 2026 security changes. See also: "Salesforce's 2026 Security Changes" (May 11) and "What We Learned From Salesforce's May 13 Security Briefing" (May 14).
If your organization signs into Salesforce through an identity provider (IdP) like Okta, Microsoft Entra ID, OneLogin, or Google Workspace, the assumption you're probably operating under is that your SSO setup covers you for the new Salesforce security requirements. Strong MFA at the identity provider, single point of identity for the whole organization, one place to manage offboarding — that's the whole point of having SSO in the first place.
That assumption is mostly right. But it has gaps, and the new Salesforce rollout exposes a few of them in ways that are easy to miss until they start causing problems. This post is the piece you wish your IT director or accidental admin had in front of them right now.
We're going to do three things. First, explain a concept called AMR/ACR signals, because the entire conversation about whether SSO "counts" hinges on it. Second, walk through what specifically your IdP needs to be doing for each of the new Salesforce requirements. Third, give you a short checklist of what to verify and how.
One disclaimer up front: BrightHelm doesn't run an IdP ourselves and our current clients are mostly direct-login organizations rather than SSO shops. We've researched this carefully and the material below is consistent with Salesforce's own documentation and the May 13 customer briefing — but you should test in a sandbox before relying on any of it.
The Concept You Need: AMR/ACR Signals
When a user signs into Salesforce through an identity provider, Salesforce isn't doing the authentication. The IdP is. So Salesforce has to take the IdP's word for what just happened — was a password used? Was MFA performed? Was a hardware key involved? Was it just a single-tap mobile push?
The IdP communicates this through two industry-standard signals called AMR and ACR. Both are pieces of metadata embedded in the SAML response. SAML stands for Security Assertion Markup Language, or the language that these technologies speak to each other.
ACR stands for Authentication Context Class Reference. Think of it as a summary label: "this login meets such-and-such authentication standard." A common one looks like:
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
This essentially means "the user typed a password over an encrypted connection — nothing stronger." Other ACR values indicate that MFA was performed, or that a high-assurance method was used.
AMR stands for Authentication Methods References. It's more granular than ACR — it's a list of specific methods the user actually used. Examples include pwd (password), otp (one-time password code), mfa (some form of multi-factor), hwk (hardware key like a YubiKey), swk (software key like a passkey in a password manager), face (facial recognition like Face ID), fpt (fingerprint like Touch ID), and a handful of others. You can essentially think of them as tags that pass more information about how the authentication was performed.
Here's the part that matters: Salesforce reads these signals and decides whether the IdP's authentication meets the new requirements. If the AMR values indicate phishing-resistant methods, the user is treated as having done phishing-resistant MFA. If they only indicate standard MFA, the user is treated accordingly. If the signals are missing entirely, or weak, Salesforce will require the user to enroll a Salesforce-side MFA method and complete a challenge on the Salesforce side — which is exactly the outcome you probably set up SSO to avoid.
The Gotcha Most Organizations Are Going to Hit
The most common failure mode is not "our IdP doesn't do MFA." Most IdPs at organizations that have invested in SSO are perfectly capable of doing strong MFA. The failure mode is that the IdP performs strong MFA but reports it weakly — sending a generic claim when it should be sending something more specific.
For example: a user signs in at Okta using Touch ID. From the user's perspective, this is phishing-resistant MFA — a passkey on a device. But if Okta's application policy is configured to only return "amr": ["mfa"] rather than "amr": ["hwk", "user"] or "amr": ["face", "user"] or similar, Salesforce reads the login as standard MFA, not phishing-resistant. The user did everything right. The configuration didn't.
For non-privileged users, this is usually fine — standard MFA satisfies the general requirement. For users with the System Administrator profile or any of the privileged permissions (Modify All Data, View All Data, Customize Application, Author Apex), it isn't fine. Those users will be blocked at login, prompted to enroll a Salesforce-side phishing-resistant method, and forced to maintain that method in parallel to whatever they're already using at the IdP.
The fix is almost always an IdP-side configuration change, not a Salesforce-side change and not a license upgrade. But you have to know to look for it.
What Your IdP Needs to Be Doing for Each Requirement
For MFA enforcement for all employee users (production enforcement starts July 20): Your IdP needs to perform some form of MFA for every login and report that in the AMR/ACR signals. If your IdP is already configured to require MFA for the Salesforce application, you're almost certainly fine here — just verify the signals are actually being sent.
For phishing-resistant MFA for privileged users (production enforcement starts July 1): Your IdP needs to perform a phishing-resistant method specifically for these users, and report it as such in AMR. Acceptable phishing-resistant AMR values include hwk (hardware security key), face (facial biometric), fpt (fingerprint biometric), and likely swk (software-stored passkey, though Salesforce's position on this is still hedged — see our May 13 post). The IdP also needs to be configured so that privileged Salesforce users are required to use one of these methods, not just allowed to.
For step-up authentication on reports (production enforcement starts June 10): This is the one most likely to surprise you. Even if your IdP does everything right above, Salesforce will not call back to your IdP to perform a step-up. The step-up challenge runs against Salesforce's own verification methods. So every user who runs or views reports — SSO or not, privileged or not — needs at minimum one of data points: a Salesforce MFA method registered, a current mobile phone number in their Salesforce user record, or a current email address in their Salesforce user record. Without one of these, the step-up challenge can't be completed, and the user is blocked from running the report.
The third requirement is the one that breaks the SSO mental model most clearly. "We use SSO with strong MFA, we shouldn't need anything Salesforce-side" is wrong for step-up. You need Salesforce-side fallback verification methods registered for every user who runs reports.
How To Verify What Your IdP Is Actually Sending
You don't have to take anything on faith here. Salesforce gives you tools to see exactly what your IdP is sending.
Easiest check: Login History. In Salesforce Setup, search for "Login History." Each recent login record shows the AMR/ACR values Salesforce received. Pick a login from a privileged user and look at the values. If they include phishing-resistant indicators like hwk or face, you're in good shape. If they only show pwd and mfa, you have configuration work to do at the IdP.
See: Salesforce Developers | Login Event Type
More detailed check: SAML Assertion Validator. Also in Salesforce Setup. This lets you paste in a raw SAML response and see exactly what Salesforce parses out, including the full authentication context. That’s useful when Login History shows something unexpected and you want to dig into the raw assertion.
See: Salesforce Help | Troubleshoot SAML Assertion Errors
Source of truth: Salesforce's documentation on recognized AMR values. Salesforce maintains a published list of which AMR values map to which tier (phishing-resistant, standard MFA, doesn't count). Custom claims from specific IdP vendors are also evaluated by Salesforce's security team, and the documentation is updated as new ones are classified. If you see an AMR value in Login History that you don't recognize, check the docs.
See: Salesforce Help | Device Activation for Salesforce Orgs
A Short Checklist for the Next Two Weeks
If your organization uses SSO for Salesforce, here's the practical sequence:
Identify your privileged users. Run a report on users with the System Administrator profile or any of the privileged permissions. This is the list that has to be phishing-resistant by July 1.
Check Login History for each privileged user. Confirm the AMR values Salesforce is receiving include phishing-resistant indicators. If they don't, you have IdP configuration work to do.
Confirm every user who runs reports has a Salesforce-side fallback. Mobile phone number current, email address current, or a Salesforce MFA method enrolled. This is for step-up authentication on reports, which goes live June 10.
Test in sandbox. The sandbox enforcement dates are earlier than production for every requirement. Use that window. If something is going to break, you want to find out in a sandbox.
Establish recovery procedures. When phishing-resistant methods become mandatory for admins, a lost device or broken laptop becomes a lockout scenario. Make sure you have at least two admins with their own enrolled methods, and document how to handle device replacement before it's an emergency.
Where This Is Going
The short version of all of this: SSO is still doing useful work in the new regime, but Salesforce has decided it can't fully trust the IdP's word for everything. The step-up requirement on reports is the clearest signal of that — Salesforce wants its own verification path for sensitive actions, regardless of what your IdP did at login. That's a meaningful change in the relationship between Salesforce and the identity providers it federates with, and it's worth understanding for reasons that go beyond this rollout.
If you're working through this and want to talk through what it means for your specific setup, we're happy to help.
Sources: Salesforce Help articles "Prepare for MFA Enforcement for All Employee Users," "Prepare for Phishing-Resistant MFA Enforcement for Privileged Users Including Admins," and "Security-Related Product Updates to the Salesforce Platform"; the Salesforce customer security briefing held May 13, 2026; and RFC 8176 (the standard defining AMR values). Specific AMR values and their Salesforce classification are subject to change as Salesforce's documentation evolves.
