Use login history and login events to see Authentication Context Class Reference (ACR) values sent by SSO identity providers. Protect your data by switching to the OAuth 2.0 web-server or client credentials flows before the username-password flow stops working.
- Prepare for Login Changes
Salesforce plans to make two changes to simplify and improve your login experience. Starting in June 2026, Salesforce prompts users to enter only their username as the first login step. And starting in August 2026, login with an email address becomes the default experience. - View Authentication Context Class Reference (ACR) Values in the Login History and Login Events
You can now use the login history and login events to see Authentication Context Class Reference (ACR) values sent by your single sign-on (SSO) identity provider. Use this information to determine whether your identity provider uses a strong or weak authentication method. SSO logins with strong ACR values can skip device activation. - Retirement of OAuth 2.0 Username-Password Flow for Connected Apps (Release Update)
When this release update is enforced, 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. - OAuth User-Agent and Hybrid User-Agent Flows Retirement (Release Update)
Salesforce is retiring the OAuth user-agent flow and the OAuth hybrid user-agent flow. For better security, update your integrations to use the OAuth web-server flow or hybrid web-server flow with the Proof Key for Code Exchange (PKCE) extension. - 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 no longer support 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. - Triple DES for SAML Single Sign-On Is No Longer Supported
The Triple Data Encryption Standard (Triple DES) algorithm is no longer supported for SAML single sign-on (SSO). If your configuration still uses Triple DES, users can’t log in via SSO. 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. - 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. - Authentication Provider UI Labels Are Updated
To improve usability, we renamed some labels on the authentication provider pages in Setup. - Valid Session Is Always Required for Email Address Changes
To improve security, Salesforce now requires a valid session for all email address changes. If a user doesn’t have a valid session, Salesforce prompts them to log in to complete the email address change. Previously, Salesforce required a valid session only if the setting “Require identity verification for email address changes” on the Identity Verification page was enabled. - Test Step-Up Authentication
To prepare for upcoming security requirements, you can now enable step-up authentication for different setup areas in your org. With step-up authentication, Salesforce prompts users for periodic authentication to take certain actions. To control how often users are prompted, configure the step-up authentication period. The maximum period is 2 hours. - Disabling External Client Apps Now Blocks SAML Login
We fixed a security gap where external client apps still allowed SAML single sign-on (SSO) using Salesforce as an identity provider, even when the app or its SAML plugin was disabled. Now, for SSO to work, both the app and the SAML plugin must be enabled. If either one is disabled, the SSO login fails. - Package External Client Apps in First-Generation Managed Packages
Package external client apps in first-generation managed packages to distribute them to other orgs. Create an external client app with Packaged distribution state, add it to your managed package, and install it in subscriber orgs alongside other packageable components. - Enable Native Browser Authentication for iOS Before Passkey Enforcement
Before you enable passkey enforcement for mobile SDK apps on iOS, turn on native browser authentication in My Domain. Otherwise, users who register passkeys are permanently locked out of your mobile app and must reinstall it or clear app data to recover. - OAuth Security Controls Are Enforced for New External Client Apps and Connected Apps
Starting in July 2026, Salesforce enforces OAuth security controls for new external client apps and connected apps. The Proof Key for Code Exchange (PKCE) extension is required for apps that use the authorization code grant type. For apps that use the refresh token flow, Salesforce requires two controls: refresh token rotation and a 30-day limit to the time-to-live (TTL) for idle refresh tokens. - Manage Passkeys and Security Keys With Ease
It's now much easier to set up and manage phishing-resistant verification methods for passwordless login and multi-factor authentication (MFA). On the new Passkeys page in your personal settings, you can view your registered passkeys and security keys, set up new ones, and delete ones that you no longer use. - Passkey-First MFA Registration and Improved Passkey Experience
Passkeys are one of the most secure, fastest, and easiest ways to log in to Salesforce, and we want all users to experience their security and usability benefits. Passkeys are now the first verification method that users see for multi-factor authentication (MFA) registration, regardless of your org’s previous identity verification settings. We also simplified the passkey registration and login experiences. Instead of separate experiences for built-in authenticators and security keys, we now have unified passkey experiences. - Usability Improvements for MFA Registration Pages
To improve the multi-factor authentication (MFA) user experience, we updated the pages where users select a verification method. The updated pages use clearer terminology that is less technical and more user-friendly. They also highlight passkeys as a recommended method, which guides users toward faster, easier, and more secure MFA. These changes improve the user experience for enforcement of the multi-factor authentication (MFA) requirement for employee users. - Identity Verification Is Required to Register New MFA Verification Methods
When multi-factor authentication (MFA) requirements are enforced in your org, users must verify their identity to register new verification methods. Users can verify their identity with another verification method that's already registered on their account. If they don't have a registered verification method, Salesforce sends a one-time verification code to their email address or phone number. - View Phishing-Resistant, Standard, and Weak MFA Methods in the SAML Assertion Validator
Use the SAML Assertion Validator to determine whether your single sign-on (SSO) provider satisfies multi-factor authentication (MFA) requirements, including phishing-resistant MFA for privileged users. The validator now shows you whether your SSO provider’s authentication signals are classified as phishing-resistant, standard, or weak. Previously, it only classified values as strong or weak. - Added, Removed, and Reclassified Single Sign-On Authentication Signals for Multi-Factor Authentication
For multi-factor authentication (MFA) requirements, Salesforce has added support for some single sign-on (SSO) authentication signals and removed support for others. Salesforce has also reclassified several signals from phishing-resistant to standard. - Restrict the OAuth 2.0 Device Flow to Local External Client Apps (Release Update)
To secure the OAuth 2.0 device flow, Salesforce is restricting this flow to local external client apps with a localhost callback URL. To prepare for this change, review your usage of the device flow and update your connected apps and external client apps to meet the new criteria. For connected apps, you must migrate to external client apps to continue using the device flow. - Monitor Usage of the OAuth 2.0 Device Flow
To monitor usage of the OAuth 2.0 device flow, use the new OAuth Device login subtype. This new login subtype helps you identify affected apps to prepare for upcoming restrictions to device flow usage. Previously, usage of the device flow was tracked under the OAuth Web Server login subtype. - Migrate Packaged and Distributed Connected Apps to External Client Apps
Safeguard your org from security risks by migrating your packaged and distributed connected apps to packaged external client apps. Use the connected app migration tool to create a packaged external client app. Migrate connected apps that are packaged in first-generation or second-generation managed packages as well as those distributed to other internal orgs to packaged external client apps. Customer OAuth flows, tokens, and active sessions remain valid through package upgrade, so there's no need to reconfigure or reauthorize for the packaged external client app. - Only Stage and Rotate OAuth Credentials for Local External Client Apps
Use the OAuth Staged Credentials Connect REST API endpoint to manage the OAuth key and secret for only local external client apps. The initial release note and the help topic for this feature didn't specify that credentials can't be staged and rotated for packaged external client apps.