• Permission Set Groups: Greater Flexibility in Granting Permissions (Generally Available) – Permission set groups are an ideal way to consistently and reliably assign permissions to a group of users. Assign users a single permission set group instead of multiple permission sets. Permission set groups combine selected permission sets to provide all the permissions that users need for their job function. Remove individual permissions from a group with the muting permission set feature to ensure that permissions do not exceed user job functions.This change applies to Lightning Experience and Salesforce Classic.
• Group Permission Sets Based on User Job Function for Easier Assignment (Generally Available) – Now you can assign users a single permission set group instead of multiple permission sets. Permission set groups combine selected permission sets to provide all the permissions that users need for their job. Similarly, remove individual permissions from a group with the permission muting feature to ensure that users do not get permissions that are not relevant to their job functions. A new user interface helps you create and manage permission set groups.
• Track Permission Set Edits with a New Confirmation Menu – It just got easier to track bulk edits on permissions. We’ve improved readability and security so that multiple-selection permissions and any permission dependencies are summarized on a separate page. With the Permission Changes Confirmation page, you can easily identify and review all added and removed permissions before they become part of your permission ecosystem. Previewing the permission edits summary helps you better manage and maintain security control for your users and organization.
• Manage Permissions in Permission Set Groups with a Muting Permission Set (Generally Available) – A muting permission set is a handy way to increase security and ensure that only components that are required by your organization and users are accessible and, conversely, those components that shouldn’t be accessed are not available. When used along with permissions, a muting permission set gives you granular control over permissions and helps make sure you’re complying with the principle of least privilege.
• External Org-Wide Defaults Are Enabled by Default in All New Orgs – To better secure your data, the External Sharing Model is enabled by default in all Salesforce orgs created in Spring ’20 or later. External org-wide defaults let you set more restrictive levels of access for external users, instead of giving internal and external users the same default access. In these newly created orgs, external access levels are initially set to Private for all objects.
• The External Sharing Model Can No Longer Be Disabled – To better protect your Salesforce org’s data, you can no longer disable the external sharing model after it’s enabled in your org.
• Safeguard Your Data by Setting External Access Levels for the Lead and Campaign Objects (Generally Available) – You can now set external access levels for the Lead object, which was previously in beta, and the Campaign object. Select more restrictive access for external users without changing the default internal access level. The objects available for external org-wide defaults vary depending on your Salesforce org’s licenses and other settings.
• Changes to Sharing API Access – Access to sharing rules and sharing sets through the Salesforce API is available for users with the View Setup and Configuration permission. Editing sharing rules and sharing sets through the API is available for users with the Manage Sharing permission.
• Permission Changes for Queues – Access to queues through the Salesforce API is available for standard and partner users, while editing queues is available for users with the Manage Users permission.
• Authentication and Identity: Apple Sign-In, Identity Verification, and API Access Control – Enable Apple sign-in for your orgs and communities, allowing users to authenticate with their Apple ID, Face ID, or Touch ID. Enhance identity verification security by storing domain verification files for external services and enabling verification methods that are more secure than email. Restrict external user access to Salesforce APIs through connected apps that are installed in your org or community. And apply the Request Signature Methods to single logout, have extra time to approve OAuth authentication requests, and troubleshoot bridged OAuth sessions.
• Domains: Custom Domains for Sandboxes (Pilot), Salesforce Edge, Instanceless URLs, and Certificate Changes for My Domains – Test your Salesforce Sites and Communities in a sandbox using custom domains (Pilot). For customers with a My Domain, certificates are changing and you can accelerate domain requests with Salesforce Edge. Remove instance names from My Domain URLs through critical updates or sandbox refreshes.
• Salesforce Shield: Real-Time Event Monitoring Threat Detection (Beta), Event Monitoring Analytics App Improvements, and Platform Encryption for Platform Events – Use Real-Time Event Monitoring platform events to detect common threats to your org (Beta). We improved the performance of the Event Monitoring Analytics app. The legacy transaction security policy framework will be retired in Summer ’20. Shield Platform Encryption now supports Platform Events in addition to Change Data Capture Events.
• Data Protection and Privacy: Party Consent, Communication Subscription, and Contact Point Objects – Store data related to your customers’ general consent preferences and the communications that they subscribe to. You can also associate multiple email addresses or phone numbers to individuals or person accounts, and manage their preferred time and consent to be contacted.
• Other Security Changes: Guest User Record Assignment, External URL Whitelist, and Setup Enhancements – Set up a default owner for any records created by guest users in Salesforce Sites. Whitelist external URLs that users are allowed to navigate to directly. Plus, we made improvements to Session Security Level Policies and the Setup Audit Trail.
• General Setup: Custom Settings Enhancements and Improved Connections with Enhanced External Services – Protect and control who has access to custom settings. Create better connections to outside services with Enhanced External Services.
• Require Customize Application Permission for Direct Read Access to Custom Settings (Critical Update, Enforced) – Access for users without the Customize Application permission to read unprotected custom settings is revoked as part of this critical update. Using different APIs that are provided by Salesforce, users without the Customize Application permission could read unprotected custom settings. Following the “secure by default” approach, this access is revoked.
• Protect Custom Settings in Developer and Scratch Orgs – The Visibility field is now only available in developer or scratch orgs, where managed packages can be created. When you create a custom setting, the package type and the Visibility field determine whether the custom setting is public or private. You can only create protected custom settings in a developer or scratch org that are then deployed in a managed package. In addition, the Visibility field must be set to protected.
• Control Who Gets Read Access to Custom Settings – You can now control the access of custom settings at a granular level by granting direct Read access to specific custom settings through profiles and permission sets.
• Make More Connections the Enhanced External Services Way (Generally Available) – Enhanced External Services is generally available and enabled by default. It’s easy to use, and provides more ways to create and connect to outside services. Now, when you register a service, you get support for more complex OpenAPI 2.0 schema, nested object types, and send parameters as headers within the HTTP requests.
• Require Permission to View Record Names in Lookup Fields (Critical Update) – To better protect your Salesforce org’s data, we restrict who can view record names in lookup fields. Beginning in Summer ’20, users must have read access to these records or the View All Lookup Record Names permission to view this data. This critical update also applies to system fields, such as Created By and Last Modified By.
• Secure Your Sandbox Data with Salesforce Data Mask – Salesforce Data Mask is a powerful new data security resource for Salesforce admins and developers. Instead of manually securing data and access for sandbox orgs, admins can use Data Mask to automatically mask the data in a sandbox.
• Permission Changes for Administrator Tasks – To access permissions or permission set groups, users must have the View Setup and Configuration permission or the equivalent permissions to manage permission sets or users, including Manage Session Permission Set Activations, Manage Users, and Assign Permission Sets.
• Changes to Managing User Roles and Preferences – Access to user roles is available for users with the View Roles and Role Hierarchy permission. Editing user roles is available for users with the Manage Roles permission. Access to UserPreference records of other users in the SOAP API is available for users with the View All Data or Manage Users permission, but all users can access their own UserPreference record.

Another massive set of permissions changes in the Spring 20 release. Over 20 new features giving you increased control over how users access the platform and what they can do on the platform. Permission set groups in GA, more control over external org wide defaults. Custom settings and much, much more

Access to named credentials through the Salesforce API is available for users with the View Setup and Configuration permission.

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

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

To help you track the recent setup changes that you and other admins make to your Salesforce org, we added new events to the Setup Audit Trail.

Where: This change applies to the Setup Audit Trail, available in Lightning Experience and Salesforce Classic in Contact Manager, Essentials, Group, Professional, Enterprise, Performance, Unlimited, Developer, and Database.com editions.

Why: Track changes to:

• Email Deliverability—Your access to send email in Salesforce, set through the Access level field on the Deliverability Setup page.
• Connected Apps—Your connected app’s PIN length and inactivity timeout, set in the Mobile Integration section of your connected app’s settings. Access these settings from the Manage Connected Apps Setup page.
• Notifications—Your notification delivery settings for custom notification types, set from the Custom Notifications Setup page, and for standard notification types, set from the Notification Delivery Settings Setup page. You can track changes to mobile, desktop, and connected app delivery settings.

How: To view the audit history, from Setup, in the Quick Find box, enter View Setup Audit Trail, and then select View Setup Audit Trail.

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

To better secure sensitive operations in the Users Setup page, you can require users to have a high-assurance session level before accessing the page. Also, we removed the View Event Log Files setting from the Session Security Level Policies section.

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

How: From Setup, in the Quick Find box, enter Identity Verification, and then select Identity Verification. In the Session Security Level Policies section, for Manage Users, select Raise session to high assurance. Click Save.

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

Whitelist URLs outside the Salesforce domain that your users can navigate to directly when the Warn users before they are redirected outside of Salesforce setting is enabled. For URLs that you don’t whitelist, users see a warning message before they get redirected.

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

How: From Setup, in the Quick Find box, enter Whitelisted URLs for Redirects, and then select Whitelisted URLs for Redirects. Click New URL

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

To increase the security of your Salesforce data, set up your org so that guest users are no longer automatically the owner of records they create in Salesforce Sites. When a guest user creates a record in a Salesforce Site, the record is assigned to a default active user, who becomes the owner.

Where: This change applies to orgs with active Salesforce Sites in Essentials, Unlimited, Performance, and Developer editions.

Why: To follow Salesforce security best practices, designate an internal org user to be the owner of records created by guest users. While we strongly encourage you to assign a default owner, changing record ownership can affect your guest users’ ability to access records. Test all changes in a sandbox environment to see the effects on data sharing and visibility before you change your implementation in production.

How: From Setup, in the Quick Find box, enter Sites, and then select Sites. Select Reassign new records created by guest users to the default owner. Click Save.

If no default owner is chosen in the org, Salesforce automatically assigns the Salesforce Site owner as the owner of records created by guest users.

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

Store data related to your customers’ general consent preferences and the communications that they subscribe to. You can also associate multiple email addresses or phone numbers to individuals or person accounts, and manage their preferred time and consent to be contacted.

• Keep Track of Customer Consent Preferences
  Use the Party Consent object to store information related to your customers’ general consent preferences, such as whether they agree to have their data collected or shared. Indicate when and how you captured consent as well. You can associate multiple party consent records to an individual or person account record.
• Manage Your Customers’ Communication Subscriptions
  Keep track of data related to the communications your customers subscribe to, such as newsletters or appointment reminders. Store when and how your customers consented to be contacted and information on their preferred timing. You can also record the channels, such as email addresses and phone numbers, through which you can reach them.
• Store Multiple Contact Points and Customer Consent Information
  To help you better reach your customers, you can now specify multiple email addresses or phone numbers for an individual or person account. Previously, our data model only allowed for one phone number or email to be associated to a single customer. Now, using contact point email and contact point phone, you can also add details such as the best time to reach out to a contact or how they prefer to be contacted. Plus, you can reference these records from a contact point consent record to store your customer’s consent to being contacted this way.

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

Use Real-Time Event Monitoring platform events to detect common threats to your org (Beta). We improved the performance of the Event Monitoring Analytics app. The legacy transaction security policy framework will be retired in Summer ’20. Shield Platform Encryption now supports Platform Events in addition to Change Data Capture Events.

• Shield Platform Encryption: Encryption for Platform Events
  Shield Platform Encryption now supports Platform Events, adding an extra layer of protection for events that involve sensitive information. Remove the Manage Encryption Keys permission from system admin profile with a critical update.
• Event Monitoring: New Threat Detection Real-Time Events (Beta), Legacy Transaction Security Retiring, Event Monitoring Analytics App Improvements
  Detect threats to your org, such as report execution anomalies and credential stuffing, with three new Real-Time Event Monitoring events. We are retiring the legacy transaction security framework in the Summer ’20 release, so migrate your existing policies to the enhanced framework. Also, we improved the performance of the Event Monitoring Analytics app.

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

Test your Salesforce Sites and Communities in a sandbox using custom domains (Pilot). Customers with a My Domain can accelerate domain requests with Salesforce Edge. Remove instance names from My Domain URLs through critical updates or sandbox refreshes.

• Use Custom Domains for Sandboxes (Pilot)
  Develop and test your Salesforce Sites and communities within your sandboxes using custom domains. This feature allows you to test new custom domains in a sandbox before deploying them to Salesforce production.
• Route My Domains Through Salesforce Edge (Previously Released Critical Update)
  We’re accelerating domain requests for My Domains. With this update, you keep the same My Domain address, but requests go through Salesforce Edge. Salesforce Edge uses machine-learning technology to improve connectivity and performance. You can acknowledge this update to let Salesforce move your org’s My Domain to the new service before the July 2020 auto-activation date. This critical update was first made available in Winter ’20.
• Stabilize the Hostname for My Domain URLs in Sandboxes (Previously Released Critical Update)
  We’re removing instance names from MyDomain URLs for sandboxes. The instance name identifies where your Salesforce sandbox org is hosted. Removing the instance name makes the URL cleaner and easier for users to remember. For example, MyDomain–SandboxName.my.salesforce.com replaces MyDomain–SandboxName.cs5.my.salesforce.com. This critical update was first made available in Summer ’18.
• Stabilize URLs for Visualforce, Experience Builder, Site.com Studio, and Content Files (Previously Released Critical Update)
  We’re removing the instance names from Visualforce, Experience Builder, Site.com Studio, and content file URLs. An instance name identifies where your Salesforce org is hosted. Instanceless domains are cleaner and easier for users to remember. This critical update applies to orgs that have a deployed My Domain. After this update, a URL that includes the instance name, such as a bookmark, automatically redirects to the new hostname. This critical update was first made available in Spring ’18.
• Get Stabilized My Domain URLs in New and Refreshed Sandboxes
  As part of our effort to stabilize domains by removing instance names from their URLs, the My Domain URL format is changing for sandboxes. When you create or refresh a sandbox with a deployed My Domain, the sandbox name within the hostname becomes lowercase. Also, the “Stabilize the Hostname for My Domain URLs in Sandboxes” and “Remove Instance Names From URLs for Visualforce, Experience Builder, Site.com Studio, and Content Files” critical updates are automatically activated. These critical updates remove the instance name from the sandbox URLs.

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