Data retention is coming to the new, platform-native version of Privacy Center. With data retention, you can copy records to an external data store at the same time that you mask or delete them. You can also view the externally retained records by setting up your retention store with Salesforce Connect. This feature becomes available on a rolling basis starting in July 2024.

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

When: Data retention becomes available in different regions on a rolling basis, beginning in July 2024. For more information about the release timeline or to learn about getting early access to the feature, contact your account executive.

Why: Under data privacy law, your customers have a right to be forgotten by your business or to have their data restricted from processing. To stay compliant, you’re sometimes required to delete, archive, or obfuscate customer data. Now you can add data retention to your compliance strategy without using the managed-package version of Privacy Center.

The platform-native version of Privacy Center is the modernized, enhanced version that we recommend for all customers. Here are some advantages to consider.

• Your Privacy Center license includes data retention as an out-of-the-box feature, along with a limited amount of free storage. Details about the amount of free storage and the cost for additional capacity are coming soon.
• Your production org and sandboxes can have separate retention stores provisioned to them.
• You can import privacy policies directly from a sandbox to a production org and vice versa. With this capability, you can test and deploy your retention implementation seamlessly.
• Privacy Center offers an updated and improved user interface compared to the managed-package version of Privacy Center.

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

Review recent changes to Privacy Center’s user interface and functionality.

• Get Ready to Retain Data with Privacy Center
  Data retention is coming to the new, platform-native version of Privacy Center. With data retention, you can copy records to an external data store at the same time that you mask or delete them. You can also view the externally retained records by setting up your retention store with Salesforce Connect. This feature becomes available on a rolling basis starting in July 2024.
• UI Text and Functionality Improvements in Privacy Center
  To improve the user experience in Privacy Center, we updated the user interface text in several places. We also changed the behavior of two privacy policy filter operators.
• Permission Requirements for the Consent Event Stream Are Enforced
  To receive notifications via the Consent Event Stream, users need either the ReadAllData or the PrivacyDataAccess permission assigned to them. Previously, this requirement was documented but not enforced. To resolve any disruptions that your users experience as a result of this change, assign one of the applicable permissions to them.

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

To reduce performance issues, we now prevent client apps from sending simultaneous token requests with the same refresh token when using the OAuth 2.0 refresh token flow. Previously, identical token requests sent at the same time didn’t fail, but they did lead to system issues across Salesforce. To avoid disruptions, update integrations that use the refresh token flow to stop sending simultaneous, identical requests to the token endpoint. Improve the efficiency of your integrations by reusing access tokens instead of continually requesting new ones.

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

How: When using the refresh token flow, Salesforce processes one token request at a time. If your client sends another request while one is being processed, the Status column in the Login History displays Failed: Token request is already being processed.

To prevent the refresh token flow from failing intermittently, update your integrations.

• Avoid or reduce simultaneous calls to the token endpoint with the same refresh token. Instead, after your client obtains an access token from the refresh token flow, cache the token and reuse it.
• If you continue to make simultaneous, identical requests, which isn’t recommended, develop a way to retry the requests when this error occurs.

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

With new support for larger tokens, use the OAuth 2.0 token exchange flow with a wider range of third-party identity providers. When you send third-party tokens to Salesforce in the subject_token parameter, the value can be up to 10,000 characters long. Previously, the maximum length for values in this parameter was 2,000 characters.

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

How: With the token exchange flow, you configure an app to exchange a token issued by an identity provider for a Salesforce token. To initiate this exchange, your app sends a POST request to the /services/oauth2/token endpoint. The request includes the provider’s token in the subject_token parameter.

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

With changes to how JSON Web Tokens (JWTs) are processed, it’s now easier to extract data from JWTs generated by methods in the Auth.JWTUtil class. We also clarified what methods we support for a JWT depending on where it came from. And you can get more test coverage by mocking HTTP callouts when processing JWTs.

Where: These changes are available in Enterprise, Performance, Unlimited, and Developer Editions.

How: For more information about these changes, see the Auth Namespace section in Apex: New and Changed Items.

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

Although Salesforce doesn’t recommend it, if you must use Embedded Login with your Experience Cloud Site, you can enable it on the Login & Registration page. In Summer ’24, Salesforce disabled Embedded Login by default to encourage users to move to OAuth 2.0 Web Server Flow or OAuth 2.0 User-Agent Flow.

Where: This change applies to Lightning communities accessed through Lightning Experience and Salesforce Classic (not available in all orgs) in Professional, Enterprise, Performance, Unlimited, and Developer editions.

Why: We recommend that you use the web server flow, the user-agent flow, or another redirect-based OAuth 2.0 flow instead of Embedded Login. Embedded Login relies on third-party cookies, which are blocked or restricted in most browsers. And Embedded Login works only on Google Chrome and only as long as third-party cookies are allowed there by default.

How: To use Embedded Login on your Experience Cloud Site, enable the feature on the Login & Registration page. From Setup in the Quick Find Box, enter Digital Experiences, and then select All Sites. In the Digital Experiences picklist, select Workspaces and then click Administration. On the Login & Registration tab select Allow embedded login on your Experience Cloud site.

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

For more consistency with naming conventions, we renamed the label for the password reset login subtype in the Login History. When a user resets their password, the Login Subtype column now displays UI Password Reset instead of Change Password.

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

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

To monitor login activity more thoroughly and prevent potential threats, you can now see what value the client passed in the X-Forwarded-For header of their HTTP request to Salesforce. For logins that redirect users to one or more proxies, the X-Forwarded-For field is sometimes used to store the origin IP address of the client. Use the new Forwarded for IP column in the Login History and related fields to track the origin IP address. This change isn’t available for OAuth and single sign-on (SSO) logins.

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

Why: Salesforce tracks the Source IP of login requests, but for logins that redirect through multiple proxies, the origin IP address isn’t always reflected in the source IP. In this case, the Forwarded for IP value is a better way to tell where the original request came from.

How: From Setup, in the Quick Find box, enter Login History, and then select Login History. Add the Forwarded for IP column to your Login History list view.

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

To improve security, in Winter ’25, users can no longer log in to Salesforce by passing a username and password as URL query string parameters in the login URL, also known as forced login. This change will break implementations and third-party integrations that use a forced login via a URL, as well as direct login (autologin) links. To avoid service disruptions, update integrations that use forced login.

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

When: This change takes effect in Winter ’25.

Why: In the Spring ’22 release, Salesforce enforced a release update that disabled the ability for users to log in using their credentials, but some orgs are still using this feature. With this change, forced login is permanently disabled in all orgs.

How: To prepare for the change, first review org usage of forced login. From Setup, in the Quick Find box, enter Login History, and then select Login History. View and download your org’s login history for the past 6 months. Review the HTTP method column. If the HTTP method is GET, and there’s no entry for Login Subtype, it indicates that users are using forced login.

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

Multi-factor authentication (MFA) is turned on by default for direct logins to production orgs as of April 8, 2024. Starting in Summer ’24, admins get in-app reminders if they don’t comply with the MFA requirement.

Where: The change to turn on MFA by default applies to Lightning Experience, Salesforce Classic, and all versions of the mobile app in all editions. The change to add in-app reminders applies to Lightning Experience and all versions of the mobile app in all editions.

How: For more information on these changes, see MFA Is On by Default for Direct Logins to Production Orgs and Salesforce Admins Get In-App Reminders If MFA Is Turned Off

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