Salesforce's Phishing-Resistant MFA Requirements for Privileged Users and Admins — How Consulting Groups Can Accomplish This with Shared Logins

Salesforce just raised the security bar for anyone with admin access, and it's creating a real problem for consulting teams that rely on shared logins. Starting June 22, 2026 for sandboxes and July 1, 2026 for production, Salesforce is enforcing phishing-resistant multi-factor authentication (MFA) for all privileged users. For agencies managing client implementations, this means the old model of one shared "admin" account for the entire consulting team no longer works.

The challenge is straightforward: phishing-resistant MFA is tied to individual people and devices, not teams. But asking clients to pay for a separate named-user license for every consultant who touches their org isn't realistic. There's a solution, though, and it's simpler than you might think.

The Problem: Why Shared Logins Break Under Phishing-Resistant MFA

For years, consulting teams have operated on a single shared login for client orgs. One generic "admin" account that multiple consultants log into keeps costs down for clients and lets agencies staff up or down on projects without licensing conversations. Salesforce's new phishing-resistant MFA requirement breaks this model in several specific ways.

Passkeys Belong to One Person, Not a Team

Phishing-resistant MFA—whether it's security keys, Face ID/Touch ID, or a password manager like Bitwarden—is tied to a specific device or an individual's vault. A shared login can only be "owned" by one verified person at a time. The moment MFA is enforced, only whoever registered the passkey can get in without friction. Everyone else either needs their own registered verifier on that account or has to wait for the primary person to unlock access.

No More Quick Hand-Offs

Today, if Consultant A is busy, Consultant B can log into the shared account and jump in immediately. Once phishing-resistant MFA is enforced, flexibility disappears. Consultant B either needs their own registered verifier on that account (meaning literally sharing a passkey or security key device between people—a security nightmare) or has to wait on Consultant A to unlock or approve access. That kills the "whoever's free can jump in" model agencies rely on.

The Old Workaround Is Gone

Some shared accounts were set up with the "Waive Multi-Factor Authentication for Exempt Users" permission to sidestep this exact friction. That exemption no longer works automatically after enforcement. It now requires a support-approved exception from Salesforce, which isn't a fast or guaranteed path.

Sandbox Access Gets Hit First

Since sandbox enforcement starts before production, agency teams doing sandbox-based configuration or testing work will feel this disruption earlier than expected, potentially mid-project. This gives you less time to plan a solution.

Key Dates at a Glance

What's Changing: Salesforce's Phishing-Resistant MFA Enforcement

Starting June 22, 2026 for sandboxes and July 1, 2026 for production, Salesforce is requiring a stronger, "phishing-proof" type of login verification for anyone considered a "privileged user." This mainly means System Admins, but also applies to anyone with Modify All Data, View All Data, Customize Application, or Author Apex permissions—even if they're not full admins.

This isn't optional. Logins will be blocked for these users until they set up a compliant method. It applies whether people log in directly with a username/password or through Single Sign-On (SSO).

Why Regular MFA No Longer Counts

Regular MFA apps like Google Authenticator, Microsoft Authenticator, or Salesforce Authenticator (TOTP codes) will no longer count for privileged users. These are still "phishable"—a scammer can trick someone into typing that code into a fake login page. Salesforce wants privileged accounts protected with methods that can't be phished at all, because these are the accounts that can see or change everything in the org.

Who Gets Affected

Affected: System Administrator profile, or anyone with Modify All Data, View All Data, Customize Application, or Author Apex permissions.

Not affected: Regular standard users without those permissions, external Experience Cloud/community users, and Chatter External/Free users.

Heads up: The old "Waive MFA for Exempt Users" permission stops working automatically. Anyone relying on that will start getting prompted to enroll, unless they specifically request an exception from Salesforce Support.

What Actually Counts as Compliant

Salesforce accepts three types of phishing-resistant MFA:

• Security Keys (physical devices like a YubiKey)
• Built-in device authenticators (Face ID, Touch ID, Windows Hello)
• Password managers with passkey support (like Bitwarden)

The third option is the game-changer for consulting teams.

The Solution: Bitwarden for Shared Logins

Here's where Bitwarden comes in. It's a password manager that supports passkeys—a phishing-resistant authentication method that Salesforce accepts. More importantly, it solves the shared login problem in a way that's practical, affordable, and secure.

How Bitwarden Works for Consulting Teams

Instead of sharing a single login with multiple people, each consultant gets their own Bitwarden vault. The shared Salesforce login credentials are stored in an organization vault that the entire team can access. When a consultant needs to log in, they authenticate to Bitwarden using their own passkey, then Bitwarden auto-fills the shared Salesforce credentials.

From Salesforce's perspective, the login is coming from one account (the shared admin account), but the authentication layer—the part that actually matters for security—is tied to individual consultants. Each person's access is logged, audited, and tied to their identity.

Why This Works

• Meets Salesforce's requirement: Bitwarden passkeys are phishing-resistant MFA. Salesforce accepts them.
• Keeps costs down: Clients still only pay for one named-user license (the shared admin account). Consultants don't need individual licenses.
• Maintains flexibility: Any consultant with access to the organization vault can log in immediately. No waiting for someone else to unlock access.
• Improves security: Each consultant's access is individually authenticated and audited. You know exactly who logged in and when.
• Scales easily: Adding a new consultant to a project is as simple as giving them access to the organization vault in Bitwarden.

Beyond This Use Case: Additional Value

Bitwarden isn't just a workaround for this specific problem. It delivers real value across multiple dimensions:

Security: Bitwarden uses end-to-end encryption, meaning even Bitwarden's own team can't see your passwords. It's open-source, so the security model is transparent and auditable.

Compliance: Bitwarden supports SSO, audit logging, and granular permission controls. If your clients need to meet compliance requirements (SOC 2, HIPAA, PCI-DSS), Bitwarden's enterprise features help you get there.

Cost efficiency: Bitwarden's pricing is significantly lower than competitors like 1Password or LastPass. For consulting teams managing multiple client projects, that adds up.

Team management: Bitwarden's organization feature lets you create separate vaults for different clients or projects. You can grant access to specific team members without exposing credentials across the entire organization.

Implementation Strategy for Consulting Teams

Here's how to implement this before the June 22 sandbox deadline:

Step 1: Set Up Bitwarden Organization

Create a Bitwarden organization account. This is your central hub for managing team access to shared credentials.

Step 2: Create Organization Vaults by Client

For each client project, create a separate vault within your Bitwarden organization. Store the shared Salesforce admin credentials in each vault.

Step 3: Enroll the Shared Admin Account in Bitwarden Passkeys

Log into the shared Salesforce admin account and set up Bitwarden as the phishing-resistant MFA method. This is the one-time setup that satisfies Salesforce's requirement.

Step 4: Grant Team Access

Add each consultant to the appropriate client vault in Bitwarden. They authenticate to Bitwarden with their own passkey, then access the shared Salesforce credentials.

Step 5: Test Before Enforcement

Before June 22, test the entire flow in your sandbox. Make sure consultants can log in, access records, and perform their normal tasks without friction.

Step 6: Document and Train

Create a simple guide for your team on how to use Bitwarden to access shared Salesforce accounts. Most consultants will pick it up immediately, but documentation prevents confusion.

The Business Conversation This Forces

Underneath all of this is a larger tension: Salesforce's security direction increasingly assumes one login equals one verified human. Clients still may not want to pay for individual named licenses per consultant, but this MFA requirement is effectively forcing that conversation to the surface.

Bitwarden gives you a bridge solution that works now. But it's worth having a conversation with clients about the long-term direction. Some may decide that individual named licenses per consultant make sense. Others may stick with the shared login model and use Bitwarden. Either way, you're prepared.

Connecting to Your Broader Salesforce Practice

If your consulting team is managing complex Salesforce implementations, this MFA requirement is just one of many security and compliance considerations. For a comprehensive approach to Salesforce consulting, consider how this fits into your broader Salesforce consulting services. Proper sales activity tracking and territory management are equally important for client success.

Frequently Asked Questions

What is phishing-resistant MFA in Salesforce?

Phishing-resistant MFA is a login method that cannot be tricked out of a user by a fake login page. Salesforce accepts three types for privileged users: hardware security keys (such as a YubiKey), built-in device authenticators (Face ID, Touch ID, Windows Hello), and passkeys stored in a FIDO2/WebAuthn-compliant password manager. Regular authenticator-app codes (TOTP) no longer count for these users.

Who has to use phishing-resistant MFA?

Any privileged user: anyone with the System Administrator profile, or with Modify All Data, View All Data, Customize Application, or Author Apex permissions, whether those are granted by profile or permission set. Standard users without those permissions, external Experience Cloud users, and Chatter External or Free users are not affected.

When does Salesforce enforce phishing-resistant MFA?

Enforcement begins June 22, 2026 in sandboxes and July 1, 2026 in production, staggered over several days so the exact day varies by org. Once an org reaches its date, affected users are blocked from logging in until they register a compliant method.

Can a consulting team keep using a shared Salesforce login?

Yes, but not by passing a single passkey between people. A phishing-resistant passkey is tied to one device or vault. The supported approach is to store the shared login's passkey in a shared password-manager vault, so each consultant authenticates with their own passkey and then accesses the shared credentials.

Does a password manager like Bitwarden meet Salesforce's MFA requirement?

Yes, provided it is FIDO2/WebAuthn-compliant and stores an actual passkey. Salesforce updated its guidance in June 2026 to confirm that cloud-synced passkeys in managers such as Bitwarden, 1Password, and iCloud Keychain satisfy the requirement. Using a password manager only for username and password alongside a TOTP code does not qualify.

Does the old MFA exemption still work?

No. The Waive Multi-Factor Authentication for Exempt Users permission stops working automatically after enforcement. Continuing to rely on it now requires a support-approved exception from Salesforce, which is not a fast or guaranteed path. 

Getting Ahead of the Deadline

The sandbox enforcement date is June 22, 2026. That's your real deadline. If you're managing multiple client projects, start testing Bitwarden in sandbox now. The setup takes a few hours, and it's far better to discover issues in sandbox than to have consultants locked out of production on July 1.

For consulting teams still using shared logins, this isn't a crisis—it's a prompt to modernize your access model. Bitwarden makes that modernization simple, affordable, and secure. Contact us today if you want to discuss how to implement this for your consulting practice.