What We Learned From Salesforce's May 13 Security Briefing: Updates to Our Earlier Analysis
This is a follow-up to "Salesforce's 2026 Security Changes: What's Actually Happening, What It Means, and Why It's Hitting Consulting Partners Hardest", published May 11.
We published our analysis of Salesforce's 2026 security changes two days ago. Salesforce ran a few rounds of customer webinars on the topic yesterday. Some of what was covered confirmed our read; some of it added detail we didn't have; one piece pushed back on a framing we took away from the written documentation. This post captures the deltas.
The core thesis of the original post — that phishing resistance is the headline and identity binding is the substance, and that consulting partners are hit hardest by the shift — held up against the briefing without qualification. The roundup of what's changing and when also held up. What follows are the specific things we'd add, clarify, or flag if we were writing the original post today.
Step-Up Authentication for Reports Has Implications for SSO Users That Are Easy to Miss
By way of background: SSO stands for “Single Sign On.” This typically means – and is what we are talking about in the context of this article – the use of an Identity Provider (IdP) service to sign into some other service. If you’ve ever used your Google or Apple account to sign into some other website, then you have used SSO. That said, in this context, we’re mostly talking about industry IdPs like Okta. Organizations sometimes adopt these to create a single, security “key” of sorts that their employees can use to unlock all kinds of doors.
The briefing made one point twice, which is usually a signal that the speaker expects it to surprise people. Even SSO users whose identity provider already performs phishing-resistant MFA will need a Salesforce-side verification method registered — Salesforce MFA, a current mobile phone number, or a current email address — to satisfy the step-up challenge on reports.
The reason: Salesforce will not call back to your IdP for step-up. The step-up challenge runs against Salesforce's own verification methods. Therefore, a clean SSO setup with phishing-resistant MFA at Okta or Entra doesn't substitute for Salesforce-side enrollment in the step-up context.
For organizations that built their identity strategy around "we have strong MFA at the IdP, we don't need anything on the Salesforce side," this is a meaningful gap to close before the June 10th production enforcement, and not a lot of time to close it. We're writing a separate piece for SSO-using organizations on what this means in practice — watch for that shortly.
The Step-Up Window Floor Is Lower Than We'd Assumed
We wrote that the default step-up window is 120 minutes and admins can adjust it. The briefing clarified that admins can tighten the window down to as little as two minutes if they choose. The 120-minute default is the ceiling of typical practice, not the floor of configurability.
For most nonprofits this is going to be irrelevant — a two-minute step-up is genuinely punishing and very few use cases justify it. But for organizations handling regulated data (health, financial aid, immigration) the granularity matters, and it's a lever worth knowing exists.
Experience Cloud Is Largely Exempt
Our original post didn't address Experience Cloud at all, and given how many nonprofits run volunteer portals, grantee portals, donor self-service, and similar functions through Experience Cloud, that was a gap. The briefing was clear on this: Experience Cloud and Experience Site logins are not subject to MFA enforcement. It remains an optional setting that admins can configure. Experience Cloud partner portal users are also exempt from the anomalous report export detection.
Whether nonprofits should enable MFA for their Experience Cloud users is a separate question and the answer is usually yes — but it's not being forced, and that distinction matters for planning.
Recovery Procedures Deserve Their Own Bullet on the Preparation Checklist
The briefing emphasized something we underweighted in our preparation guidance: organizations need access recovery procedures in place before enforcement hits. When a privileged user loses their phishing-resistant MFA device — broken laptop, lost YubiKey, replaced phone — they're locked out of the org until they can verify identity another way.
Salesforce Support can issue temporary codes by phone if a user is the sole admin, but that's a fallback for emergencies, not a workflow (we can hear the snickering in the back, pipe down). The better answer is for organizations to:
Designate at least two admins so single-admin lockout isn't the failure point.
Document the recovery procedure before the first enforcement date hits.
Confirm that backup admins have their own enrolled phishing-resistant methods.
Verify mobile and email contact information for all privileged users is current, since the SMS/email fallback for step-up depends on those being right.
For very small nonprofits where there is genuinely only one person who can administer Salesforce, this is one of the places where the "when to bring in outside help" conversation gets practical. The cost of a second admin enrolled with a backup security key is far lower than the cost of a multi-day lockout during a fundraising campaign.
How To Verify What Your IdP Is Actually Sending Salesforce
If you're using SSO, our original post mentioned that Salesforce checks for AMR/ACR signals from your identity provider to determine whether MFA happened and what type. We didn't tell you how to verify what your IdP is actually sending. The briefing pointed to three places to look:
Login History in Salesforce Setup — the easiest check. Recent logins show the AMR/ACR values Salesforce received.
SAML Assertion Validator in Salesforce — paste in a raw SAML response and see exactly what Salesforce parses out.
Salesforce's documentation on recognized AMR values for each tier.
If you're not sure whether your IdP is sending the right signals — or whether the values it sends will be classified as phishing-resistant by Salesforce — this is the place to start. The most common gotcha is an IdP that performs phishing-resistant authentication but only reports a generic mfa claim, which Salesforce reads as standard MFA, not phishing-resistant. The fix is usually IdP-side configuration, not a license change.
Disclaimer: BrightHelm doesn’t use an IdP and we don’t currently have any clients who are, so we haven’t tested it.
The Synced Passkey Question: A Little Less Closed Than We Wrote…?
In our original post we leaned into the language Salesforce's written documentation uses — "cryptographic, device-bound, and origin-bound authentication" — and read that as evidence that synced passkeys are likely to be squeezed out. The briefing pushed back on that framing, a bit.
Tushar Sharma, one of the product managers presenting, was asked specifically about supported passkeys and answered: "We support all FIDO2 standard passkeys. That includes all standards-based support across Chrome, Edge, Safari, Windows, and macOS. Currently the passkeys in the UI are called built-in authenticators and security keys, and we are working to change the terminology or product flows, but all standards-based passkeys are already supported."
When pressed on the AMR value swk (software key) — which according to our research is what a password-manager-based synced passkey reports — Tushar said "I believe it is" treated as phishing-resistant, but hedged and pointed to the knowledge articles as the source of truth.
So: the briefing was more permissive in tone toward synced passkeys than the written documentation is. That doesn't override the documentation, and we still wouldn't recommend building a long-term consulting access strategy on the assumption that 1Password-shared passkeys will permanently satisfy phishing-resistant MFA. We still say the destination of one-person-one-login is clearly what Salesforce is aiming for. The honest read now is "the policy on synced passkeys is unsettled and the people building the product are not communicating one position consistently." That's worth knowing.
For consulting partners planning around this, our call is to still treat synced passkeys as a stay of execution. But the execution date is less imminent than the written docs alone suggest.
What We're Doing Next
We're tracking the rollout closely and will publish more as the picture clarifies. The next piece will be the SSO-focused explainer mentioned above — what AMR/ACR signals are, why Salesforce needs them, and what to verify with your IdP before enforcement.
If you're working through this transition and have questions specific to your organization's setup, we're happy to talk.
Sources cited in this post: the Salesforce customer security briefing held May 13, 2026, presented by Glenn Clark with product managers Tushar Sharma and Purva [last name not captured]. Statements attributed to specific speakers reflect our notes and the meeting recording transcript. Where the briefing and the official help documentation point in different directions, we've noted both. The official Salesforce Help articles remain the source of truth, and we'll update this post if the documentation changes.
