The situation
After your org is upgraded to Summer ‘26, single sign-on stops working. The symptoms are abrupt and org-wide:
- Users click the SSO button on the login page and are redirected to your identity provider, authenticate successfully there, but land back on a Salesforce error rather than inside the org
- Some users see a generic SAML error page; others are silently bounced back to the standard login screen
- Nothing appears in Login History for the failed attempts — the rows you would expect simply are not there
- Local Salesforce username and password logins still work for admins, so the org is reachable, but every federated user is locked out
- A change freeze was in place, so “nothing changed” — except the platform upgraded over the weekend
The org is not down. Authentication via SAML is. And because failed SAML parsing leaves no login history, the usual first diagnostic step comes back empty, which makes this feel more mysterious than it is.
Root cause
Your org was running on the single-configuration SAML framework — Salesforce’s original SAML implementation, which supports SSO with only one external identity provider. Summer ‘26 enforces the Migrate to a Multiple-Configuration SAML Framework release update, which removes support for the single-configuration framework entirely.
This release update is not new. It first appeared in Spring ‘24, was scheduled for Summer ‘24, and has been postponed across several releases. Summer ‘26 is the enforcement point. When enforcement lands, any org still relying on the single-configuration framework has its SAML SSO configuration stop functioning — because the framework it depends on no longer exists.
The reason nothing shows in login history is specific and important for diagnosis: when Salesforce cannot parse a SAML response — which is what happens when the response is being handled by a framework that has been removed — the attempt is not recorded in login history at all. The absence of failure rows is itself a symptom, not a sign that requests are not arriving.
The deeper issue is that the single-configuration framework stored your SAML settings in a legacy structure tied to a single IdP. The multiple-configuration framework stores each identity provider as its own SAML Single Sign-On Settings record. Enforcement does not automatically rewrite your old configuration into the new structure — that migration is the work the release update asks you to do in advance. If it was never applied and tested, enforcement simply removes the old path with nothing valid in its place.
Diagnosis
Confirm which framework the org is on
From Setup, in the Quick Find box, enter Release Updates. Look for Migrate to a Multiple-Configuration SAML Framework. If it is present and not yet applied, your org is still on the single-configuration framework and is exposed to this exact failure.
Review the existing SAML configuration
From Setup, in the Quick Find box, enter Single Sign-On Settings. Note every SAML configuration present, the identity provider it points to, the Issuer, the Entity ID, the Identity Provider Login URL, and the signing certificate. Capture all of this before making changes — you will need to recreate it in the new framework.
Use the SAML Assertion Validator
On the Single Sign-On Settings page, the SAML Assertion Validator lets you paste a real SAML response from your IdP and see exactly where parsing or validation fails. This is the most reliable way to confirm the response is well-formed and that the mismatch is framework-related rather than a certificate or attribute problem.
Resolution
Do all of this in a sandbox first. SAML enforcement is also applied to sandboxes ahead of production, so a sandbox is both the safe place to rehearse and a realistic preview of what production will do.
Fix 1 — Recreate each identity provider in the multiple-configuration framework
For every IdP your org authenticates against, create a SAML Single Sign-On Settings record in the new framework. From Setup → Single Sign-On Settings, create a new configuration — either manually using the captured values, or using New from Metadata File / New from Metadata URL if your IdP publishes metadata, which populates the Issuer, Entity ID, login URL, and certificate automatically.
Match the SAML Identity Type and Identity Location to what your IdP sends — for most setups the assertion contains the Federation ID on the User object. Getting this wrong is the most common cause of a migration that validates but still fails to map users.
Fix 2 — Apply the release update
From Setup → Release Updates → Migrate to a Multiple-Configuration SAML Framework → Get Started, and follow the testing and activation steps. Do not enable it until your new configuration is in place and validated.
Fix 3 — Re-point My Domain and the login page
Confirm your My Domain authentication configuration references the new SSO setting. From Setup → My Domain → Authentication Configuration, ensure the new SAML SSO option is selected and appears on the login page. The configuration name changes when you recreate it, so any place that referenced the old configuration by name needs updating.
Fix 4 — Validate end to end before enforcement
Use the SAML Assertion Validator with a live assertion, then perform a full SP-initiated and IdP-initiated login as a federated test user — not as an admin who can fall back to username and password.
Verification
A successful migration looks like this:
| Check | Expected |
|---|---|
| Release Updates | Migrate to a Multiple-Configuration SAML Framework shows as applied |
| Single Sign-On Settings | Each IdP exists as its own configuration record |
| SAML Assertion Validator | A live assertion validates with no errors |
| Federated login | A non-admin SSO user logs in successfully, both SP- and IdP-initiated |
| Login History | The successful SSO login is now recorded |
Once a federated test user can log in and the login appears in login history, the migration is sound. Schedule the production cutover ahead of your instance’s enforcement date rather than waiting for the upgrade to force it — an SSO outage discovered after enforcement locks out every federated user at once, with no login history to diagnose from.