Salesforce is not asking anymore. Starting July 1 in production, users who open a report will need to re-verify their identity even if they just logged in. By July 20, every internal user in every production org will need multi-factor authentication — not as a recommendation, but as a locked system setting that admins cannot disable. Five enforcement changes, three deadline dates, and zero tolerance for orgs that are not ready.
| Date | What changes | Who it affects |
|---|---|---|
| July 1 | Step-up MFA on every report Any user who runs or views a report is prompted to re-verify identity, even after a recent login. All orgs, not Shield-only. | All users who access reports. Users not enrolled in MFA are blocked at this step-up prompt — not just at login. |
| July 1 | Phishing-resistant MFA for privileged users System Admins and users with Modify All Data, View All Data, or Manage Users must switch to hardware keys or passkeys. Authenticator apps no longer qualify. | System Administrator profile users, plus anyone with Modify All Data, View All Data, or Manage Users via permission set — not just via profile. |
| July 13 | Transaction Security Policies auto-created for Shield orgs Shield orgs without a custom export TSP get one auto-created for exports over 10,000 records. | Shield-licensed orgs only. Orgs with existing export TSPs are unaffected. Auto-created policies may need review before this date. |
| July 20 | Full MFA locked for all internal users Salesforce locks the MFA setting. Admins cannot disable it. Any user not enrolled is blocked from login entirely. | All internal users in all production orgs. No exceptions, no grace period. Unenrolled users cannot log in after this date. |
| July 20 | MFA Opt Out permission stops working The self-service exemption permission for automation and integration users ceases to function. | Integration users and automation service accounts currently using the opt-out permission. Must file a Salesforce Support case before July 20 for a supported exemption. |
Change 1: Step-up MFA on every report — July 1
From July 1, any user who runs or views a report in Salesforce is prompted to verify their identity again, even if they authenticated at login minutes earlier. This applies to all reports, not just exports, and not just Shield-licensed orgs. It is platform-wide.
The practical impact on end users is a second prompt in their session flow when they access report functionality. Orgs with high report usage — sales dashboards, weekly pipeline reviews, regular operational reporting — should communicate this change to their users in advance. A verification prompt that appears without warning reads as a potential security incident to users who were not expecting it.
The enrollment implication is more significant: any user who accesses reports and is not enrolled in an MFA method will be blocked at this step-up verification. Enrollment must be complete before July 1 for report-heavy users specifically, not just before July 20 for the general rollout.
Change 2: Phishing-resistant MFA for privileged users — July 1
System Administrators and users with Modify All Data, View All Data, or Manage Users permissions must switch to a phishing-resistant authentication method by July 1. An authenticator app — the method most admins currently use — no longer qualifies for these privilege levels.
Phishing-resistant methods at GA include hardware security keys compliant with FIDO2 (YubiKey and similar devices) and passkeys stored on a trusted device. Biometric authenticators on modern devices qualify when configured as passkeys.
The action required for admins right now is an audit of which users hold elevated permissions in production. The Admin profile is obvious. The less obvious group is permission sets that grant Modify All Data, View All Data, or Manage Users without giving the System Administrator profile — these users are subject to the same requirement and are frequently missed in pre-enforcement preparation.
Change 3: Transaction Security Policies for report exports — July 13
Shield-licensed orgs that do not have a custom Transaction Security Policy governing report exports will have one automatically created by Salesforce on July 13. The auto-created TSP applies to exports over 10,000 records and adds a verification step or block depending on the default configuration.
Orgs with Shield that have already configured export TSPs are unaffected. Orgs with Shield that have not configured them should review the auto-created policy before July 13 and determine whether the default behavior is appropriate for their specific export patterns. Auto-created policies are a starting point, not a final configuration.
Change 4: Full MFA for all internal users — July 20
On July 20, Salesforce locks the Multi-Factor Authentication setting in all production orgs. The setting cannot be disabled by an admin after this date. Any internal user who is not enrolled in an MFA method is blocked from logging in until enrollment is completed.
What gets blocked if users are not enrolled on July 20: complete login block for any internal user without an enrolled MFA method. They cannot log in at all — not to read email, not to view their opportunities, not to run a report. The fix is to complete enrollment, which takes time that may not exist in the middle of a blocked login incident.
The recommended approach is to complete enrollment for all internal users before July 13 — one week before the final deadline — to allow time to address any enrollment issues before the lock takes effect.
Change 5: MFA exemption permission stops working — July 20
The MFA Opt Out of Multi-Factor Authentication permission, which some orgs have used to exempt automation users and integration service accounts from MFA requirements, stops functioning on July 20. Integration users and automation service accounts that use this permission for their login flow must be handled through an alternative path before the deadline.
The supported path for integration and automation users who require a login flow incompatible with MFA is a Salesforce Support case filed before July 20, documenting the specific use case and requesting an exemption through the supported process. The self-service permission-based exemption will not be available after enforcement.
The readiness checklist before July 1
July 20 is a hard cutoff, not a recommendation. Orgs that arrive at that date with unenrolled users will have blocked logins — not a warning, not a grace period, blocked. The preparation window is now.
