Salesforce SSO Required Permission: Migration Audit

Short answer: The Salesforce "Single Sign-On Required" permission is a new user permission that replaces the legacy org-wide "Disable login with Salesforce credentials" setting for forcing users through SSO; eligible orgs are migrated automatically on Salesforce's published schedule, so audit who is SSO-only today before it runs.

Dates below follow Salesforce Help articles 005461455 and 005461718 (change log Oct 21, 2026). Salesforce's published schedule is the authority; confirm it in your release notes. Last reviewed: 2026-10-29.

Is my org in scope?

Your org is in scope for the automatic migration only if all three are true:

"Disable login with Salesforce credentials" is ON
The Delegated Gateway URL is empty
At least one user has the "Is Single Sign-On Enabled" permission

If any of the three is false, the automatic migration does not apply to your org. Check all three in Setup before assuming either way.

What changes on Nov 6 and what auto-migrates in January

Per Salesforce's published schedule:

**Oct 23, 2026:** the new "Single Sign-On Required" user permission becomes available in sandboxes
**Nov 6, 2026:** the permission becomes available in production
**Dec 1-9, 2026:** eligible legacy configurations auto-migrate in sandboxes
**Jan 4-22, 2027:** eligible legacy configurations auto-migrate in production

The permission cannot be used to require SSO until your org has been migrated. After migration, the legacy setting becomes uneditable and the legacy permission can no longer be assigned. New users are not SSO-only unless someone assigns them the new permission.

Audit before migration

Start in a sandbox, since it migrates first. Find every permission set, including profile-owned ones, that grants "Is Single Sign-On Enabled" (field `PermissionsIsSsoEnabled`), and who holds it:

`SELECT Assignee.Username, Assignee.Profile.Name, PermissionSet.Name, PermissionSet.IsOwnedByProfile FROM PermissionSetAssignment WHERE PermissionSet.PermissionsIsSsoEnabled = true`

Then decide, user by user:

**Admins:** keep at least one administrator who can log in with a Salesforce username and password, so an identity-provider outage cannot lock everyone out of Setup.
**Integration users:** list every user that an API client, middleware or scheduled job logs in as. These authenticate with credentials or tokens and not through your identity provider, so they must stay exempt.
**Everyone else:** confirm they are meant to be SSO-only.

Write the exempt list down before the migration date. After the migration, watch Login History for the status "Denied: Single Sign-On Required" (confirm the exact wording in your org). A spike from a service account means an integration user was caught.

After migration

Re-run the query above and compare it to your pre-migration list
Confirm the legacy "Disable login with Salesforce credentials" setting is now read-only
Log in as an admin and as each integration user to confirm access still works
Filter Login History for "Denied: Single Sign-On Required" daily for the first two weeks
Assign the new permission deliberately to any new user who must be SSO-only

FAQ

What is the Salesforce Single Sign-On Required permission?

A new user permission that marks a user as SSO-only. It replaces the org-wide "Disable login with Salesforce credentials" setting for that purpose.

When does it reach production?

Per Salesforce's published schedule, Nov 6, 2026. Eligible production orgs auto-migrate Jan 4-22, 2027.

Will my new users be SSO-only after migration?

No. New users are not SSO-only unless the new permission is assigned to them.

Want to see where your org stands before the migration? The free health check is a short questionnaire that gives a peer-benchmarked score, with no account and no org connection.

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