How should organisations meet Salesforce’s MFA requirement without creating avoidable login friction for users?

The cleanest approach is to use MFA at the identity layer already in place, then apply SSO so users authenticate once and reuse that trust for approved apps. Keep policy granular, so MFA is required where risk is higher and minimized where access is routine. That balance improves adoption while still protecting cloud resources and sensitive accounts.

Use the identity layer you already trust

The easiest way to reduce Salesforce login friction is to avoid making Salesforce its own separate authentication island. If your organisation already has a central identity provider, place MFA there and let Salesforce rely on federated sign-in. That way, the user satisfies the stronger check once, rather than repeating a local challenge for every cloud app.

For workforce access patterns, Workforce Identity Security Guide is the clearest internal reference for combining phishing-resistant MFA, SSO, and step-up checks without turning every login into a high-friction event.

Where Salesforce-specific friction usually comes from

Most avoidable friction comes from over-applying MFA to low-risk, repetitive sessions, or from using weak factors that force frequent re-prompting. A better design is to preserve the trust established by the identity layer, then step up only when the login context changes, such as a new device, a risky network, or a sensitive Salesforce function.

That model aligns with the practical lesson from Salesloft OAuth token breach and Klue OAuth Supply Chain Breach, where access was not broken by a repeated password prompt but by trust in connected identity and token flows.

Salesforce also supports the cleaner pattern described in IAM and Identity Provider Buyer’s Guide, which is to choose an identity platform that can centralise SSO, MFA policy, and lifecycle controls instead of bolting those controls onto every app separately.

How to balance stronger assurance with better user experience

Granular policy is the key design choice. Require MFA more aggressively for privileged users, remote access, high-value records, and unusual context, but reduce repetition for routine app use when the session is already strongly established. The goal is not to weaken assurance, but to concentrate challenge where it actually changes risk.

Phishing-resistant methods are especially important because they lower both abuse risk and user confusion. Passwordless and Passkeys Guide is useful here because it frames passkeys and FIDO2 as a way to improve both resistance and usability, not just as another control to add.

For organisations that want a widely understood external reference for that approach, NIST SP 800-63 Digital Identity Guidelines is a solid anchor for authenticator assurance, phishing-resistant authentication, and assurance-based step-up decisions.

Risk and Threat Considerations

Over-friction is not just a usability problem. When MFA is too noisy or badly timed, users start seeking shortcuts, approving prompts reflexively, or bypassing sanctioned flows through shadow processes and help-desk workarounds. That creates more exposure than a well-designed, risk-based MFA posture.

Failure mechanism: Excessive prompts, poor factor choice, or inconsistent SSO behaviour can drive prompt fatigue, token misuse, or unsafe recovery paths that attackers can exploit through phishing, social engineering, or session theft.

Impact: Users are more likely to reuse weak paths or approve malicious access, while defenders lose the benefit of MFA as a practical barrier rather than a box-ticking requirement.

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-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	MFA assurance and federated login are central to the question.
Recommendation — Use assurance-based MFA and step-up rules to reduce repetitive prompts while preserving strong authentication.
NIST CSF 2.0	PR.AA-05 — Authentication strengthened with MFA	The question is about applying MFA without degrading login usability.
	PR.AA-01 — Identity and access roles managed	Granular access policy and SSO depend on clear identity governance.
Recommendation — Implement MFA through the identity provider and apply it selectively by risk. Align authentication policy to role and access context so routine logins stay low friction.
OWASP Non-Human Identity Top 10	NHI-04 — Insecure Authentication	Federated login and token-based access can still be weakened by poor authentication design.
	NHI-07 — Long-Lived Secrets	Reducing login friction often involves token reuse and session trust, which must be bounded.
Recommendation — Use phishing-resistant authentication and avoid weak fallback paths for Salesforce access. Limit session and token lifetime so convenience does not become persistent access.

Practitioner Guidance

What to prioritise: Put the strongest factor at the identity provider, then decide where Salesforce should accept federated trust versus requiring step-up. If users must authenticate separately inside Salesforce, friction will usually rise faster than security.

What to verify: Confirm that the login policy distinguishes ordinary usage from privileged or sensitive actions, and that recovery, device change, and fallback flows are not weaker than the primary MFA path. Many “MFA” deployments fail in the exception handling, not the main login.

Practitioner takeaway: The best balance is usually centralised SSO with phishing-resistant MFA at the identity layer, plus narrowly targeted step-up rules, because that preserves user flow while keeping the real security boundary where it belongs.