Fix Guides

Salesforce SSO Required Sandbox Auto-Migration: What to Check and Fix

Updated 2026-11-05

Symptoms

These are the things an admin notices after a sandbox has been migrated.

1. 1. “Disable login with Salesforce credentials” is read-only. After migration, per Salesforce's help article, the legacy setting can no longer be edited. If you open the login settings in a migrated sandbox and the checkbox will not change, this is the expected result, not a permissions problem on your admin profile.
2. 2. The legacy SSO permission is missing when you assign permissions. Per Salesforce's help article, the legacy permission becomes unassignable after migration. An admin who tries to give it to a user in the sandbox, and cannot find it, is looking at the same change.
3. 3. Newly created sandbox users can log in with a password. Salesforce's change log says that after migration new users are not SSO-only unless they are assigned the new Single Sign-On Required permission. A new user who can still use a username and password has not been assigned it.
4. 4. An integration user or a break-glass admin is affected. Any user who relied on credential login while the org setting was on, or who must keep it, needs a deliberate decision about the new permission. Check these users first, because a wrong guess locks someone out or leaves a password path open.
5. 5. The sandbox is migrated but production still shows the legacy setting. The windows differ. Per Salesforce's help article, sandboxes migrate Dec 1-9, 2026 and production Jan 4-22, 2027, so for a few weeks the two orgs behave differently. That is the planned gap, not drift.

What to Check

1. 1. Confirm the org was eligible. Per Salesforce's help article, only orgs with “Disable login with Salesforce credentials” on, an empty Delegated Gateway URL and at least one user with “Is Single Sign-On Enabled” are migrated. Was each of those true in this sandbox? If the Delegated Gateway URL was set, the org should not have been migrated.
2. 2. List who has the new permission and who has the old flag. Compare the users holding the new Single Sign-On Required permission with the users who had “Is Single Sign-On Enabled” before. Any user in the second group and not the first is a question to answer, not an assumption to make.
3. 3. List who must keep credential login. Name the integration users and the emergency admin accounts that have to sign in with a password. Is each one deliberately left without the new permission?
4. 4. Check whether production has changed yet. The permission is available in production from Nov 6, 2026, but per Salesforce's help article it cannot be used to require SSO until the org is migrated. Has your production org been migrated, or is it still waiting for its January window?
5. 5. Ask what a sandbox refresh does. Does a sandbox refresh after Dec 9 bring the sandbox in line with production, including the old setting? The help article does not settle this in the text we reviewed, so test it on one sandbox and write down what you see.

How to Fix It

1. 1. Assign the new permission deliberately. Give Single Sign-On Required to the users who should be SSO-only, through a permission set you control, rather than relying on what carried over.
2. 2. Keep an exemption list. Write down every user who stays on credential login, why, and who approved it. Revisit it at each review of your integration users.
3. 3. Test in the migrated sandbox before January. Sign in as an SSO-only user, as an exempt integration user and as a newly created user, and record the Login History result for each. Production's window starts Jan 4, 2027.
4. 4. Document the production date. Put your production migration window, the owner and the rollback contact on the calendar, so the January change is not the first time anyone sees it.

See where your org stands before January: the free health check is a short questionnaire that gives a peer-benchmarked score, with no account and no org connection.

Sources: Salesforce Help 005461455 and the 005461718 change log (Oct 21, 2026). Dates can move, so confirm them in the live article.

FAQ

Wrenk runs this kind of audit and the fixes that follow across every connected org as part of managed Salesforce operations.