Archives de catégorie : Summer’26

SUMMER’26 – DEFAULT TRANSACTION POLICY ON REPORT EXPORTS

Publié le par
Répondre

Following my previous article dealing with MFA enforcements (and stricter « Phishing-Resistant » MFA for System Admin users, or users with powerful administrative permissions), Salesforce also recently communicated on changes on Transaction Security Policies, that will be released after Salesforce’s Summer’26 release.

As you know, large report exports may be easily exploited for data theft or leaks (from out of the company, or by someone stealing data before leaving). With Salesforce’s Event Monitoring (Shield) and some robust Transaction Security Policies, Salesforce platform provides a proactive layer of defense to identify and block unauthorized data leak.

So what is the change for Summer’26 ?

STRICTER TSP MANAGEMENT REQUIREMENTS

Managing your critical Transaction Security Policies (TSP) will soon require a « double check » approach. Indeed, to be able to create, edit, or activate / deactivate TSP records, users would now need to be assigned both the following permissions :

  • The « traditional » Customize Application permission, used for instance customization.
  • With the upcoming Modify Transaction Security Policy permission.

Salesforce also mentions that if a user is trying to perform these actions through the Setup User Interface, Salesforce will prompt this user for an extra identity verification step, in order to ensure the changes are intentional and well realized by the logged-in user.

🔜▶️ As for now, please check your System Administrators, and all users granted with the Customize Application permission, and start identifying who should be assigned the new Modify Transaction Security Policy permission.

A NEW DEFAUT POLICY FOR LARGE REPORT EXPORTS

To prevent data leaks, due to badly configured instances, or Salesforce products not yet fully mastered by clients, Salesforce will also roll out a default Transaction Security Policy, dealing especially with report export use case.

  • This policy will concern any UI-based report export that exceeds 10 000 records.
  • In this case, Salesforce will automatically require an extra identity verification step before the export can continue.

🔜▶️ That will allow for all new orgs / updated orgs to have at least one default security policy. However, you will need to review, tweak or not, and activate this default Transaction Security Policy, so that it will match your data volume / sensitivity and criticality of your data.

To read more on the subject

SUMMER’26 – MFA ENFORCEMENT AFTER SUMMER’26 RELEASE

Publié le par
Répondre

Some important security changes will take place in Salesforce instances after Summer’26 version upgrade. You will find below a focus on MFA (Multi-Factor Authentication) topic.

This change will take place in Salesforce instances :

  • Sandbox : Starting as of June 22nd, 2026
  • Production : Starting as of July 20th, 2026

MFA Enforcement for all users

First, MFA will now be enforced for all users. This security change will affect all users logging into Salesforce (via direct UI and SSO logins) both in Production and sandboxes.

  • Standard users, already using MFA, will keep on logging with the same MFA experience, and confirming their login in the same Authenticator mobile application that they already use.
  • Users logging through SSO, holding a MFA capacity, will keep the same login experience.

However, as MFA will be definitively enforced, System Admin will not be allowed anymore to deactivate MFA, from setup, for certain users. This option will be grayed out in setup.

Resistant MFA Activation for all users

Then, the big news come from a second type of MFA, that will be enforced, for powerful users, in a stricter way after Summer’26 Release.

This more secure « Phishing-resistant MFA » method will concern every « System Admin »-like users, i.e. System Administrator themselves, and users granted with one of the following permissions : Modify All Data, View All Data, Customize Application, or Author Apex.

These powerful users will need to use one of the secure methods to confirm their login :

  • Security Keys (WebAuthn / FIDO2), like Yubico’s YubiKey, or Google’s Titan Security Key
  • Built-in Authenticators, like Touch ID, FaceID, or Windows Hello.

To correctly handle this change, and avoid service interruption for your users, please follow some practical rules :

  • Monitor all users, through setup or login history information, and identify those who do not login through MFA.
  • Inform and encourage all concerned users to properly register their MFA configuration, before the security changes are deployed.
  • Anticipate the Security Key test / purchase process before Summer vacation. Test and support your Admin-like users with this specific change.
  • In case of SSO / MFA configurations / login flow changes, please test all your configurations first in sandbox, before doing it in Production.

To read more on the subject