TL;DR
- Summer '26 retires the original single-configuration SAML single sign-on framework. Orgs that never migrated to the multiple-configuration framework lose SSO logins when the release reaches their instance.
- Summer '26 reached production across 15 May, 5 June and 12 to 13 June 2026, so for most orgs this is a check-now situation, not a future one.
- You can see which framework you are on in one place: Setup, then Single Sign-On Settings. If you still see an "Enable Multiple Configs" button, you have not migrated.
- Separately, Apex classes compiled in API version 67.0 now default to "with sharing" and run in user mode, where older versions defaulted to "without sharing". This can return fewer records or change behaviour in code that relied on the old default.
- Neither change announces itself. The first sign is usually a broken login or a report that suddenly returns less data.
What You'll Learn
- What single-configuration SAML actually is, in plain Salesforce terms, and the exact Setup page where you check it
- How to tell whether your org has already migrated or is about to break
- What the Apex "with sharing" and user-mode default change does, and which code it affects
- The specific things to do before, or right after, Summer '26 lands
The Problem
The security enforcement wave gets the attention, but two of the changes most likely to actually break an org arrive quietly inside the Summer '26 release rather than as a dated enforcement notice. One stops people logging in. The other changes what your Apex code can see. Both have been on Salesforce's roadmap for a while, which is exactly why they are easy to miss: teams assume "we would have migrated by now" and never check. The single-configuration SAML retirement was first scheduled for Summer '24 and slipped, so a lot of orgs quietly carried the old setup into 2026.
Common Questions This Article Answers:
- What is single-configuration SAML, and how do I tell if I am still on it?
- Where in Setup do I check, and how do I migrate safely?
- What does the Apex "with sharing" default change actually affect?
Quick Answer
Summer '26 makes two breaking changes outside the headline security deadlines. First, it retires single-configuration SAML, the original single sign-on framework that supported one identity provider. If your org never switched to the multiple-configuration framework, SSO logins fail when Summer '26 lands. You check this in Setup, under Single Sign-On Settings: an "Enable Multiple Configs" button means you have not migrated, and clicking it performs the migration while keeping your existing configuration. Second, Apex classes saved in API version 67.0 now default to "with sharing" and run database operations in user mode, instead of the old "without sharing" default. Code that relied on the old behaviour can return fewer records. Test SSO in a sandbox, and recompile and test any Apex you bump to v67.
What single-configuration SAML is, in plain terms
If your users log in to Salesforce by clicking through to a company login screen such as Okta, Microsoft Entra ID or Ping, rather than typing a Salesforce password, that is single sign-on, and SAML is the common protocol that carries the trust between the identity provider and Salesforce.
"Single-configuration" is Salesforce's name for the original version of that feature. It supported exactly one identity provider: one SAML setup, one connection. Years ago Salesforce introduced a newer framework, "multiple-configuration" SAML, which lets an org connect several identity providers and which is now the only version Salesforce supports. Summer '26 is where the old single-configuration framework is finally switched off.
The important thing for a junior admin is that this is not about whether you "use SSO correctly." It is about which underlying framework your org happens to be on, which depends entirely on whether someone migrated at some point in the past. Plenty of healthy, working SSO setups are still quietly on the old framework.
Where to check it in Setup
There is one page to look at. In Setup, type "Single Sign-On Settings" into the Quick Find box on the left, and select Single Sign-On Settings under Identity. This is the page that controls SAML single sign-on for the whole org.
Now read what the page shows you:
- If you see a button labelled "Enable Multiple Configs", your org is still on the single-configuration framework. That button is the migration, and it is the thing you need to act on.
- If you instead see a list of named SAML Single Sign-On Settings, with buttons like "New" and "New from Metadata File" to add more, your org has already moved to the multiple-configuration framework. You are fine, and there is nothing to do.
That single visual check, the presence or absence of the "Enable Multiple Configs" button, is the fastest way to know whether Summer '26 puts your logins at risk.
- Corporate_IdP
- Partner_IdP
How to migrate safely
Migrating is deliberately undramatic: clicking "Enable Multiple Configs" converts your existing single configuration into the new list-based framework and keeps it working, so your current identity provider connection carries over rather than being recreated from scratch. Two cautions make it safe rather than nerve-racking.
First, do it in a sandbox before production and actually test a login through your identity provider afterwards, so you confirm SSO still works on the new framework before you touch production. Second, treat the change as one-way: once an org is on the multiple-configuration framework it does not go back, so you want to have tested rather than to be discovering surprises in production. If your org has any custom links, bookmarks or identity-provider settings that reference the old single-config login URL, check those too, because the multiple-configuration framework can expose different login URLs per configuration.
If the "Enable Multiple Configs" button is already gone, none of this applies to you and you can move on.
The Apex change: secure-by-default in API v67.0
The second change is for anyone who writes or owns Apex. In API version 66.0 and earlier, an Apex class that did not declare its sharing behaviour defaulted to "without sharing", meaning it ignored the running user's record access and could see everything. From API version 67.0, the Summer '26 version, an omitted sharing declaration defaults to "with sharing" instead, so the class respects the user's record visibility by default.
Two related changes ship alongside it. Apex database operations now run in user mode by default, which means SOQL, SOSL and DML enforce the running user's sharing rules, field-level security and object permissions rather than running unrestricted. And the old WITH SECURITY_ENFORCED clause is removed for v67.0 and later, replaced by explicit user-mode access.
This is a genuine improvement, because the old defaults were a common source of accidental data exposure. The catch is that it can change behaviour in code that quietly relied on the old default. A class that used to return every record might now return only the records the running user can see, which looks like data going missing rather than like a security fix. One subtlety is worth knowing: in an inheritance chain, if any class in the chain is saved at v67.0 or later, the omitted-sharing default becomes "with sharing", so the new behaviour can reach older classes indirectly.
The practical guidance is simple. The new default only applies to classes compiled at v67.0 or later, so existing code does not change until you bump its version, but anything new starts at the latest version by default. When you raise a class to v67, recompile and test it, especially queries that are meant to return broad data sets, and add an explicit without sharing declaration only where you genuinely intend a class to bypass the user's access.
Frequently Asked Questions
Q: How do I know if my org is still on single-configuration SAML?
A: Go to Setup, enter "Single Sign-On Settings" in Quick Find, and open Single Sign-On Settings under Identity. If the page shows an "Enable Multiple Configs" button, you are still on the single-configuration framework and need to migrate. If it shows a list of named SAML configurations with New buttons, you have already migrated and are fine.
Q: We do not use SSO at all. Does the SAML change affect us?
A: No. The single-configuration SAML retirement only affects orgs that log users in through a SAML identity provider on the old framework. If your users log in with Salesforce usernames and passwords, or you do not have SAML SSO configured, there is nothing to do for this change.
Q: Will the Apex change break my existing classes immediately?
A: Not on its own. The "with sharing" and user-mode defaults apply to classes compiled in API version 67.0 or later. Existing classes keep their current behaviour until you raise their version. The exception is inheritance: if any class in a chain is saved at v67.0 or later, the omitted-sharing default becomes "with sharing" for that chain, so test inherited code when you upgrade.
Q: Is migrating the SAML framework reversible?
A: Treat it as one-way. Once an org moves to the multiple-configuration framework it stays there. That is why you should click "Enable Multiple Configs" in a sandbox first, test a real SSO login, and only then do it in production.
Key Takeaways
- Two quiet breakers: Summer '26 retires single-configuration SAML and changes the Apex sharing default. Neither arrives as a dated enforcement notice.
- One page to check SAML: Setup, then Single Sign-On Settings. An "Enable Multiple Configs" button means you have not migrated.
- Migrate in a sandbox and test a login: the migration keeps your existing config, but the change is one-way, so test before production.
- Apex v67 is secure-by-default: omitted sharing now means "with sharing" and user mode. Recompile and test code you bump to v67, watching for queries that return fewer records.
- Most of this is check-now: Summer '26 has already reached production for most instances.
What's Next?
Recommended Reading:
- Salesforce Security Enforcement in 2026: Every Change, Date, and What Admins Must Do
- Salesforce MFA Enforcement in 2026: What Admins Must Verify and Do
- Catch Salesforce Security Gaps in One Command (sf-audit)
Action Items:
- Open Setup then Single Sign-On Settings and check for the "Enable Multiple Configs" button. If it is there, plan the migration in a sandbox.
- Test a real SSO login on the multiple-configuration framework before touching production.
- For any Apex you raise to API v67.0, recompile and test it, paying attention to queries expected to return broad data.