Connected app creation is disabled by default for all Salesforce orgs. The Salesforce-managed app for the X (formerly Twitter) auth provider is being retired. Create a Canvas app with an external client app. Migrate SAML-enabled connected apps to external client apps.
- Creation of New Connected Apps Is Disabled by Default
The ability to create new connected apps is disabled by default for all Salesforce orgs. This change improves security by removing the risks associated with connected apps. This update does not affect any existing connected apps, which will continue to function normally. Also, packaged, existing connected apps that are deployed in a new org aren't affected. We recommend using external client apps for all new integrations and migrating existing connected apps to external client apps. - Configure Canvas Plugin for External Client App
You can now create a Canvas app using the external client app framework, which is a more secure and modern replacement for connected apps. Existing connected apps with Canvas integrations continue to function normally, including those that are packaged and deployed. We recommend using external client apps for all new Canvas integrations. - Track Attempts to Use Uninstalled Connected Apps
You can now track denied attempts to use connected apps that aren't installed in your org (uninstalled apps for short). By tracking these denied attempts, you can identify both legitimate and suspicious attempts to use uninstalled apps. You can decide whether to allow usage of the app or to block it entirely. - New and Updated Security Alerts for OAuth Flows
To discourage users from connecting unfamiliar third-party apps to Salesforce, we added security alerts for OAuth flows. These security alerts appear when a user connects a device to Salesforce via the OAuth 2.0 device flow. We also updated the security alert on the page where users authorize access to their data via OAuth 2.0 flows. - Device Activation Is Required for Single Sign-On
As part of ongoing measures to uplift security, we’re enforcing a new device activation requirement for users who log in via single sign-on (SSO). We’ll require device activation if the SSO provider doesn’t use authentication methods that meet Salesforce security standards. We’re enforcing this requirement in phases based on the type of identity provider. - API-Only Users Are Blocked from Bridging into UI Sessions
To improve security, users with the API Only User permission can no longer bridge into UI sessions by using the frontdoor URL generated by the /services/oauth2/singleaccess endpoint, also known as UI Bridge API. This change can break integrations that unintentionally grant UI access to API-only users. - Set Up Passwordless Login with Passkeys (Generally Available)
Give users a fast, easy, and phishing-resistant alternative to passwords. Passwordless login with passkeys is now generally available. With this feature, users can log in with a built-in authenticator (such as Touch ID or Face ID) or a security key (such as a YubiKey or mobile device). Look forward to fewer password resets, fewer login issues, and happier users. - Migrate SAML-Enabled Connected Apps to External Client Apps
Bring the improved usability and security of the external client apps framework to your SAML single sign-on (SSO) configurations. With a few clicks, you can now transform SAML-enabled connected apps into external client apps. After migration, you get an identical external app with all of your SAML configurations, while your old connected app remains in read-only mode. - Migrate to a Multiple-Configuration SAML Framework (Release Update)
If you see this release update, your Salesforce instance is using our original single-configuration SAML framework, which supports single sign-on (SSO) with only one identity provider. We’re giving you a final reminder that with Summer ’26, we’re no longer supporting the single-configuration SAML framework. To make sure that your SSO configurations don’t break, migrate to our newer multiple-configuration SAML framework, which supports SSO with multiple identity providers instead of just one. If you don’t migrate, your SAML SSO configurations will stop working when this release update is enforced in Summer ’26. - Salesforce-Managed X (Formerly Twitter) Authentication Provider Retirement (Release Update)
The Salesforce-managed app for the X (formerly Twitter) authentication provider is being retired. This update breaks any single sign-on (SSO) configurations that use the Salesforce-managed X app. To avoid disruptions, create a custom X app and update your SSO configurations. - New LinkedIn Authentication Providers Use LinkedIn API v2
To stay up to date with the latest LinkedIn API version, new LinkedIn authentication providers now use LinkedIn API v2. Configurations that you created before Spring ’26 still use LinkedIn API v1. Also, new and existing authentication providers that use the Salesforce-managed LinkedIn app still use LinkedIn API v1. - Triple DES for SAML Single Sign-On Stops Working in Summer ’26
In Summer ’26, SAML single sign-on (SSO) configurations that use the Triple Data Encryption Standard (Triple DES) algorithm will stop working. This change applies to all SSO configurations that use the Triple DES algorithm, whether you use Salesforce as an identity provider or as a service provider. To improve security, use the Advanced Encryption Standard (AES) algorithms, AES 128 or AES 256, instead. - Sandbox Users with Non-Unique Usernames Can't Be Unfrozen
You can't unfreeze a sandbox user if their username exists in another sandbox instance. This change prevents duplicate usernames for active, unfrozen users. To unfreeze a user with a non-unique username, update the username to a unique value. - Create an External Client App in a Scratch Org
Build local external client apps in your scratch org. Before Spring '26, local external client apps couldn't be created on scratch orgs. At that time, the only way to get an external client app on a scratch org was to package it and associate it with an existing external client app on a Dev Hub org. - Verification Method Order Is Changed
Salesforce now uses this order of precedence for identity verification methods: built-in authenticators, security keys, Salesforce Authenticator, and third-party authenticator apps. Previously, this was the order of precedence: the Salesforce Authenticator mobile app, built-in authenticators, security keys, and third-party authenticator apps. This change affects verification method registration, multi-factor authentication (MFA), and device activation. As part of this change, we changed the "Show all verification method registration options instead of starting with Salesforce Authenticator" setting to "Show all verification method registration options instead of starting with built-in authenticators." The updated label is currently English-only. Translations are scheduled to be available in April 2026, but this is subject to change. - Retirement of OAuth 2.0 Username-Password Flow for Connected Apps (Release Update)
In Winter ’27, we'll stop supporting the OAuth 2.0 username-password flow for connected apps. This update will break all connected app integrations that use this flow. For better security, update your integrations to use the OAuth 2.0 web-server flow or the OAuth 2.0 client credentials flow instead. - Check Authentication Method Strength with the SAML Assertion Validator
We made it easy to check for strong authentication methods in SAML responses from your single sign-on (SSO) identity provider. You can now use the SAML Assertion Validator to check the strength of Authentication Method Reference (AMR) and Authentication Context Class Reference (ACR) values. Previously, the SAML Assertion Validator showed you ACR values but not AMR values, and it didn't include any information about their strength. - Heading Was Added to Salesforce Login Pages
For a more intuitive login experience, we added a clear “Salesforce login” heading to several login pages. - Improved Support for IPv6 and Private IPs
We significantly increased the IPv6 address limit for trusted IP ranges and profile IP ranges, and we now exclude private IPs from10.0.0.0to10.255.255.255when calculating the total. If your IPv6 ranges are now under the new limit of 2^99 (2 to the power of 99), users can log in from allowlisted IPs without completing device activation. We apply this limit separately from the IPv4 limit, which is still 16,777,216. - Prepare for Email to Become the Default Login Experience
Starting in September, email-based login becomes the default login experience for the UI of login.salesforce.com and test.salesforce.com. This update creates a unified login process and simplifies the experience for your users. While your users can still choose to log in with a username and password, prepare them for email to appear as the primary option. - Allow OAuth Refresh Tokens Only in Certain IP Ranges
Secure your external client apps and connected apps by restricting OAuth refresh tokens to known network locations. This security enhancement ensures that refresh tokens are rejected if they originate from an IP address outside of your defined ranges. Your developers can now prevent unauthorized token use even if a valid token is compromised. - Troubleshoot Formatting Issues in SCIM Payloads
Resolve JSON payload issues when managing user identity with the System for Cross-Domain Identity Management (SCIM). When you send an incorrectly formatted payload to a SCIM endpoint, Salesforce now returns a descriptive error message. - Limit the Idle Refresh Token TTL (Time-to-Live) to 30 Days
Protect your data from unauthorized use of old, idle refresh tokens. For improved external client app and connected app security, set a 30-day limit to the idle refresh token TTL, which is the amount of time a refresh token can be inactive before it expires. The idle TTL works as a sliding window: each time the token is used within the 30-day period, its idle TTL resets. - Lock OAuth Security Controls
To secure your external client apps and connected apps, you can now lock specific OAuth security controls to prevent further edits. These security controls include the settings to require PKCE (Proof Key for Code Exchange) and to enable refresh token rotation. If these controls are enabled, you now see a banner that prompts you to review and lock them. - Stay Informed About MFA Changes with an In-App Reminder
To help you and your users prepare for upcoming multi-factor authentication (MFA) security requirements, Salesforce added an in-app reminder. If your org isn’t compliant with new MFA requirements, all users see a banner that alerts them about the upcoming changes. - Prepare for Step-Up Authentication with an In-App Prompt
With upcoming step-up authentication requirements, Salesforce prompts users to verify their identity for sensitive actions, such as report exports. To help users prepare, Salesforce now prompts them to register a verification method.