TL;DR: Salesforce will require phishing-resistant MFA for employee logins in sandbox environments starting June 22, 2026 and then phase enforcement into production on July 1, reflecting a wider shift away from legacy MFA for privileged access. The change reinforces that password-based and code-based methods no longer provide enough assurance when AI-driven phishing now dominates the attack path, according to Yubico.
At a glance
What this is: Salesforce is moving privileged employee access toward phishing-resistant MFA, making hardware-backed or built-in authenticator methods the expected baseline for higher-risk logins.
Why it matters: IAM teams should treat this as another sign that traditional MFA methods no longer provide enough assurance for privileged accounts, especially where phishing and account recovery attacks remain viable.
By the numbers:
- 86% of phishing attacks are now AI-driven, according to Yubico.
- Salesforce will enforce MFA in sandbox environments beginning June 22, 2026, according to Yubico.
Context
Phishing-resistant authentication means the login process proves the user and the destination site together, rather than relying on a shared secret or a one-time code that can be intercepted or replayed. In this article, the identity security question is whether privileged access can still be governed safely with legacy MFA when attack tooling now scales phishing faster than review cycles can react.
Salesforce's enforcement dates make the operational point clear for enterprise identity programmes. When privileged users are required to use security keys or built-in authenticators, the weak link shifts from password handling to authenticator provenance, registration discipline, and policy coverage across direct and SSO paths.
The broader governance issue is not Salesforce-specific. When elevated access remains protected by methods that are phishable, the control is being asked to defend a role it was never designed to withstand under current threat conditions.
Key questions
Q: What breaks when privileged users still rely on phishable MFA?
A: Phishable MFA fails when the attacker can trick a user into revealing or approving the second factor, which leaves privileged access exposed even though MFA is technically in place. For high-risk roles, the failure mode is that the control adds friction without removing replayable or interceptable secrets, so account takeover remains feasible.
Q: Why do phishing-resistant factors matter more for administrators than for standard users?
A: Administrators have broader permissions, more recovery value, and a larger blast radius if compromised. Phishing-resistant factors matter because they bind authentication to the device and the real site, making credential capture far less useful to an attacker. That changes the risk profile at the point where access is most dangerous.
Q: What signs show that an MFA programme is still too weak for privileged access?
A: Weak signals include continued use of SMS, push, or TOTP for elevated roles, policy exceptions across SSO paths, and delayed backup authenticator enrolment. If administrators can still authenticate with methods that a phishing kit can relay or coerce, the programme has not yet reached phishing-resistant assurance.
Q: Should organisations prioritise phishing-resistant MFA over other identity projects?
A: For most enterprises, yes, when the goal is to reduce the most common account takeover path. It should be prioritised ahead of lower-value convenience changes because authentication weakness often becomes the first step in broader identity compromise and later governance failures.
Technical breakdown
Why phishable MFA fails for privileged access
Traditional MFA often reduces risk by adding a second factor, but it still depends on a secret or transaction the user can be tricked into revealing or approving. SMS codes, TOTP apps, and push notifications can all be intercepted, replayed, or socially engineered. For privileged users, that weakness matters more because a single successful login can expose administrative actions, production settings, and downstream access paths. Phishing-resistant methods change the trust model by binding authentication to the legitimate site and a device-held private key, which removes the remote extraction path that attackers exploit.
Practical implication: treat phishable MFA as insufficient for privileged accounts and map elevated roles to phishing-resistant methods only.
How FIDO2 and WebAuthn change the authentication path
FIDO2 and WebAuthn use public-key cryptography so the private key remains on the device and cannot be copied into a phishing page. The website proves its identity to the authenticator, and the authenticator proves possession without exposing reusable secrets. That matters because the attacker no longer gets a usable code even if the user is lured to a lookalike site. In governance terms, the control shifts from shared-secret protection to cryptographic proof of origin and possession, which is materially stronger for administrative access than code-based MFA.
Practical implication: verify that privileged login policies require device-bound authenticators rather than codes or push approvals.
Why sandbox enforcement is a governance signal, not a side note
Starting enforcement in sandbox environments is a sign that authentication policy is being pushed left into test and pre-production paths before it reaches production. That reduces surprise failures later, but it also forces teams to inventory where privileged identities authenticate, including direct logins and federated paths. If sandboxes are not covered, teams can build exceptions into the very environments used to validate controls. For identity teams, the important architectural question is whether policy enforcement is consistent across the full login estate, not just the production endpoint.
Practical implication: extend authentication policy checks to sandbox, production, and SSO paths before enforcement dates arrive.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Phishable MFA is no longer a defensible control baseline for privileged access. Salesforce's move reflects a broader control reset: elevated users are too valuable a target for codes and push approvals that can be socially engineered. The practical conclusion is that access assurance for administrators now has to assume hostile phishing conditions as normal.
Phishing-resistant authentication marks a shift from secret sharing to cryptographic possession proof. Security keys and built-in authenticators based on FIDO2 and WebAuthn remove the remote reuse path that attackers rely on. That changes identity assurance from something an attacker can intercept in transit to something anchored in a device-bound private key.
86% of phishing attacks being AI-driven makes legacy MFA a scaling problem, not just a user problem. When attack campaigns become faster, more convincing, and easier to customise, the issue is not whether one user clicks the wrong link. The issue is whether the control model can still hold under industrialised social engineering. The implication is that privileged identity policy must be set for attacker scale, not average-user caution.
Sandbox-first enforcement shows that authentication governance now has to span the full identity lifecycle. If controls are only tightened at production cutover, teams will miss the places where policy drift, exception handling, and user registration failures first appear. The lesson for practitioners is to govern privileged MFA as a programme control, not a release-day checkbox.
Phishing-resistant access is becoming a baseline expectation for high-risk roles, not a niche hardening choice. Once a major enterprise platform moves in this direction, identity teams should assume that privileged authentication standards will keep tightening across cloud and SaaS estates. The implication is to re-evaluate which users, roles, and login paths still depend on phishable methods.
What this signals
Phishing-resistant authentication is becoming the practical control line for elevated access. Once privileged users are forced onto device-bound authenticators, the old distinction between “MFA enabled” and “MFA protected” stops being useful. Programmes should now separate phishable factors from authenticators that actually bind the login to the real site and a real device.
Privileged access governance has to include authenticator type, not just enrolment status. A user can be fully enrolled in MFA and still be exposed if the method is SMS, TOTP, or push approval. That means access reviews need to capture the assurance level of the factor in use, not simply whether a factor exists.
Phishing-resistant policy belongs in the same governance conversation as PAM and SSO. When administrators can authenticate through multiple paths, weak coverage in one path undermines the whole control set. The operational question is whether your privileged access programme enforces the same authentication standard everywhere elevated access is possible.
For practitioners
- Inventory privileged Salesforce identities Identify System Administrators, power users, and any elevated service or admin roles that authenticate into Salesforce through direct or federated paths.
- Replace code-based MFA for high-risk roles Move administrators and other elevated users onto security keys or built-in authenticators that satisfy phishing-resistant requirements rather than SMS, TOTP, or push approvals.
- Check SSO enforcement end to end Verify that the same phishing-resistant policy applies to both direct Salesforce logins and SSO-based access so exceptions do not reintroduce weaker authentication.
- Register backup authenticators before cutoff dates Require primary and backup device registration early so administrators are not locked out when enforcement begins in sandbox and then production.
Key takeaways
- Salesforce's rollout shows that phishable MFA no longer provides enough assurance for privileged enterprise access.
- AI-driven phishing makes authentication method choice a governance issue, not just a user-experience decision.
- Teams should align privileged access, SSO, and authenticator policy before enforcement dates expose coverage gaps.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on weaker MFA methods versus phishing-resistant authentication for privileged users. |
| NHI-10 — Human Use of NHI | The article covers human admins using privileged enterprise accounts, a control area where human misuse patterns matter. | |
| Recommendation — Replace phishable authentication for privileged NHI access with phishing-resistant methods bound to device proof. Restrict privileged human sessions to stronger authenticator requirements and separate admin use from routine login paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator management directly applies to replacing and governing MFA methods for privileged accounts. |
| IA-2 — Identification and Authentication (Organizational Users) | Privileged Salesforce users are organisational users whose login assurance must be governed explicitly. | |
| Recommendation — Enforce IA-5 to require phishing-resistant authenticators for elevated access and retire weaker factors. Apply IA-2 to ensure organisational users with elevated rights authenticate using approved strong methods. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about access assurance for privileged users and how permissions are activated securely. |
| Recommendation — Use PR.AA-05 to align privileged access permissions with phishing-resistant authentication requirements. | ||
Key terms
- Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
- FIDO2: FIDO2 is a passwordless authentication standard that uses public-key cryptography instead of shared secrets. A service stores the public key while the authenticator keeps the private key, allowing users to prove possession without sending reusable credentials over the network.
- WebAuthn: WebAuthn is a browser and platform standard for phishing-resistant authentication using public-key cryptography. It binds the authenticator to the origin and signs a challenge instead of sending a reusable code, which makes replay and relay attacks far harder.
- Phishable MFA: Phishable MFA is multi-factor authentication that can still be tricked by an attacker into revealing or relaying a valid login factor. It usually relies on secrets or prompts that can be captured, replayed, or socially engineered. In practice, it reduces risk but does not fully resist phishing, session hijacking, or adversary-in-the-middle attacks.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 26, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org