Upgrade SAML Single Sign-On Framework (Release Update)
Salesforce is upgrading its SAML framework as part of regular maintenance. This update can affect integrations with third-party systems, such as integrations with SAML identity providers and SAML-enabled applications. This update applies to all SAML-based integrations, including Identity for Employees, and Salesforce Customer Identity, including Experience Cloud.
Where: This change applies to Lightning Experience and Salesforce Classic in all editions.
When: This update was first made available in Summer ’22 and is enforced in Spring ’23. To get the major release upgrade date for your instance, go to Trust Status, search for your instance, and click the maintenance tab.
Why: This maintenance update improves your security posture and can increase the platform’s performance. Some single sign-on (SSO) URLs are now encoded. For service provider-initiated SSO, the Identity Provider URL and Assertion Consumer Service (ACS) URL are encoded. For all single logout configurations, the Single Logout Endpoint and relay state parameter are encoded. All existing SAML-based integrations can be affected.
Because Salesforce uses SAML to integrate with third-party systems, this upgrade can break integrations on the third party’s side. To avoid disruptions, apply this release update and test your SAML integrations.
Upgrade SAML Single Sign-On Framework (Release Update) (salesforce.com)
Monitor Connected App Logins That Use Insecure Flows
In Login History, view logins into connected apps that use user-agent or username-password login flows. With new OAuth Flow Enhancements, you can monitor use of these insecure flows to determine the impact of blocking them.
Where: This change applies to Lightning Experience and Salesforce Classic in all editions.
Why: You can block user-agent and username-password login flows so that developers can’t use them to build new integrations. Blocking these flows is likely to break mobile applications, including those developed by Salesforce such as the Salesforce mobile app and the Field Service mobile app. Blocking is also likely to break managed packages. To avoid disruptions, monitor logins to see which apps use these flows.
How: From Setup, in the Quick Find box, enter Login History, and then click Login History. Click Create New View.
To restrict the new view to show only login subtype data, under Step 2: Specify Filter Criteria, select Login Subtype and equals, then click 
and select the login subtype values to include.
To display the Login Subtype column in the new view, under Step 3: Select Fields to Display, add the Login Subtype field. Finish creating the Login History view, and then save.
Monitor Connected App Logins That Use Insecure Flows (salesforce.com)
Insert Consumer Secrets in Authentication Providers Manually in All Change Sets and Packages
Beginning in November 2022, if a change set or package includes an authentication provider with a consumer secret defined, the consumer secret is changed to a placeholder value. You must insert the consumer secret manually after deployment. Beginning with the Spring ’23 release, this change applies to all change sets and packages, including those generated before November 2022. When you import an authentication provider, the consumer secret is treated as a plaintext value, even if the value was encrypted when the authentication provider was created.
Where: This change applies to Lightning Experience and Salesforce Classic in all editions.
Check the Revocation Status of User Authentication Certificates
Enhance the security of certificate-based logins to Salesforce by checking the revocation status of user certificates. This setting prevents logins with certificates that are revoked or can’t be validated. Before you enable revocation status checks, make sure that your uploaded user certificates contain Online Certificate Status Protocol (OCSP) or Certificate Revocation List (CRL) endpoints.
Check the Revocation Status of User Authentication Certificates (salesforce.com)
Chatter Free and Chatter External Users Are Automatically Excluded from MFA Auto-Enablement and Enforcement
Salesforce users with the Chatter Free or Chatter External license are exempt from the multi-factor authentication (MFA) requirement. When the Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org setting gets turned on, either by you or by Salesforce, the setting automatically excludes these users. Keep in mind that you may need to exclude other MFA-exempt use cases on your own.
MFA Auto-Enablement: Find Out When and How Your Org Is Affected (Release Update)
As of February 1, 2022, Salesforce requires all customers to use multi-factor authentication (MFA) when accessing Salesforce products. To help customers meet this requirement, Salesforce is automatically enabling MFA for production orgs in several phases via the MFA Auto-Enablement Release Update. For orgs in the first phase, MFA is auto-enabled with Spring ’23. For orgs in the second phase, MFA is auto-enabled with Summer ’23.
Where: This change applies to Lightning Experience, Salesforce Classic, and all Salesforce mobile apps in all editions.
When: To know when your production org is affected, monitor the Release Update node in Setup for the MFA Auto-Enablement Release Update.
- Phase 1 orgs: The release update for this phase was made available in Winter ’23 and goes into effect with Spring ’23. To get the major release upgrade date for your instance, go to Trust Status, search for your instance, and click the maintenance tab. Note that the MFA release update usually takes effect at the time your org is updated to Spring '23, but in some cases there could be a delay of several hours to a few days before MFA is auto-enabled for your users.
- Phase 2 orgs: If you see the release update after Spring ’23 finishes rolling out, your org is scheduled to be auto-enabled with Summer ’23. In rare cases, it can take several weeks for the update to appear after the Spring ’23 release is complete.
- For orgs not included in phase 1 or 2, the release update will be available in a later release.
How: The release update automatically turns on this setting: Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org. Users who have the Multi-Factor Authentication for User Interface Logins user permission experience no changes.
When MFA is turned on for your org, the process for logging in to the UI changes. After a user enters their username and password, they must verify their identity with an MFA verification method such as an authenticator app, security key, or built-in authenticator. If users haven’t done so already, they’re prompted to register a verification method the next time they log in after this release update goes into effect.
To prepare for this update, we recommend taking these steps.
- Verify whether your org has exempt user types that need to be manually excluded from MFA before MFA auto-enablement occurs. See Exclude Exempt Users from MFA in Salesforce Help.
- Train your users on how to acquire, register, and log in with MFA verification methods. See Change Management for a Successful MFA Rollout for guidance and customizable templates.
If your users aren’t prepared to start using MFA when Salesforce auto-enables it, you have two options.
- Your users can skip MFA registration for 30 days and can log in as usual. This grace period begins on the day the org is auto-enabled, and the same 30-day window applies to all users in the org. For example, if a user logs in five days after their org was auto-enabled, 25 days remain before they’re required to register for MFA.
- In the unlikely event that users experience issues with MFA, you can temporarily disable it. But keep in mind that when your org reaches the MFA enforcement milestone in the future, Salesforce will re-enable MFA and the option to disable it will be removed.
- From Setup, in the Quick Find box, enter Identity, and then select Identity Verification.
- Deselect Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org.
- Save your changes.
MFA Auto-Enablement: Find Out When and How Your Org Is Affected (Release Update) (salesforce.com)
Identity and Access Management
The first phase of multi-factor authentication (MFA) auto-enablement is in effect. Salesforce offers more capabilities for SAML single sign-on and certificate-based authentication methods. Manage insecure login flows and consumer secrets with greater visibility and security. Provide your Experience Cloud users with a streamlined and branded identity experience. Log in to Salesforce Easy orgs with an email address, and if you have access to more than one Salesforce Easy org, use the Environment Switcher dashboard to select which org to log in to.
- MFA Auto-Enablement: Find Out When and How Your Org Is Affected (Release Update)
As of February 1, 2022, Salesforce requires all customers to use multi-factor authentication (MFA) when accessing Salesforce products. To help customers meet this requirement, Salesforce is automatically enabling MFA for production orgs in several phases via the MFA Auto-Enablement Release Update. For orgs in the first phase, MFA is auto-enabled with Spring ’23. For orgs in the second phase, MFA is auto-enabled with Summer ’23. - Chatter Free and Chatter External Users Are Automatically Excluded from MFA Auto-Enablement and Enforcement
Salesforce users with the Chatter Free or Chatter External license are exempt from the multi-factor authentication (MFA) requirement. When the Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org setting gets turned on, either by you or by Salesforce, the setting automatically excludes these users. Keep in mind that you may need to exclude other MFA-exempt use cases on your own. - Check the Revocation Status of User Authentication Certificates
Enhance the security of certificate-based logins to Salesforce by checking the revocation status of user certificates. This setting prevents logins with certificates that are revoked or can’t be validated. Before you enable revocation status checks, make sure that your uploaded user certificates contain Online Certificate Status Protocol (OCSP) or Certificate Revocation List (CRL) endpoints. - Insert Consumer Secrets in Authentication Providers Manually in All Change Sets and Packages
Beginning in November 2022, if a change set or package includes an authentication provider with a consumer secret defined, the consumer secret is changed to a placeholder value. You must insert the consumer secret manually after deployment. Beginning with the Spring ’23 release, this change applies to all change sets and packages, including those generated before November 2022. When you import an authentication provider, the consumer secret is treated as a plaintext value, even if the value was encrypted when the authentication provider was created. - Monitor Connected App Logins That Use Insecure Flows
In Login History, view logins into connected apps that use user-agent or username-password login flows. With new OAuth Flow Enhancements, you can monitor use of these insecure flows to determine the impact of blocking them. - Upgrade SAML Single Sign-On Framework (Release Update)
Salesforce is upgrading its SAML framework as part of regular maintenance. This update can affect integrations with third-party systems, such as integrations with SAML identity providers and SAML-enabled applications. This update applies to all SAML-based integrations, including Identity for Employees, and Salesforce Customer Identity, including Experience Cloud. - Take Charge of Your Identity Experiences with Headless Login and Forgot Password Flows
Get ready to create identity experiences that are convenient for your customers and partners and consistent with your brand. With new Headless Identity APIs for Login and Forgot Password, you can control the user experience in a third-party app while relying on Salesforce for authentication. Your users log in, access their data, and manage their passwords without leaving your app. Behind the scenes, your Salesforce implementation uses authentication APIs called via an Experience Cloud site to handle authenticating users, authorizing data access, and resetting passwords. - Simplify Login to Salesforce Easy with Welcome.salesforce.com and the Environment Switcher
Log in to Salesforce Easy by using an email address on welcome.salesforce.com. You can use the Environment Switcher dashboard to select the org that you want to open if you can access multiple Salesforce Easy orgs via a single email address. - Other Changes in the Salesforce Authenticator Mobile App
The Salesforce Authenticator mobile app has new device and version requirements.
Identity and Access Management (salesforce.com)
New Permissions for Creating Contracts and Service Contracts
To create contracts or service contracts from an opportunity or order, users now require Create access on assets in addition to the existing Read and Edit asset requirements.
Where: This change applies to Salesforce Lightning and Salesforce Classic in Salesforce CPQ and Service Cloud for Salesforce CPQ.
New Permissions for Creating Contracts and Service Contracts (salesforce.com)
Assign New Access Permission Sets and Review New Permissions (Release Update)
Ensure that users have secure and appropriate levels of access to objects and fields. Assign the new Salesforce CPQ Admin User Access and Salesforce CPQ Partner User Access permission sets to your Salesforce CPQ admins and partner users. Review the new permissions added to the Salesforce CPQ Customer User Access permission set. Then use a CPQ package setting to test the permission sets before they’re enforced in Spring ’22.
Where: This change applies to Lightning Experience and Salesforce Classic in Salesforce CPQ.
When: Salesforce enforces this update in Spring ’22. To get the major release upgrade date for your instance, go to Trust Status, search for your instance, and click the maintenance tab.
Why: A series of four Access permission sets and requirements contain data security–related permissions. In Summer ’21, we added the permission sets User Access and Customer User Access. In Winter ’22, we added permission requirements to the Customer User Access set, and we added two more sets, Partner User Access and Admin User Access. We also introduced the same data-security permissions to standard CPQ permission sets.
As permission requirements are added in future releases, two methods help ensure that your users never risk missing important data security updates.
- If you cloned or created custom permission sets for admins, users, partners, or customers, assign the appropriate Access set. We designed Access sets for assignment directly to your users, without cloning or editing.
- If you don’t clone or use custom permission sets, you can use the standard sets alone, without assigning Access sets,
For example, let’s say you assign a customized admin permission set to admins and the standard Customer User set to customers. In this case, assign the Admin User Access permission set to your admins. Your customers can continue using the Customer User set without changes.
For a complete list of new permissions in each Access permission set, review New and Changed Objects, Fields, and Permissions in Salesforce CPQ and Billing Winter ’22.
How: To review this update, from Setup, in the Quick Find box, enter Release Updates, and then select Release Updates.
Data restrictions for the Access permission sets are enforced in Salesforce CPQ Spring ’22. Until then, you have some options for testing them in your org. When the CPQ package setting Perform Enhanced Data Access Checks is active, Salesforce CPQ enforces data restrictions for the Access permission sets. When Perform Enhanced Data Checks is inactive, the Access permission set restrictions aren't enforced.
To start testing, assign the Salesforce CPQ User Access set to your users. Then assign the Salesforce CPQ Customer User Access set to your customer users. Next, from Setup, in the Quick Find box, enter Installed Packages, and then click Installed Packages. Go to Salesforce CPQ and click Configure. In the Additional Settings tab, select Perform Enhanced Data Access Checks.
You can turn Perform Enhanced Data Access Checks on and off as needed before Spring ’22. In Spring ’22, we'll remove the Perform Enhanced Data Access Checks setting and enforce data restrictions for the Access permission sets.
Assign New Access Permission Sets and Review New Permissions (Release Update) (salesforce.com)
Salesforce CPQ
Permissions were added to standard permission sets, and Access permission sets were updated.
- Assign New Access Permission Sets and Review New Permissions (Release Update)
Ensure that users have secure and appropriate levels of access to objects and fields. Assign the new Salesforce CPQ Admin User Access and Salesforce CPQ Partner User Access permission sets to your Salesforce CPQ admins and partner users. Review the new permissions added to the Salesforce CPQ Customer User Access permission set. Then use a CPQ package setting to test the permission sets before they’re enforced in Spring ’22. - New Permissions for Creating Contracts and Service Contracts
To create contracts or service contracts from an opportunity or order, users now require Create access on assets in addition to the existing Read and Edit asset requirements.