Salesforce Summer '26: The SSO Change That Can Lock Out Your Users

"We Don't Touch SSO. It Just Works." That Is Exactly the Problem.

Every release cycle, the same thing happens. A client forwards me the headline features — this summer it is multi-agent Agentforce, the new Help Agent, Tableau MCP — and asks which ones we should pilot. Almost nobody forwards me the security section. And buried in the Summer '26 security section is the change most likely to actually take your org down: Salesforce is retiring the single-configuration SAML framework.

If your users log in through Okta, Entra ID, Ping, or any other identity provider, and you set that up years ago, this is aimed at you. Not at your roadmap. At your Monday morning.

What Single-Config vs Multiple-Config Actually Means

Single sign-on in Salesforce comes in two flavours, and most older orgs are still on the first one.

The single-configuration framework is the original design: one global SAML setup per org. One issuer, one identity-provider certificate, one set of endpoints. It works, which is exactly why nobody has touched it since go-live.

The multiple-configuration framework lets you define several named SAML configurations side by side, each with its own issuer, certificate, and login URL. It is what allows an org — or an Experience Cloud site — to federate with more than one identity provider at once.

Salesforce announced the move from single to multiple back in Summer '24, then postponed it. Summer '26 is where the release notes put the enforcement. This has slipped before, so I understand the temptation to assume it slips again. I would not bet your login page on it.

Why This One Is Different From the Usual Release Noise

Most release items are opt-in. You enable a feature when you are ready. This is the opposite: the framework change is applied when the release reaches your instance, whether or not you have prepared for it. If the active configuration does not carry over cleanly, the failure mode is not a degraded feature. It is users staring at a login error.

I have seen what an SSO outage costs at a client where an unrelated certificate expired — a full sales floor unable to log in for most of a morning, an emergency bridge call, and a very unhappy CRO. That was an accident. This one is on the calendar. There is no excuse for being surprised by a dated, documented change.

One related trap in the same release: the Salesforce-managed app for the X (formerly Twitter) auth provider is also being retired. If you have an Auth Provider with Type set to Twitter and a blank Consumer Key, it is leaning on that managed app and will stop working. Worth a thirty-second check while you are in there.

Are You Actually Affected? A Quick Read

| Your situation | Action |
| --- | --- |
| SSO via external IdP, set up before 2024, never revisited | Assume single-config. Verify and plan migration now. |
| Recently implemented SSO, or already federating multiple IdPs | Likely already on multiple-config. Confirm and move on. |
| No SSO, username and password only | Not affected by this change. |
| Experience Cloud site with external login | Same exposure as the org. Test the site login separately. |
| Auth Provider Type = Twitter, blank Consumer Key | Separate retirement. Reconfigure or remove. |

What Has Not Changed

To be fair about scope: this is a framework migration, not a re-architecture of how SAML works. Your identity provider does not change. SAML 2.0 is still SAML 2.0. Your users will not notice anything if you do this right — the whole goal is that login looks identical the day after. Multiple-config is also a genuine upgrade, not just a forced move: once you are on it, adding a second IdP for an acquisition or a partner community stops being a re-platforming exercise.

So the work is real but bounded. This is a "block an afternoon and test properly" task, not a project.

What To Do Right Now

1. Confirm which framework you are on. In Setup, open Single Sign-On Settings and look at how your SAML configuration is structured. If you cannot tell at a glance, that itself tells you it was set up long ago and needs attention.

2. Reproduce it in a sandbox first. Refresh a full or partial sandbox, perform the migration there, and run a real login through your identity provider. Never let a production login page be the place you discover a mismatched endpoint.

3. Update the identity-provider side. Multiple-config can change the login and assertion-consumer-service URLs your IdP points at. Map every endpoint, update Okta or Entra or Ping accordingly, and test each one — including any Experience Cloud sites.

4. Schedule the cutover before your instance's release date. Find your org's Summer '26 maintenance window on the Salesforce trust site and complete the migration ahead of it, not the morning of. Build in a rollback note and tell your support team the date.

Not sure whether your org is on the old framework or the new one? Let's talk — I will help you find out before the release decides for you.