Salesforce is replacing a legacy combination of settings and permissions used to make selected users SSO-only. The new control, `Single Sign-On Required`, becomes visible in sandboxes on October 23, 2026 and in production on November 6. Eligible legacy configurations are then scheduled for automatic migration in sandboxes from December 1-9 and in production from January 4-22, 2027.

Salesforce says no configuration change is required before the migration and no user disruption is expected. That is reassuring, but it is not a reason to ignore the change. Identity controls sit on a critical path: a technically correct permission can still expose weak provisioning, an untested recovery route, or uncertainty about which human and nonhuman identities depend on direct authentication.

The right objective is not to stop the migration. It is to prove that the migrated control preserves the intended policy, that legitimate SSO journeys still work, that prohibited direct logins remain blocked, and that administrators can recover safely when the identity provider is unavailable.

First, determine whether your Salesforce org is affected

The migration is narrower than the headline may suggest. According to Salesforce, an org is eligible only when all three conditions are true:

  1. `Disable login with Salesforce credentials` is enabled in Single Sign-On Settings.
  2. `Delegated Gateway URL` has no value.
  3. At least one user has the `Is Single Sign-On Enabled` permission.

Organizations using delegated authentication are excluded. Organizations that do not currently require SSO through this exact legacy arrangement are also excluded.

For eligible orgs, Salesforce will assign `Single Sign-On Required` to users who currently have `Is Single Sign-On Enabled`. Profiles and permission sets containing the legacy permission receive the new permission as well. After migration, the legacy org setting becomes uneditable, administrators can no longer assign the old permission, and SSO-only status is managed with the new per-user control.

That is intended to preserve existing behavior. It also makes the effective assignment easier to see and manage. The preparation work should focus on validating the users and business paths behind that assignment.

Why an automatic migration still needs an owner

An identity change can succeed at the platform level while leaving operational gaps elsewhere.

A permission assignment does not prove the SSO journey works

The new permission blocks username-and-password login through supported Salesforce UI and API paths. It does not test the identity provider, SAML or OpenID Connect configuration, user mapping, conditional-access policy, certificate lifecycle, mobile path, or help-desk process.

The migrated assignment and the working end-to-end login journey are two different things. Both must be verified.

Emergency access can fail when it depends on the same system as normal access

Salesforce's SSO guidance recommends not requiring SSO for administrators who may need to respond to an SSO outage or related problem. That does not justify a loosely controlled shared credential. It does mean the organization needs a documented, policy-approved administrative recovery path that is independent of the failed dependency, protected by the required Salesforce authentication controls, monitored, and exercised.

The design should be reviewed with the organization's identity and security owners. Regulated organizations should also align it with their privileged-access, evidence, and incident-response requirements. This article does not establish compliance with any law or standard.

New-user provisioning changes after migration

Salesforce explicitly states that a user created after migration is not automatically SSO-only simply because the org was migrated. The new user must receive `Single Sign-On Required` through a profile or permission set.

That creates a durable operating requirement. If joiner and role-change workflows do not assign the permission, the organization can drift away from its intended authentication policy one user at a time.

API impact must be classified, not guessed

The permission blocks direct username-and-password login through supported API paths for assigned users. It does not mean every API integration stops working, and it should not be treated as a substitute for the separate Salesforce changes affecting OAuth and SOAP `login()`.

Review every affected identity by actual authentication method. Human SSO, OAuth-based integrations, legacy username-password clients, CLI use, middleware, scheduled jobs, and vendor-managed connections have different dependencies. Test the complete transaction rather than inferring behavior from the word "API."

A seven-step readiness plan

Confirm scope in every org

Check production and each sandbox independently. Record the three eligibility conditions, the identity provider, the SSO protocol, the authentication services shown on the login page, and the owner of the configuration.

Do not assume that a full-copy sandbox matches production. Identity-provider assignments, endpoints, certificates, user activation, and authentication policies often differ by environment.

Export the affected-user baseline

Salesforce provides the following query to find permission-set assignments, including profile-owned permission sets, that contain the legacy permission:

sql 
SELECT AssigneeId,
       Assignee.Name,
       Assignee.Username,
       PermissionSet.Label,
       PermissionSet.IsOwnedByProfile
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsIsSsoEnabled = true

Preserve the result as dated evidence. For each assignee, add the user type, business owner, employment or vendor status, privilege level, normal login route, and whether direct API authentication is known to exist.

The purpose is not merely to count assignments. It is to answer: should this identity remain SSO-only, and what business service depends on its ability to authenticate?

Separate identity populations

At minimum, classify:

  • Standard employees
  • Contact-center and operational users
  • External, partner, or community administrators
  • Salesforce administrators and other privileged users
  • Deployment, middleware, and integration identities
  • Vendor-supported identities
  • Dormant, duplicate, or unowned accounts

Healthcare and insurance organizations should pay particular attention to round-the-clock service teams, claims or member-service operations, and third parties whose identity-provider access is managed outside the Salesforce team. Nonprofit foundations should check seasonal staff, grantee or partner operations, and administrators whose responsibilities may be distributed across a small team.

These are risk-prioritization examples, not claims that every organization uses these identity patterns.

Define the intended policy before testing

For every population, state the expected result:

  • Must authenticate through the corporate identity provider
  • May use an approved direct Salesforce login for recovery or a documented exception
  • Must use OAuth or another approved non-password mechanism for system access
  • Must be deactivated or remediated before migration

Name the person who can approve an exception and the evidence required. Without an expected-state register, a successful login test can still validate the wrong policy.

Establish a sandbox test matrix

The new permission becomes visible in sandboxes on October 23, but Salesforce says it cannot be used to enforce SSO until the automatic migration completes. Use the October milestone to inspect availability and prepare. Execute migrated-state tests after the sandbox migration window of December 1-9.

Test representative users and paths, including:

  • Service-provider-initiated SSO from the Salesforce login route
  • Identity-provider-initiated SSO, if supported
  • Desktop and approved mobile access
  • A standard user assigned the new permission
  • A privileged user intended to be SSO-only
  • An approved administrative recovery identity not assigned the permission
  • A direct username-password attempt that should be denied
  • Any affected API client or operational tool, using its real authentication method
  • New-user provisioning and a role change that should add or remove the permission
  • Help-desk diagnosis using Salesforce Login History and identity-provider logs

For a deliberately blocked attempt, Salesforce says Login History should show `Denied: Single Sign-On Required`. For an SSO failure, continue into the identity provider, SAML or OpenID Connect configuration, mapping, and service assignment rather than removing the permission reflexively.

Update provisioning and recovery procedures

Revise the source-of-truth workflow that creates Salesforce users. Whether provisioning is handled through SCIM, an identity-governance platform, service requests, automation, or manual administration, the process must deliberately assign `Single Sign-On Required` to the correct users after migration.

Also update:

  • Joiner, mover, and leaver procedures
  • Permission-set groups and profile ownership
  • Access-review evidence
  • Admin and help-desk runbooks
  • Identity-provider outage procedures
  • Monitoring and alert ownership
  • Deployment tooling that manages affected profiles or permission sets

Exercise the recovery procedure. A document that depends on an unavailable device, an absent approver, an expired credential, or the same failed identity provider is not a reliable recovery path.

Validate production and monitor for drift

After Salesforce migrates the production org during the January 4-22 window:

  1. Re-run the affected-user inventory.
  2. Confirm the expected profiles and permission sets now contain `Single Sign-On Required`.
  3. Test representative SSO and prohibited direct-login paths.
  4. Confirm the approved administrative recovery path.
  5. Review Login History for unexpected denials.
  6. Compare help-desk authentication incidents with the pre-migration baseline.
  7. Sample newly created and recently changed users for correct permission assignment.

Keep heightened monitoring through at least one complete onboarding and access-review cycle. The lasting risk is not the one-time copy of a permission; it is policy drift after the migration.

What success looks like

A successful migration has evidence at four levels:

  • Configuration: the intended users, profiles, and permission sets received the new permission.
  • Authentication: approved SSO paths work and prohibited direct login is denied.
  • Resilience: an authorized administrator can recover during an identity-provider failure without weakening normal controls.
  • Operations: new users and role changes receive the correct permission, and exceptions remain owned and reviewable.

Track outcomes such as unexpected SSO denials, time to diagnose authentication incidents, users missing the required permission after provisioning, unmanaged direct-login exceptions, and failed API transactions tied to affected identities. These measures are more useful than reporting that the migration task was marked complete.

Use the change to simplify identity ownership

The new permission is a cleaner control than the legacy combination it replaces. The migration is also a useful forcing function: it exposes who owns SSO policy, who owns Salesforce permission assignment, who monitors failures, and who can restore access during an outage.

Yuniq's Salesforce consulting and managed support services can help organizations inventory the legacy configuration, classify affected identities, build a representative sandbox test plan, update provisioning and recovery runbooks, and validate the production state. The goal is focused: preserve secure access through the migration and leave behind an authentication process that remains governable after January.