mfa-enforcement-strategy

name	mfa-enforcement-strategy
description	Plan and operate Salesforce org-wide multi-factor authentication (MFA) enforcement: verification methods, phased rollout, SSO and API-only considerations, exemptions, and operational readiness. NOT for designing Login Flow post-authentication logic, IP allowlists, or conditional step-up policies—use ip-range-and-login-flow-strategy, network-security-and-trusted-ips, or transaction-security-policies instead.
category	security
salesforce-version	Spring '25+
well-architected-pillars	["Security","Operational Excellence"]
triggers	["We need an MFA enforcement strategy for our Salesforce org before we turn on org-wide MFA","How do we roll out Salesforce multi-factor authentication without breaking integrations and SSO users","Which verification methods count for Salesforce MFA and when does SAML SSO satisfy the MFA requirement","Who can be exempt from org-wide MFA enforcement and how do we document API-only integration users","Our security team wants a checklist for Salesforce MFA contractual requirement and production org defaults","What changes in the 2026 Salesforce MFA enforcement and which permissions require phishing-resistant MFA"]
tags	["mfa-enforcement-strategy","multi-factor-authentication","org-wide-mfa","sso-mfa","security-settings","verification-methods","phishing-resistant-mfa"]
inputs	["Identity model: SSO (SAML/OIDC) vs Salesforce local login, and whether direct login to Salesforce is still allowed","User populations: employees, contractors, service accounts, integration users, Experience Cloud or community logins in scope","Current verification methods registered and support model (help desk, device loss, travel)"]
outputs	["A phased rollout plan with communications, exception handling, and validation gates","Decision record for verification methods, IdP MFA posture, and exemption criteria aligned to official Salesforce guidance"]
dependencies	[]
version	1.1.0
author	Pranav Nagrecha
updated	"2026-07-08T00:00:00.000Z"

MFA Enforcement Strategy

Use this skill when you are defining how an organization turns on and sustains multi-factor authentication (MFA) for Salesforce human and non-human identities—not when you are wiring conditional challenges, IP-based login rules, or Flow-based login experiences. It focuses on org-wide enforcement posture, supported verification methods, Single Sign-On (SSO) delegation, exemptions, and the operational work that keeps logins working under pressure.

---

Before Starting

Gather this context before working on anything in this domain:

• How users authenticate today: Salesforce username and password only, hybrid SSO plus occasional direct login, or SSO-only with the Identity Provider (IdP) as the primary gate.
• Integration surface: Which workloads use UI sessions versus OAuth/JWT/API-only patterns, and which accounts are true automation principals versus humans using API access.
• Regulatory or contractual drivers: MFA is a baseline control in Salesforce contracts and security baselines; your program still needs a rollout plan, support playbooks, and exception governance regardless of what the platform enforces by default.

---

Core Concepts

The 2026 enforcement events

Salesforce is "enforcing Multi-Factor Authentication (MFA) for all employee logins, including direct UI and Single Sign-On (SSO), across both production and sandbox orgs." Two waves land on different dates, so a single "MFA deadline" on your program plan is already wrong:

Enforcement	Sandboxes	Production
MFA for all employee users	Starting June 22, 2026, staggered over approximately 7 days	Starting July 20, 2026, staggered over approximately 30 days
Phishing-resistant MFA (PRMFA) for privileged users, including admins	Starting June 22, 2026, staggered over approximately 7 days	Starting July 1, 2026, staggered over approximately 30 days

Two levers you may be relying on today disappear: the org-wide MFA setting becomes active and admins "no longer have the ability to deselect or disable it," and the Waive Multi-Factor Authentication for Exempt Users permission "no longer automatically exempt[s] users from MFA"—holders are "prompted to enroll and use an MFA verifier at login." Rewrite any exemption-dependent runbook against the sandbox date, which arrives first and is where you will discover what breaks.

SSO does not clear the bar by itself. An SSO login satisfies enforcement only where the IdP passes a standard-MFA or phishing-resistant-MFA signal to Salesforce via ACR (Authentication Context Class Reference) or AMR (Authentication Methods Reference, RFC 8176). Where the IdP sends no such signal, those users are "required to enroll an MFA verifier in the Salesforce UI"—so an IdP that enforces MFA but omits the claim still produces a visible change for every SSO user.