Home / security / mfa-enforcement-strategy

mfa-enforcement-strategy

Org-wide MFA rollout strategy, phased enablement, exception governance, and audit. Triggers: MFA rollout plan, MFA policy, MFA governance. NOT for per-user-type enforcement patterns — use security/mfa-enforcement-patterns.

• v1.1.1
• Salesforce Spring '25+
• Updated 2026-10-03
• Security
• Operational Excellence

• mfa-enforcement-strategy
• multi-factor-authentication
• org-wide-mfa
• sso-mfa
• security-settings
• verification-methods
• phishing-resistant-mfa

Open the skill folder on GitHub

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.

Questions to Ask Before Configuring

Core Concepts

The 2026 enforcement events

UNVERIFIED (2026-10-03): the dates, populations, and quotes in this subsection come from Salesforce Help articles (listed in references/well-architected.md) that return only a script shell to an unauthenticated fetch; confirm them signed in before planning against them. The fetchable Security Guide (Summer '26) states only that Salesforce "requires MFA for logins to Salesforce products" and that the requirement "applies equally to direct logins with a Salesforce username and password and to logins via single sign-on (SSO)."

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:

Two levers you may be relying on today disappear (UNVERIFIED (2026-10-03), Help only; the Summer '26 Metadata API guide still documents the waiver permission as overriding enableMFADirectUILoginOptIn): 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. UNVERIFIED (2026-10-03), Help only: 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.

Phishing-resistant MFA and the permissions that trigger it

UNVERIFIED (2026-10-03), Help only: PRMFA applies to users with the System Administrator profile or any one of Modify All Data, View All Data, Customize Application, or Author Apex. Those four permissions travel on ordinary permission sets and permission set groups, so the PRMFA population is routinely far larger than the admin headcount. Enumerate it from effective permission assignments, never from the profile name alone.

Salesforce Authenticator and TOTP apps remain valid standard MFA. They simply do not satisfy the privileged-user requirement, which is the detail that strands admin populations who "already did MFA years ago."

Org-wide enforcement versus user self-registration

Salesforce distinguishes requiring MFA for direct logins to the Salesforce UI from users casually adding a verification method. Org-wide enforcement changes the login outcome for every in-scope user until they satisfy the requirement or a documented exemption applies. Treat enforcement as a program: communications, help desk readiness, backup codes or device replacement, and executive sponsorship matter as much as the toggle in Setup.

Supported verification methods (product surface)

The TwoFactorMethodsInfo object (Object Reference) records which methods each user has registered: HasSalesforceAuthenticator, HasTotp (authenticator apps that generate time-based one-time passwords), HasSecurityKey (WebAuthn-compatible keys), HasBuiltInAuthenticator (Touch ID, Windows Hello), HasU2F, and HasTempCode (an admin-generated temporary code). Org settings switch some methods on: enableBuiltInAuthenticator, enableU2F, enableLightningLogin, and allowUserAuthenticationByCertificate in sessionSettings. Pick a small approved set for the enterprise so help desk procedures stay consistent; avoid an unbounded list of consumer apps unless support teams are staffed for it. Querying TwoFactorMethodsInfo needs the "Manage MFA in API" permission.

SSO and MFA delegation

When users access Salesforce exclusively through SSO where the IdP enforces MFA, Salesforce can treat that path as satisfying the MFA expectation for those users (UNVERIFIED (2026-10-03): stated in Salesforce Help, not in the fetchable Security Guide, which says only that the requirement applies to SSO logins too), provided direct Salesforce login is not a realistic bypass (for example, broad password-based login still enabled for the same population). The failure mode is familiar: SSO is “MFA protected” but a subset of users retains a Salesforce password path and never registers a second factor with Salesforce. Validate both the IdP authentication policy and Salesforce login channels together.

Exemptions and integration identities

Some categories of users or flows may be excluded or handled differently under documented Salesforce exemption patterns (for example narrowly scoped automation or legacy constraints). Exemptions should be time-bound, approved, and rare, each one is debt that auditors and incident responders will ask about. Prefer modern patterns for integration users (OAuth flows designed for automation) over stretching human MFA policies across machine principals.

Common Patterns

Phased rollout by persona

When to use: Medium and large orgs where a single “big bang” cutover risks revenue or operations.

How it works: Pilot with IT and admins, then business units, then contractors. Run parallel reporting on who has not registered a verification method. Pair each phase with office hours and scripted recovery steps.

Why not the alternative: Flipping enforcement for everyone at once without inventorying SSO bypass and integrations produces preventable lockouts and emergency rollbacks.

SSO-first with Salesforce direct login disabled for employees

When to use: Enterprise standard is SAML or OpenID Connect from a central IdP with strong MFA at the IdP.

How it works: Align IdP MFA with corporate policy, remove or tightly control Salesforce direct login for employee populations, and validate break-glass admin paths.

Why not the alternative: Leaving parallel login paths defeats the economic and security rationale of central MFA and complicates attestation.

Verification method standardization plus security key program

When to use: High-assurance teams (finance, admins, developers with deployment rights).

How it works: Offer FIDO2 keys and documented provisioning; keep TOTP as fallback where keys are impractical.

Why not the alternative: Push-only reliance on a single mobile OS vendor stack can stall travelers or regulated sites where phones are restricted.

Decision Guidance

Recommended Workflow

1. Inventory authentication paths: List IdP connections, remaining Salesforce-password users, Experience Cloud or external identity usage, and integration accounts.
2. Read current org posture: Retrieve Settings:Security and ProfileSessionSetting, and note sessionSettings.enableMFADirectUILoginOptIn, the method switches (enableBuiltInAuthenticator, enableU2F, enableLightningLogin), singleSignOnSettings.isLoginWithSalesforceCredentialsDisabled, and any profile with requiredSessionLevel HIGH_ASSURANCE. Query TwoFactorMethodsInfo for registration coverage (SOQL in references/metadata-examples.md).
3. Choose allowed verification methods: Publish the approved set, procurement for keys if needed, and help desk scripts for device loss.
4. Close bypasses before enforcement: Address direct login, dormant passwords, and shared accounts that cannot complete MFA personally.
5. Pilot and measure: Track registration completion, failed logins, and integration errors; adjust communications and training.
6. Enable enforcement with rollback owners: Name who can act during an incident and rehearse break-glass; once the enforcement dates pass, rehearse verification-method recovery, because disabling the setting is no longer available.
7. Run the local checker: From repo root: python3 skills/security/mfa-enforcement-strategy/scripts/check_mfa_enforcement_strategy.py --skip-skill --manifest-dir force-app to review retrieved Security.settings and ProfileSessionSetting files.

Review Checklist

Run through these before marking work in this area complete:

• [ ] SSO and direct-login posture documented; no silent bypass for the populations in scope
• [ ] Verification methods standardized; help desk trained on recovery
• [ ] Integration and automation accounts reviewed; exemptions documented with owners and expiry
• [ ] Executive and legal/compliance stakeholders aligned on timelines and residual risk
• [ ] Post-cutover monitoring for login failures and IdP saturation

Salesforce-Specific Gotchas

Full write-ups with sources are in references/gotchas.md.

Output Artifacts

Related Skills

• security/ip-range-and-login-flow-strategy: Login Flows, session policies, and IP-based login design (not org-wide MFA program management)
• security/network-security-and-trusted-ips: Trusted IP ranges and network-level controls
• security/transaction-security-policies: Targeted step-up and policy enforcement on events
• admin/integration-user-management: Integration users, OAuth/JWT patterns, and MFA waivers where applicable

Package files

• references/examples.md
• references/gotchas.md
• references/llm-anti-patterns.md
• references/metadata-examples.md
• references/well-architected.md
• templates/mfa-enforcement-strategy-template.md
• scripts/check_mfa_enforcement_strategy.py