Salesforce changed the locks and most orgs aren't ready

Between April and July 2026, Salesforce is pushing through the most significant wave of security changes the platform has seen in years. Mandatory multi-factor authentication for all users. Phishing-resistant MFA for administrators. Step-up authentication every time someone exports a report. Automatic account freezes for connections it classifies as high-risk. Email domain verification. All compressed into roughly twelve weeks.

Some of it is already live and quietly breaking things. The rest lands in production on July 1.

The community reaction has not been subtle. Marc Baizman, a longtime nonprofit Salesforce consultant, called the rollout an absolute mess on LinkedIn. Francis Pindar, a Salesforce MVP with a twenty-year-old developer org he uses for training work, got locked out of it for reasons Salesforce still hasn't clearly explained. Consultants are walking back guidance to clients because requirements changed mid-rollout.

None of that means the security changes are wrong. It means most organizations weren't ready, and some are finding that out right now in the worst way.

What's actually changing and when

Salesforce published the full picture in their Security-Related Product Updates article, but the details are scattered across multiple Help pages. Here's the consolidated view.

Email domain verification (DKIM) has been in effect since April 13, 2026. Any domain your org sends email from must be verified through DKIM or Salesforce's authorized email domain process. Unverified domains don't trigger a bounce or an error. The emails just stop arriving. If your org has been sending from an unverified domain since April, those messages have been silently disappearing.

High-risk IP and anonymizing proxy blocking went live April 24, 2026. Salesforce now automatically freezes accounts that connect from VPNs, proxies, and addresses it classifies as high-risk. A frozen user needs an admin to restore access. Salesforce hasn't published clear criteria for what qualifies as high-risk, and there's currently no documented mechanism for orgs to designate trusted IPs as exempt. Practitioners have reported account freezes from regular ISP connections, mobile carrier networks, and cloud-hosted infrastructure with no clear explanation.

Step-up MFA authentication for report exports begins enforcement June 17 in sandboxes and July 1 in production. Even if a user is already logged in with MFA, exporting a report triggers a second authentication challenge. By default, that challenge repeats every 120 minutes. Admins can configure the window but cannot turn it off.

MFA required for all employee users rolls out in sandboxes June 22 and production starting July 20. The org-wide setting becomes locked. The "Waive Multi-Factor Authentication for Exempt Users" permission stops working. Any user who hasn't enrolled in an MFA method gets blocked at login.

Phishing-resistant MFA for privileged users is the most consequential change and the one with the hardest enforcement date. Starting June 22 in sandboxes and July 1 in production, anyone with the System Administrator profile, or the permissions Modify All Data, View All Data, Customize Application, or Author Apex, must log in with a phishing-resistant method. Standard authenticator apps like Google Authenticator and Microsoft Authenticator don't qualify for privileged users. The qualifying methods are built-in authenticators (Touch ID, Face ID, Windows Hello) and physical security keys like YubiKey or Google Titan. Users without a compliant method registered get blocked at login. Salesforce locks the setting so admins cannot disable it.

Why this is different from a typical platform update

Salesforce pushes changes with every release. This wave is different in two important ways.

First, the timeline. Twelve weeks for changes of this scope, some of which are already enforced, is short. Organizations running complex Salesforce environments, with multiple integration points, custom connected apps, external identity providers, or large teams with varied permission structures, don't adapt to authentication changes in weeks. They adapt in quarters.

Second, the nature of the failure mode. Most Salesforce updates change functionality. These changes block access. A user who hasn't enrolled in the right MFA method doesn't get a degraded experience. They can't log in. A domain that hasn't been verified doesn't get lower deliverability. The emails disappear. These are hard stops, not soft impacts, and they're happening across production orgs right now.

Salesforce Ben, which has covered the rollout closely, noted that this is likely the beginning of an ongoing security tightening cycle, not a one-time event. The threat landscape targeting Salesforce orgs is real and documented. Attackers have successfully used real-time phishing to capture both passwords and MFA codes simultaneously, logging into orgs before the codes expire. Phishing-resistant methods close that attack path at a structural level. More changes are probably coming.

The industries where this hits hardest

Most Salesforce orgs will feel these changes. Some will feel them much more than others.

Healthcare. Health Cloud orgs tend to have elevated permissions distributed across clinical and administrative users, complex integration patterns connecting to EHRs and payer systems, and HIPAA accountability requirements that the new identity-binding controls are actually designed to strengthen. The alignment is real: audit trail requirements under HIPAA and the one-human-per-login goal of Salesforce's MFA push are pointing at the same thing. The challenge is that getting there requires meaningful configuration work, and orgs running integrations through connected apps need to audit those as well. The step-up authentication on report exports matters here directly: clinical and compliance reporting workflows that pull patient records will require every user to be enrolled and prepared, not just notified.

Financial services. Financial Services Cloud orgs will feel the report export authentication changes in analyst and compliance workflows immediately. The high-risk IP blocking has already created friction for teams that use consumer VPN products as standard practice when working remotely. More critically, financial services orgs often have external consultants or auditors with elevated Salesforce access. Those users need to be inventoried, enrolled in phishing-resistant methods, and ready before the July 1 production enforcement date. An auditor who can't log in on the morning of an audit is a different kind of problem than a configuration issue.

Nonprofits. This is where the rollout has caused the most visible pain in the community, and the reason goes beyond the timeline. The nonprofit Salesforce consulting model has historically relied on shared admin credentials across consulting teams, with economic constraints that made per-consultant licensing difficult. The phishing-resistant MFA requirement is specifically incompatible with that model, because the security goal it's designed to achieve, binding every login to a specific human, is exactly what shared credentials prevent. BrightHelm Partners put it directly: "The shared-credential model isn't just technically vulnerable to the new rules. It's structurally incompatible with the direction the entire identity ecosystem is moving." For nonprofits managing donor data, grant compliance, or program delivery in Salesforce, the path forward requires rethinking how consultant access is structured, not just how it's authenticated.

Orgs running Agentforce. The tightening of connected app controls and API authentication is running on a parallel track to the UI login changes. Agentforce integrations rely on specific external client app configurations and authentication flows that run through the same identity infrastructure these changes are touching. Orgs that have deployed Agentforce agents, or are mid-implementation, need to audit their connected apps, confirm integration users are correctly scoped with minimum-necessary permissions, and verify that the security requirement changes haven't inadvertently affected agent authentication. API-only logins are currently exempt from the MFA enforcement, but the broader tightening of connected app controls means this is not the time to assume existing integrations are unaffected.

What "do nothing" looks like

Some of these deadlines have already passed. For the rest, the failure modes are concrete.

Privileged users who haven't registered a phishing-resistant MFA method by July 1 will be blocked at the login screen in production. This is not a Health Check flag. It's an account block. If your org's only system administrator hits the July 1 enforcement wall without a qualifying method registered, restoring access requires a phone call to Salesforce Support.

Organizations with Salesforce Shield or Event Monitoring that haven't configured a Transaction Security Policy for report exports will have Salesforce auto-deploy a default policy in July, with a 10,000-record threshold. That threshold may or may not reflect how your teams actually work. If it doesn't, the disruption to reporting workflows could be significant for teams that rely on large data exports.

Users relying on the "Waive Multi-Factor Authentication for Exempt Users" permission to bypass MFA will lose that exemption when enforcement hits. If those users are part of integration flows or automated processes that connect through the UI, those processes will break.

And the DKIM enforcement is already live. If your org has been sending email from an unverified domain since April 13, those messages have been failing silently. There's no error log in Salesforce telling you this. You'd only know from the receiving end.

What to do before July 1

Audit your privileged users first. Run a permissions audit to identify every user with System Administrator, Modify All Data, View All Data, Customize Application, or Author Apex. Every one of them needs a phishing-resistant MFA method registered before July 1. If you're going the hardware security key route, budget roughly $25 to $50 per key from vendors like Yubico and order two per user so a lost key doesn't become a lockout.

Check your DKIM configuration. Go to Setup, search for DKIM Keys, and review what's there. If your org sends from a custom domain and it isn't verified, those emails have been failing since April. Your IT team will need access to your domain's DNS settings to complete the verification.

Check your MFA enrollment status. Salesforce offers a Multi-Factor Authentication Dashboard from Salesforce Labs that shows which users are and aren't enrolled. Run it now. Don't wait until enforcement to discover the gaps.

Set up your Transaction Security Policies before Salesforce sets them for you. If you have Shield or Event Monitoring, create a TSP on the ReportEvent with thresholds that reflect how your teams actually use reporting. The default Salesforce will deploy in July doesn't know your workflows.

Audit your connected apps and integration users. Review what's connected, what scopes those apps have, and whether the permission footprint matches what's actually needed. Integration users that were set up years ago with broad permissions for convenience are worth revisiting now. The principle of minimum necessary access matters more as the surrounding controls tighten.

The changes Salesforce is making are the right ones. Phishing-resistant MFA closes a real, actively exploited attack path. Identity binding means "who accessed this record" has an actual answer. The security posture on the other side of this rollout is meaningfully better than what most orgs had in January.

Getting there without disruption is the work. And for organizations without deep Salesforce expertise in-house, right now is the moment to get help before enforcement turns a configuration problem into an operational one.

At Tristella Advisors, our Salesforce practice is built around helping organizations get through exactly this kind of transition: from security and compliance readiness to Agentforce implementation to the broader question of whether your org is set up to scale safely. If you're unsure where you stand on any of these requirements, start with a conversation.

Learn more about our Salesforce and Agentforce services at tristellaadvisors.com/services/salesforce-agentforce.

Sources: