Salesforce's 2026 Security Changes: What's Actually Happening, What It Means, and Why It's Hitting Consulting Partners Hardest
Between April and July 2026, Salesforce is pushing through the most significant wave of security changes the platform has seen in years. Mandatory MFA for all employee users. Phishing-resistant MFA for admins. Step-up authentication on reports. Auto-containment of "high-risk" connections. Email domain verification. ISV connected app tightening. All compressed into roughly twelve weeks.
The community reaction has been blunt. Marc Baizman, a longtime nonprofit-focused consultant, called the rollout "an absolute sh*tshow" on LinkedIn. David Rabinak, an independent consultant in Europe, described losing client trust because requirements changed mid-rollout — IP range enforcement was on the list, then off, leaving him to walk back guidance he'd just delivered. Francis Pindar, a Salesforce MVP with a twenty-year-old developer org he uses for training and reference work, got locked out of it for reasons Salesforce hasn't been able to clearly explain.
These aren't fringe complaints. They're coming from the most experienced practitioners in the ecosystem, and the criticism is about communication, timing, and operational impact — not about whether the security goals are right.
We think that distinction is important, and it's the one we want to lead with. The destination Salesforce is pointing at is the right destination. The way they're getting there has been managed poorly. Both things can be true at once, and pretending only one of them is true — in either direction — produces an incomplete analysis.
In this piece we want to do six things.
First, give you a clean reference roundup of what's actually changing and when, so you can stop hunting through five different help articles.
Second, explain what passkeys actually are and why the distinctions inside that category matter more than most coverage is acknowledging.
Third, lay out our analytical thesis: phishing resistance is the headline, but identity binding is the real story — and that's why this hits consulting partners harder than anyone else.
Fourth, pick at the distinction between passkey types and why we think the popular workaround is only a stay of execution.
Fifth, name a risk that almost no one in the partner community is talking about: the displacement risk, where friction in one place pushes work toward less governed paths.
Sixth, offer some suggestions for paths forward, what we think is the best solution, and what we actually expect.
You'll get our honest read throughout. Where the official guidance is clear, we'll cite it. Where it's silent or unclear, we'll say so. Where we think the community is wrong, we'll say that too.
Part One: What's Actually Changing
Here's the roundup. Dates and scope reflect Salesforce's official Help articles as of early May 2026. The roadmap document Salesforce maintains has been updated more than once during this rollout, so treat any specific date as the current answer rather than a permanent one.
MFA Required for All Employee Users
Salesforce is enforcing multi-factor authentication for every employee login — direct UI and Single Sign-On — across both production and sandbox orgs. Sandboxes get this starting June 22, 2026, staggered over about seven days. Production orgs get it starting July 20, 2026, staggered over about thirty days.
The org-wide setting "Require multi-factor authentication for all direct UI logins" becomes active and admins lose the ability to disable it. The "Waive Multi-Factor Authentication for Exempt Users" permission stops automatically exempting users — those users will be prompted to enroll like everyone else. To restore exemptions for legitimate use cases like automated testing tools, you have to file a case with Salesforce Support.
API-only logins are exempt. We'll come back to that in Part Four because it matters more than it looks.
For SSO logins, Salesforce relies on your identity provider passing standard ACR/AMR signals (RFC 8176) confirming MFA was performed. If your IdP doesn't pass those signals, Salesforce will challenge the user itself.
Phishing-Resistant MFA for Admins and Privileged Users
This is the big one for consulting partners, and it's what most of the rest of this post is about.
Anyone holding the System Administrator profile, or any of the permissions Modify All Data, View All Data, Customize Application, or Author Apex, will be required to register a “phishing-resistant” MFA method. Sandboxes start June 22, 2026. Production starts July 1, 2026.
Phishing-resistant means built-in authenticators (Touch ID, Face ID, Windows Hello) or physical security keys (YubiKey, Google Titan, or other WebAuthn/U2F devices). Standard authenticator apps that produce six-digit TOTP (Time-based One-Time Password) codes — Google Authenticator, Microsoft Authenticator, Authy — do not satisfy this requirement for privileged users.
The expected user experience after enforcement will be privileged users being blocked from logging in until they register a compliant method, then prompted on every subsequent login.
Step-Up Authentication for Reports
Even after a user has logged in with MFA, viewing or exporting a report will trigger an additional authentication challenge if a configurable amount of time has passed since the last step-up. The default window is 120 minutes; admins can adjust it. Sandboxes get the feature May 27, 2026, with enforcement starting June 3. Production gets the feature May 27, with enforcement starting June 10.
There's also a machine-learning layer: if Salesforce detects anomalous report activity — unusually large exports, unusual times, unusual patterns — it triggers step-up authentication regardless of when the user last verified.
If a user can't complete the MFA challenge (because they haven't enrolled in a method), the system falls back to a one-time password by email or SMS. If all options are exhausted, the operation is blocked.
Auto-Containment for "High-Risk" Connections
This one started April 24, 2026, and has caused the most operational pain so far. Salesforce now monitors connections from anonymizing VPNs, proxies, and IP addresses it considers high-risk, and automatically freezes user accounts that connect from them. Frozen users have their authentication tokens revoked. An admin has to unfreeze them.
The legitimate criticism here is real and worth naming directly, specifically:
Salesforce has not published clear criteria for what counts as "high-risk."
There is no allow-list mechanism for orgs to designate trusted IPs as exempt.
Admins are receiving notifications without enough detail to investigate efficiently.
Practitioners have reported being locked out from regular ISP connections, mobile carrier networks, and AWS-hosted infrastructure with no obvious reason. We’ve seen this already at BrightHelm, as our team uses VPNs when travelling as a standard security practice.
If a user is locked out and they're the only admin, Salesforce Support will reactivate the account by phone. That's a legitimate fallback, but it's also a significant operational disruption that better policy design could have avoided.
Email Domain Verification (DKIM)
Email-sending domains used by your Salesforce org must be verified through DKIM or Salesforce's authorized email domain process. Phase 1 enforcement (new and existing email-sending domains) hit sandboxes March 24, 2026, and production starting April 13, 2026. Phase 2 (allowlisted domains) started rolling out April 14, 2026 in sandboxes; production date TBD.
If you haven't set up DKIM, you should do it regardless. Email deliverability has been getting harder for years, and unauthenticated domains are increasingly being filtered or rejected by major mail providers.
Part Two: A Passkey Primer
Most of the coverage we've seen treats "phishing-resistant MFA" as a single bucket. It isn't. The distinctions inside the bucket matter — for what's allowed today, for what may be allowed tomorrow, and for the business model questions consulting firms are wrestling with right now.
What a Passkey Actually Is
A passkey is a cryptographic credential. When you register a passkey with a website, your device generates a key pair: a private key that stays on your device (or syncs only through an end-to-end encrypted vault), and a public key that the website stores. When you log in, the website sends a challenge, your device signs it with the private key, and the website verifies the signature.
The phrase that matters: the private key never leaves the device or the encrypted vault. Compare that to a password (you type a secret) or a TOTP code (you type a six-digit number generated from a shared secret). Both of those involve transmitting something the user types, which means a phishing site can capture it.
A passkey can't be captured by a phishing site for two structural reasons. First, there's nothing to type — the signing happens on-device. Second, passkeys are “origin-bound.” This means your browser checks that the domain requesting the signature matches the domain the credential was registered to. Even if you somehow tried to use your real-salesforce.com passkey on evil-salesforce.com, it wouldn't fire.
This is what makes passkeys cryptographically phishing-resistant. The protection isn't a policy; it's structural.
Why Passkeys Feel Similar to TOTP From the User's Seat
If you've used 1Password, LastPass, or Apple's iCloud Keychain to create passkeys recently, you've probably noticed they don't feel that different from typing a six-digit code. A prompt appears, you confirm (sometimes with a fingerprint or Face ID), you're in. About five seconds, give or take.
That's true. The user experience is similar. The security model is wildly different. This is one of the rare cases where you get better security and slightly less friction at the same time.
The Distinction That Matters: Synced vs. Device-Bound
There are two flavors of passkey, and the difference is critical.
Device-bound passkeys live on a single device — a YubiKey, the secure enclave of a specific MacBook, the TPM of a Windows machine. The private key cannot be copied, exported, or synced. If you lose the device, you lose the credential. Built-in authenticators like Touch ID and Windows Hello, when used directly without a password manager, create device-bound passkeys.
Synced passkeys (sometimes called "multi-device" or "cloud-synced") are generated and stored in a password manager — 1Password, iCloud Keychain, Google Password Manager, Bitwarden — and synchronized across all devices in your vault through end-to-end encryption. Anyone with access to that vault can use the passkey on their device.
Both types are cryptographically phishing-resistant. Both prevent the credential from being captured by a fake login page. But they differ on a property that turns out to matter enormously for what Salesforce is trying to do: identity binding.
A device-bound passkey is bound to one device, and in practice to one human (the human who controls that device). A synced passkey shared across a vault is bound to whoever has the vault open.
We'll come back to this. It's the technical fork that determines whether a lot of consulting firms can keep operating the way they currently do.
What WebAuthn Actually Tells the Server
When a passkey is registered, the WebAuthn protocol exchanges metadata that includes two relevant flags: Backup Eligibility (BE) — "is this credential capable of being synced to other devices?" — and Backup State (BS) — "has it actually been backed up or synced?"
A device-bound passkey on a YubiKey reports BE=0, BS=0. A 1Password-synced passkey reports BE=1, BS=1.
The relying party (Salesforce) sees these flags on every login. They aren't hidden. They aren't optional. The protocol is specifically designed so that services that care about device-bound versus synced credentials can tell the difference and act on it.
That last sentence is the one to hold onto. We'll return to it.
Part Three: Phishing Resistance Is the Headline. Identity Binding Is the Substance.
Here is our central thesis, and the part of this post that we think is most worth the read.
The reason Salesforce is pushing phishing-resistant MFA isn't only — or even primarily — to stop external phishers. It's to make every login attributable to a specific human. The headline is phishing resistance. The substance is identity binding.
Why That Distinction Matters
When LoginHistory shows that user consultant_admin@nonprofit.org logged in at 2:14 AM and exported 50,000 records, the question Salesforce wants you to be able to answer is "which human did that?" Today, in many consulting engagements, the honest answer is "we're not sure — could have been any of three or four people who share this login, or could have been someone who phished one of them last month."
That ambiguity is not a minor record-keeping issue. It is, increasingly, the entire reason data exfiltration through compromised consulting credentials has become a meaningful threat surface. When the credential is bound to a vault rather than a human, you can't reliably:
Audit access. "Who accessed this PHI?" doesn't have a real answer.
Contain a breach. Freezing the right user only contains the breach if "the right user" maps to one human. When it maps to a vault shared by five, you're either freezing too much or too little.
Comply with regulations. HIPAA, GDPR, PSD2, and most modern data-protection frameworks assume identifiable accountability. "We don't know which human accessed this record" is not an answer that holds up in audit.
Manage offboarding. When a consultant leaves a firm, removing them from a shared vault doesn't necessarily revoke their access — the credential persists, the consultant just shouldn't use it anymore. The honor system is doing the security work.
So Salesforce's real goal — the deep version of what they're announcing — is one human, one credential, one user record. Phishing resistance is the property they're advertising. Identity binding is the property they're actually trying to produce.
Why This Hits Consulting Partners Harder Than Anyone Else
Internal IT teams largely already work this way. Each employee has a license. Each license maps to one human. SSO ties Salesforce identity back to corporate identity, which is tied to HR records. Identity binding has been the implicit operating model for most enterprise customers for years. The new MFA rules tighten the security on credentials that are already individually owned.
Consulting partners — especially those serving small and mid-sized clients, and especially those serving nonprofits — operate differently. The economic reality of the engagements often makes per-consultant licenses unaffordable for clients. That's not a bad practice invented by careless firms. It's the model that has made nonprofit Salesforce consulting economically viable for years.
Phishing-resistant MFA, properly implemented, breaks that model. Not because the credential is harder to share, but because identity binding is precisely what shared credentials prevent.
This is the substance of what's hitting partners hardest. The friction is real. The license cost is real. But the deeper fact is that the direction — toward one-human-per-credential — is structurally incompatible with the shared-login operating model that has been quietly underwriting a meaningful slice of the partner ecosystem.
Why "How Do We Keep Sharing Logins?" Is the Wrong Question
A lot of the partner community discussion right now is pointed at preserving the existing model. Will 1Password's synced passkeys keep working? Can we structure shared vaults to keep multi-consultant access alive? Where are the workarounds?
We get it. Honestly, we've been asking ourselves the same questions. When the enforcement clock is measured in weeks and clients are looking at us for answers, the first job is triage: figure out what works right now, what breaks right now, and how to keep the wheels on through June and July. That's not the wrong instinct. That's professional consulting under pressure, and the partners doing that work are the ones holding the ecosystem together through a rough rollout.
But triage is the first job, not the only job. And if the conversation stops at "how do we preserve what we had," we're solving for the wrong horizon.
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. Salesforce is one of many vendors heading this way. Microsoft, Google, Okta, Apple — every major identity platform is converging on attestation, device binding, and one-person-per-credential as table stakes. If we build our strategy around finding workarounds that let shared credentials persist, we're paddling against a tide that's getting stronger every quarter.
The question isn't "how do we keep sharing logins." The question is "how do we restructure consultant access so it's economically viable and each consultant has their own identity?" Those are different problems with different answers, and only the second one is durable.
We'll lay out concrete options in Part Six. But the framing matters first.
Part Four: The Synced Passkey Question
A lot of us in the partner community have been hoping that 1Password-style synced passkeys will preserve the shared-vault model in upgraded form. The logic is appealing: a passkey shared through a vault is cryptographically phishing-resistant, every consultant accessing the vault uses a phishing-resistant credential, the security posture goes up rather than down, and the existing operating model survives.
We've been researching this carefully, and we think the evidence is not where the optimistic version of this assumption needs it to be.
What Salesforce's Documentation Says
The Salesforce Help articles describing phishing-resistant MFA enforcement reference "Security Keys" and "Built-in Authenticators." Salesforce's January 2026 security blog defines phishing-resistant methods using the explicit phrase "cryptographic, device-bound, and origin-bound authentication." The word device-bound is part of how Salesforce defines the category.
That isn't a flat prohibition on synced passkeys, and the Help articles don't currently distinguish between synced and device-bound at the technical implementation level. But it's the definitional language Salesforce has chosen, and it matters for where this is heading.
What Practitioners Are Reporting
A user posting to the 1Password community forum reported that their 1Password-synced passkey, initially working as a Salalesforce login method, started failing with "undefined error." When they contacted 1Password support, the response was that Salesforce had declined to investigate because Salesforce only officially supports built-in authenticators (Touch ID, Windows Hello) and physical security keys (YubiKey-class hardware). The same user confirmed that a Windows-native, device-bound passkey worked fine on the same setup.
This is one report, on one forum, and it doesn't constitute Salesforce policy. But it's the failure mode the optimistic interpretation specifically predicts wouldn't happen — synced passkey works, then doesn't, and the vendor response is "we don't support that." It points the same direction as Salesforce's definitional language, and we have not been able to find contradicting evidence: no official Salesforce documentation explicitly endorses synced passkeys.
What the Broader Industry Is Doing
Microsoft's Entra ID documentation, updated April 2026, treats synced and device-bound passkeys as distinct categories with different governance properties. Microsoft's documentation explicitly states that synced passkeys do not support attestation, while device-bound passkeys do. The major hardware authenticator vendors — and at least some cybersecurity regulatory frameworks, including aspects of PSD2 — treat synced passkeys as cryptographically phishing-resistant but not high-assurance.
The technical infrastructure for relying parties to distinguish synced from device-bound is mature, standardized, and present in every major browser. The WebAuthn BE and BS flags we described in Part Two are exactly how a service like Salesforce would enforce the distinction if and when they choose to.
Our Read
Synced passkeys may work for Salesforce logins today. The technical implementation has not, to our knowledge, been hardened against them. But the combination of Salesforce's definitional language, the practitioner reports of inconsistent behavior, the broader industry direction, and the fact that the technical means for tighter enforcement are sitting one configuration change away — this is not a stable foundation to plan a business model on.
We think synced passkeys should be treated as a stay of execution, not a strategy. They may extend the runway. They will not save the model.
Part Five: The Displacement Risk No One Is Talking About
Here's the part of the conversation that almost no one in the partner community is having out loud, and it's the part we think matters most for how the next twelve to twenty-four months actually play out.
The Argument
Security policy that creates significant operational friction does not produce more security. It produces displaced behavior. Work continues, but it routes around the friction through whatever path has lower resistance — and the alternative path is almost always worse from a governance perspective. Less visible. Less governed. Broader-scoped. More likely to be owned by an individual practitioner than the firm.
This pattern is empirically well-established. It's why password complexity rules produced sticky notes under keyboards, why VPN restrictions produced personal hotspots, and why aggressive MFA produced people approving every push notification reflexively until attackers learned to exploit the muscle memory.
We think a version of this is going to happen in the Salesforce consulting ecosystem over the next twelve months, and we think it deserves to be named directly.
Where We Think the Pressure Is Going to Go
A consultant who finds it operationally painful to log into eight client orgs every day with eight different device-bound passkeys — and who is under pressure to bill hours efficiently — has an obvious alternative. Skip the UI login. Wire up an OAuth-authenticated CLI tool. Connect an MCP server with API access. Spin up an agent with broad-scope refresh tokens. The Salesforce ecosystem makes all of these straightforward, and the AI tooling layer has been growing faster than any governance framework has kept up with.
From the consultant's seat, this is faster. From the client's seat, this is potentially much worse. The work that previously happened through a shared-but-monitored UI login now happens through a Connected App with broad scopes, owned by an individual consultant, embedded in tooling the client may not even know exists. The threat surface didn't shrink. It moved… and arguably it expanded.
This is the part of the new regime where Salesforce's identity-binding goal has a giant exception. API-only logins are exempt from the MFA enforcement. That exemption exists for legitimate automation reasons — service accounts, integration users, batch jobs — and it's the right design. But it's also exactly the door that displaced behavior walks through. The friction we're imposing on humans is the same friction that pushes humans toward becoming "automation" in the eyes of the system.
Why We're Naming This
We're naming it for three reasons.
First, because pretending it isn't happening doesn't prevent it. The industry has watched this pattern play out in every previous wave of security tightening. The firms that handle this transition well will be the ones that anticipate where the pressure is going and govern both sides — human access and machine access — as one continuous problem.
Second, because the official narrative around the rollout is incomplete without it. Salesforce is rolling out tighter controls on UI logins while a major adjacent surface (Connected Apps, API tokens, agent tooling) tightens on a different timeline with different mechanisms. Customers and practitioners deserve to understand both.
Third, because consulting firms that pretend this risk doesn't exist while quietly engaging in the displaced behavior — wiring up broad-scope automation to dodge their own login friction — are doing something we want to call out clearly. The shared-password model was a tradeoff with known properties. Trading it for individual-consultant-owned automation with broad scopes and weak governance is not an upgrade. It's a downgrade dressed up as innovation.
The principle worth holding onto is this: identity binding isn't only about humans. It's about every identity that touches your client's data — human or machine. The work is to govern both, not to push the friction from one to the other.
Part Six: What This Means and What to Do
We've spent most of this post on analysis. Here's the practical part.
If you're an internal admin or IT leader at an organization that uses Salesforce, the list of things to do is well-covered in the official Salesforce Help articles and the various community write-ups. Enable phishing-resistant MFA methods in your sandbox now. Get your privileged users enrolled. Verify your email domains. Review your Connected Apps. Don't wait until June.
If you're a consulting partner, the work is different. Here's how we're thinking about it for our own firm and for the clients we serve.
Restructure Consultant Access, Don't Preserve It
The honest options, in roughly increasing order of restructuring effort:
Dedicated lead-consultant arrangements. One consultant per engagement is the licensed admin of record. Other consultants on the team operate through shadowing, screen-share, formal handoffs, or scoped lower-license access. Less efficient day-to-day, but defensible to auditors and clean for offboarding.
Integration users for legitimate automation. A meaningful slice of what currently runs through "shared admin" use is actually automation work that should already be running through an integration user with API-only access. Separating those flows often recovers more capacity than firms expect, and it puts the automation on the right governance footing.
Evolved pricing models. If client license costs are going up, partner pricing models may need to evolve too. Bundling licenses into engagement pricing is one option. Multi-year structured engagements that amortize the cost are another. The pros and cons are worth an honest conversation with each client.
Salesforce should “comp” Consultant Licenses. This is what we think is the best answer: Salesforce gives registered partners free licenses in the client orgs in exchange for reporting that project via the partner program. There’s clearly some administrative overhead to this, but Salesforce knows who the partners are, and partners obviously know the Org Id of their client’s orgs. The mechanism would likely be submitting a case to the Partner Portal (I know, I can hear the groans already), and Salesforce could provide a set of seats in a client org proportional to the partner’s team size, which they also know. In so doing, Salesforce supports stepped up security while also gaining better oversight of their partner community. Seems like a win-win to us, though we realize this is a stretch ask.
That said, the right answer is usually a combination. The wrong answer is a workaround that preserves the old model and pretends the underlying direction isn't changing.
Govern Machine Access With the Same Care as Human Access
Inventory your Connected Apps. Audit who owns them and what scopes they have. Separate firm-owned automation from individual-consultant-owned automation. Assign integration users with minimum-necessary permissions. Enable IP allow-lists where reasonable. Rotate refresh tokens. Log and monitor. Every piece of advice in the standard "best practices for Connected Apps" guidance becomes more important, not less, as the human-login surface tightens.
The Bright Spot Worth Holding Onto
This rollout has been hard, the timeline has been compressed, and the communication from Salesforce has not been what practitioners deserved. We want to be honest about all of that.
But the destination is meaningfully better than the place most consulting engagements were operating from a year ago. Phishing-resistant credentials are a real upgrade over shared passwords, regardless of which restructuring path a firm takes. Identity-bound access is a real upgrade over credential-bound access. Auditable accountability is a real upgrade over best-guess attribution.
Whatever the path forward looks like for your firm and your clients, the path is leading somewhere worth going. That's worth saying clearly even when the immediate experience of the rollout is frustrating.
Change is the Constant, Conversation is the Cure
Things will continue to change. Salesforce's rollout has been revised more than once already, and the synced-versus-device-bound question is the kind of issue that could be settled definitively by a single configuration change on Salesforce's side. We're tracking this closely for our own clients and our own firm, and we'll publish more as the picture clarifies.
If you're a consulting partner, an admin, or a security-focused practitioner working through this transition, we'd like to hear from you. The community conversations on this have been valuable, and we want to keep contributing to them.
Closing
Most of what we've written here is critical of how the rollout has been managed. We mean the criticism, and we think it's earned. We also think the substance of what Salesforce is doing is right, and we think the consulting partner community is going to have to change in ways that will be uncomfortable but ultimately beneficial — for our clients, for our firms, and for the broader trustworthiness of the platform we all build on.
The version of consulting that depended on credential ambiguity is ending. The version that depends on competence, transparency, and properly governed access is starting. We think that's a trade worth making, even when the transition is rough.
We'll be writing more about this. Watch this space.
Sources cited in this post include: Salesforce Help articles "Prepare for MFA Enforcement for All Employee Users," "Prepare for Phishing-Resistant MFA Enforcement for Privileged Users including Admins," and "Security-Related Product Updates to the Salesforce Platform: User Identity, Data Protection, and Access Controls" the 1Password community forum; Microsoft Entra ID April 2026 documentation; and SentinelOne and Thales analyses of phishing-resistant MFA categories.
