To complete enforcement of the email verification requirement introduced in the Spring ’22 major release, Salesforce now requires all users in all orgs and Experience Cloud sites to verify their email address. If a user sends an email from an unverified email address, Salesforce rejects this email message and doesn’t complete the send. Unverified email addresses can’t be used for sends until the user verifies their email address or resets their password. To avoid disruptions, ensure that all user email addresses are verified.

Where: This change is available in Lightning Experience and Salesforce Classic (not available in all orgs) in all editions.

Who: This requirement applies to all users in all orgs and Experience Cloud sites, including employee, customer, and partner users across sandbox and production instances. Most users affected by this change are SSO users because non-SSO users verify their email address when they sign up. However, some non-SSO users can be affected if they use email addresses that were added to Salesforce before the current verification process existed.

Email verification for org-wide email addresses was already and continues to be required. Any features that use org-wide email address functionality, such as Service Email, already meet email verification requirements.

Why: In past releases, Salesforce enforced this requirement for all orgs and Experience Cloud sites except for paid production instances with single sign-on (SSO) users. In Spring ’24, Salesforce started enforcing the requirement for paid production instances with SSO users, but only for instances created after Spring ’24. With the Summer ’24 release, Salesforce now enforces the requirement for all orgs and Experience Cloud sites, including all paid production instances with SSO users, regardless of when they were created.

How: As a Salesforce admin, check a user’s email verification status by viewing the user’s details. From the Users page in Setup, select a user and check the Email field. When the user completes verification, the Verify link changes to Verified. Users can also see their own email verification status from the Advanced User Details page.

For unverified users, you have several options for verifying their email address. The best method for your use case depends on how many users you’re verifying and what kind of experience you want to provide.

For an individual user, you can initiate verification or the user can do it themselves. With either of these methods, the user receives a Salesforce-branded verification email that can’t be customized.

For a large number of users or to have more control over branding and the user experience, use these options.

• To verify multiple users at once, use the async email method. You can customize the verification email template to suit your brand.
• To automatically verify all email addresses that belong to a specific domain, verify the domain using DomainKeys Identified Mail (DKIM). Use this method when you don’t want users to receive a verification email at all.

Salesforce also verifies a user’s email address during some processes, such as password reset and device activation.

For a full overview of the different ways to verify email addresses, see User Email Verification in Salesforce Help.

https://help.salesforce.com/s/articleView?id=release-notes.rn_security_email_verification.htm&release=250&type=5

To follow recommended security standards, use the new credentials Connect REST API resource instead of Metadata API to access External Client App OAuth consumer credentials.

Where: This change applies Group, Essentials, Professional, Enterprise, Performance, Unlimited, and Developer editions.

When: Salesforce enforces this update in Winter ‘25. To get the major release upgrade date for your instance, go to Trust Status, search for your instance, and click the maintenance tab.

Who: This change applies to existing External Client App users who use Metadata API to access consumer credentials.

Why: Accessing consumer secrets through the credentials endpoint of the Connect REST API removes the possibility of accidentally committing consumer secrets to source control.

How: Access consumer secrets through the credentials endpoint of the Connect REST API. Unless you contact Salesforce Customer Support to continue using Metadata API, your external client apps can’t access consumer secrets via Metadata API after Winter ’25.

https://help.salesforce.com/s/articleView?id=release-notes.rn_security_eca_use_rest_api_for_creds_ru.htm&release=250&type=5

The legacy Firebase Cloud Messaging API server key is no longer accepted for configuring Android push notifications on mobile connected apps. Because of a change in how Google handles push notifications, Android mobile connected apps now require the Admin SDK private key and project ID from a Google Firebase project.

Where: This change applies to mobile connected apps with Android push notifications. Connected apps can be created in Group, Professional, Enterprise, Essentials, Performance, Unlimited, and Developer editions.

How: Get the required information from your Firebase project in the Google Firebase Console. Then submit the information to your mobile connected app’s settings in App Manager.

https://help.salesforce.com/s/articleView?id=release-notes.rn_security_mobile_connected_app_firebase_fields.htm&release=250&type=5

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 external identity provider. With this release update, we’re removing support for the single-configuration SAML framework and supporting only the multiple-configuration SAML framework. To preserve your existing configuration, follow the steps to apply this update. If you don’t, your SSO configuration stops working when this update is enforced. This update was first made available in Spring ’24. It was scheduled to be enforced for all instances in Summer ’24, but we postponed the enforcement date for production instances to Spring ’25. This update is still enforced for sandboxes in Summer ’24.

Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Unlimited, and Developer editions.

When: This update is enforced for production instances in Spring ’25 and is enforced for sandboxes in Summer ’24. This update was scheduled to be enforced for all instances in Summer ’24 but was postponed to Spring ’25 for production instances only. To get the major release upgrade date for your instance, go to Trust Status, search for your instance, and click the maintenance tab.

Why: We’re no longer supporting the single-configuration SAML SSO framework that you’re currently using. When this update is enforced, you’re required to use a multiple-configuration SAML framework. To keep using your existing SAML SSO configuration, migrate to the multiple-configuration framework. Otherwise, your SAML SSO stops working for you when this update is enforced.

How: These changes apply to your existing SAML SSO configuration.

• SAML responses from your identity provider must include the audience attribute.
• Your Salesforce Login URL changes.
• If Salesforce can’t parse a SAML response, it isn’t recorded in the login history.

Make sure you understand these changes, update your configuration accordingly, and test all changes in a sandbox before enabling this update. If you don’t, your configuration stops working when this update is enforced.

To review this update, from Setup, in the Quick Find box, enter Release Updates, and then select Release Updates. For Migrate to a Multiple-Configuration SAML Framework, follow the testing and activation steps.

https://help.salesforce.com/s/articleView?id=release-notes.rn_security_saml_release_update.htm&release=250&type=5

For better usability when configuring the OAuth 2.0 token exchange flow, define and enable OAuth 2.0 token exchange handlers in Setup instead of using Metadata API. Create a handler definition, link it to an Apex class, and set some of its properties, such as what types of tokens it supports and whether it can create users.

Where: This change applies to Lightning Experience (not available in all orgs) in Enterprise, Performance, Unlimited, and Developer editions.

Why: The token exchange flow simplifies your integration patterns for use cases that include a central identity provider, such as Okta, along with multiple service providers and microservices.

How: From the Token Exchange Handlers page in Setup, define and enable the handler. The ability to edit the handler in Setup isn’t currently supported. To edit its definition, use Metadata API.

https://help.salesforce.com/s/articleView?id=release-notes.rn_security_token_exchange_setup.htm&release=250&type=5

Give users uninterrupted access across custom apps and Salesforce. With the new Single-Access UI Bridge API, use an existing Salesforce access token to load a new session in a Salesforce UI, such as a Visualforce site or mobile app. For example, when users are logged in to a headless app, redirect them to your Experience Cloud site to view Support cases without making them log in again.

Where: This change applies to Lightning Experience and Salesforce Classic in all editions.

How: Using a POST request, send an access token to the new /services/oauth2/singleaccess endpoint on your My Domain or Experience Cloud site. Salesforce returns a JSON response with a frontdoor.jsp URL. Use the URL to redirect the user and load a new, authenticated session in a custom interface.

https://help.salesforce.com/s/articleView?id=release-notes.rn_security_frontdoor_url.htm&release=250&type=5

The external client apps framework, a new and improved generation of connected apps, is catching up to connected apps fast. The new framework now supports headless login, passwordless login, and guest user flows using the Authorization Code and Credentials Flow. You can also configure an external client app to issue JSON Web Token (JWT)-based access tokens.

Where: The changes to support the Authorization Code and Credentials Flow apply to LWR, Aura, and Visualforce sites accessed through Lightning Experience and Salesforce Classic in Enterprise, Unlimited, and Developer editions. The changes to support JWT-based access tokens apply to Lightning Experience and Salesforce Classic in Group, Essentials, Professional, Enterprise, Performance, Unlimited, and Developer editions.

Why: Unlike the connected apps framework, the external client apps framework is compatible with second-generation packaging (2GP), making apps easier to package and distribute. It’s also more secure and fully metadata-exposed. And its design makes it easy to define clear roles for developers and admins.

How: Create and edit external client apps via the External Client App Manager in Setup, or use Metadata API. External client apps currently support all variations of the Authorization Code and Credentials Flow except headless registration.

https://help.salesforce.com/s/articleView?id=release-notes.rn_security_eca_oauth.htm&release=250&type=5

Try the new External Client App Manager to create, manage, and update your external client apps. You can still do all these things with Metadata API, but this new user interface means that now you don’t have to. With External Client App Manager,you can create a local app just for your org or design one to package and distribute.

Where: This change applies to Lightning Experience in Professional, Performance, and Unlimited editions.

Who: The External Client App Manager is shown only to Lightning Experience-enabled users on orgs that have opted in to External Client Apps.

Why: As part of the new generation of Connected Apps, External Client Apps offers the ability to connect external applications with Salesforce data while maintaining security and clearly defining user roles. External client apps are designed with the security of second-generation managed packaging in mind.

https://help.salesforce.com/s/articleView?id=release-notes.rn_security_eca.htm&release=250&type=5

Take control of identity experiences for customers and partners. Use the new Welcome New Member for Passwordless Registration email template to customize the one-time password (OTP) email that users receive when they sign up for your Experience Cloud site using passwordless registration.

Where: These changes apply to LWR, Aura, and Visualforce sites accessed through Lightning Experience and Salesforce Classic in Professional, Enterprise, Unlimited, and Developer editions.

https://help.salesforce.com/s/articleView?id=release-notes.rn_security_otp_email.htm&release=250&type=5

To provide branded, personalized identity verification experiences for external users, create an Apex handler to send one-time passwords (OTPs) via an SMS messaging provider of your choice. Customize the content of the message and the short code that tells users who sent it. Use the handler to send OTPs for any Experience Cloud identity verification use case, such as multi-factor authentication (MFA) and passwordless login.

Where: These changes apply to LWR, Aura, and Visualforce sites accessed through Lightning Experience and Salesforce Classic in Enterprise, Unlimited, and Developer editions.

Why: For Experience Cloud sites, use a custom OTP provider for any identity verification use case that uses SMS, such as MFA, passwordless login and registration, self-registration with SMS, and device activation.

For headless apps, use a custom OTP provider to send SMS messages during the headless forgot password, passwordless login, and registration flows.

How: Create a custom one-time password delivery handler Apex class. From your Experience Cloud Login & Registration settings, in the Customized OTP Delivery section, select your Apex handler class.

To opt in to this feature, contact your Salesforce account executive. Opting in to this feature affects all Experience Cloud sites. To avoid disruptions, enable the Apex handler for all sites.

https://help.salesforce.com/s/articleView?id=release-notes.rn_security_custom_otp_beta.htm&release=250&type=5