Multi-Factor Authentication for Users

Introduction
Multi-Factor Authentication (MFA) is one of the most heavily emphasized topics in the Advanced Security and Access section of the Salesforce Advanced Administrator exam. Salesforce has made MFA a contractual requirement for all customers accessing Salesforce products through the user interface, and as an advanced administrator you are expected to know how to enable it, enforce it, troubleshoot it, and design around it when single sign-on or integrations are involved. This guide walks you through why MFA matters, what it is, how it works inside Salesforce, and how to recognize and answer exam questions on the subject.

Why Multi-Factor Authentication Is Important
Usernames and passwords alone are no longer sufficient to protect business data. Phishing, credential stuffing, keylogging, and password reuse mean that a stolen password can give an attacker direct access to a CRM full of customer data, financial information, and intellectual property. MFA dramatically reduces this risk by requiring the user to prove their identity with a second factor that an attacker is unlikely to possess.

From a Salesforce perspective, there are three key reasons MFA is important:
1. Contractual requirement: Effective February 1, 2022, Salesforce requires all customers to use MFA for direct UI logins to Salesforce products. Beginning in 2023 and continuing into 2024, Salesforce began automatically enabling and then enforcing MFA across orgs.
2. Data protection and compliance: Regulations and standards such as GDPR, HIPAA, SOC 2, and PCI DSS increasingly expect strong authentication controls.
3. Defense in depth: MFA complements other security tools you will be tested on, such as login IP ranges, login hours, session settings, and transaction security policies.

What Multi-Factor Authentication Is
MFA requires two or more pieces of evidence (factors) to verify a user's identity. The factors fall into familiar categories:
- Something you know: a password or PIN.
- Something you have: a mobile device running an authenticator app, or a physical security key.
- Something you are: a fingerprint, face scan, or other biometric.

In Salesforce, the first factor is always the username and password (or the identity provider credentials when SSO is used). The second factor must be one of the verification methods that Salesforce considers strong.

Supported Verification Methods
- Salesforce Authenticator mobile app: Salesforce's own app that supports push notifications. The user simply taps Approve, and it can use location-based automated verification for trusted locations.
- Third-party TOTP authenticator apps: Google Authenticator, Microsoft Authenticator, Authy, and similar apps that generate a time-based one-time password.
- Security keys: Physical devices that support WebAuthn (FIDO2) or U2F standards, such as YubiKey or Google Titan.
- Built-in authenticators: Platform biometrics such as Windows Hello, Touch ID, or Face ID, using WebAuthn.

Methods That Do NOT Satisfy the MFA Requirement
This is a favorite exam trap. The following are not accepted as MFA verification methods for the Salesforce requirement:
- SMS text message codes
- Email-based one-time codes
- Phone calls
- Security questions
These methods are still used for device activation (identity verification when logging in from an unrecognized browser or device), but device activation is not the same as MFA and does not meet the contractual requirement.

How MFA Works in Salesforce

1. Enabling MFA for UI Logins
MFA for the Salesforce user interface is controlled by the user permission Multi-Factor Authentication for User Interface Logins. You can grant this permission through a profile or, more flexibly, through a permission set. Once a user has this permission, the next time they log in they are prompted to register a verification method, and from then on every UI login requires both the password and the second factor.

Modern orgs also have an org-wide setting in Setup > Identity Verification called Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org. When this setting is enabled, every user who logs in directly with a Salesforce username and password is required to use MFA regardless of their profile or permission set assignments. Salesforce has been turning this on automatically as part of MFA auto-enablement and enforcement.

2. Enabling MFA for API Logins
A separate permission, Multi-Factor Authentication for API Logins, requires users to provide a second factor when authenticating through the API with a username and password. When this is enabled, the user must supply a time-based token generated by an authenticator app in place of, or in addition to, the security token in the password field. Note that API connections using OAuth flows and integration users are generally exempt from the UI MFA requirement, which is why best practice is to dedicate integration users and use OAuth rather than username-password API logins wherever possible.

3. Registering a Verification Method
Users register methods from their personal settings under Advanced User Details in the App Registration fields (for example, App Registration: Salesforce Authenticator, App Registration: One-Time Password Generator, Security Key (U2F or WebAuthn), Built-In Authenticator). Administrators can see which methods a user has registered on the user detail page and can disconnect them from there.

4. Session Security Levels and High Assurance
Salesforce assigns a session security level to every session: Standard or High Assurance. By default, logging in with username and password alone produces a Standard session, while completing MFA produces a High Assurance session. These levels are configured in Setup > Session Settings under Session Security Levels, where you can move authentication methods (Username Password, Delegated Authentication, Activation, Lightning Login, Multi-Factor Authentication, SSO, and so on) between the two columns.

You can then require High Assurance for sensitive resources, which is called step-up authentication. Examples include:
- Setting Session Security Level Required at Login to High Assurance on a profile, which forces MFA at login for users with that profile.
- Requiring High Assurance to access specific connected apps.
- Requiring High Assurance to access Reports and Dashboards through the Session Settings option.
- Raising the session level to High Assurance in a Login Flow or when exporting data.
If a user is in a Standard session and tries to access a High Assurance resource, Salesforce prompts them for MFA on the spot.

5. Login Flows and MFA
Login Flows allow you to insert custom logic after authentication but before the user reaches the home page. A login flow can call the Verify Identity or MFA actions to challenge a user with MFA conditionally, for example only when they log in from outside the corporate network or only for certain profiles. This is a common exam scenario for implementing conditional or risk-based MFA.

6. MFA with Single Sign-On
When users authenticate through SSO (SAML or OpenID Connect), Salesforce does not see their password; the identity provider authenticates them. The MFA requirement can be satisfied in two ways:
- Enable MFA at the identity provider level (Okta, Azure AD, Ping, and others). This is the recommended approach because the IdP controls the whole authentication experience.
- Use Salesforce MFA for SSO users by enabling MFA via a login flow or by setting the session security level required for SSO to High Assurance, which triggers Salesforce's own MFA challenge after the SSO assertion is accepted.
Remember: the permission Multi-Factor Authentication for User Interface Logins on its own applies to direct username and password logins; for SSO users you need the IdP or a High Assurance requirement to enforce Salesforce MFA.

7. Lightning Login
Lightning Login lets users log in without a password by approving a push notification in Salesforce Authenticator and using a device biometric or PIN. It is enabled in Session Settings and requires the Lightning Login User permission. Lightning Login is itself considered a form of MFA because it uses possession (the phone) plus a biometric or PIN, replacing the password factor.

8. Exempting Users
Some users should not be subject to MFA, such as users who only access Salesforce through the API, test automation users, or users whose login is handled entirely by an external IdP with its own MFA. Salesforce provides the permission Waive Multi-Factor Authentication for Exempt Users, which excludes a user from the org-wide MFA requirement when the Require MFA for all direct UI logins setting is turned on. Use this sparingly and only for legitimate exemption categories defined in the MFA FAQ.

9. Troubleshooting and Recovery
Administrators must handle real-world situations where users lose or replace their devices:
- Disconnect a verification method: On the user detail page, click Disconnect next to the registered method (for example, App Registration: Salesforce Authenticator). The user is prompted to register a new method on next login. Admins need the Manage Multi-Factor Authentication in User Interface permission to do this.
- Generate a temporary verification code: From the user record, an administrator (or a user with the appropriate permission) can generate a temporary code that is valid from 1 to 24 hours. The user can log in with this code while they set up a new device. A user can only have one active temporary code at a time, and it can be expired early by the admin.
- Identity Verification History: Found under Setup, this log shows every verification attempt, the method used, the result, and the user, which is invaluable for auditing and troubleshooting.
- Login History: Shows login attempts and whether the session reached High Assurance.

10. Related Permissions to Memorize
- Multi-Factor Authentication for User Interface Logins: requires MFA for UI logins.
- Multi-Factor Authentication for API Logins: requires a TOTP token for username-password API logins.
- Manage Multi-Factor Authentication in User Interface: lets an admin disconnect methods, generate temporary codes, and view Identity Verification History.
- Manage Multi-Factor Authentication in API: allows management of MFA through the API.
- Waive Multi-Factor Authentication for Exempt Users: excludes a user from the org-wide MFA requirement.
- Lightning Login User: allows passwordless login with Salesforce Authenticator.

Best Practices for Advanced Administrators
- Use permission sets rather than profiles to roll out MFA in phases, piloting with a small group before enabling for everyone.
- Communicate ahead of rollout and provide instructions for installing Salesforce Authenticator or a TOTP app.
- Register at least two verification methods per user when possible to reduce lockouts.
- Dedicate integration users that authenticate via OAuth so that MFA for API does not break integrations.
- Use step-up authentication (High Assurance) for sensitive features rather than relying on MFA at login alone.
- Review Identity Verification History regularly for failed attempts.
- Prefer enforcing MFA at the IdP for SSO users and keep Salesforce MFA as a safety net for any remaining direct logins, including administrators who log in with a username and password as a fallback.

How to Approach Exam Questions on This Topic
Exam questions on MFA are usually scenario-based. Read the scenario carefully and identify what is really being asked: Is it about enabling MFA, enforcing it conditionally, exempting someone, troubleshooting a lost device, or distinguishing MFA from a similar feature? Then map the scenario to the specific permission, setting, or feature.

Exam Tips: Answering Questions on Multi-Factor Authentication for Users

1. Know the difference between MFA and device activation. If a question mentions an email or SMS code sent when logging in from a new browser, that is device activation (identity verification), not MFA. SMS, email, phone calls, and security questions never satisfy the MFA requirement.

2. Match the permission to the login type. UI logins use Multi-Factor Authentication for User Interface Logins; username-password API logins use Multi-Factor Authentication for API Logins. If the question involves an integration breaking after MFA was enabled, the answer usually involves the API permission, a security token or TOTP token, or switching to OAuth with a dedicated integration user.

3. Permission sets over profiles for phased rollouts. When a question asks for the most flexible or least disruptive way to enable MFA for a subset of users, choose a permission set.

4. Conditional or step-up MFA points to session security levels or login flows. If users should be challenged only when accessing reports, a connected app, or sensitive data, think High Assurance session security level. If MFA should depend on IP address, profile, or other logic at login time, think Login Flow.

5. SSO scenarios. If users log in via SSO and MFA must be enforced, the best answer is typically to enable MFA at the identity provider, or to require a High Assurance session level for the SSO authentication method so Salesforce challenges the user after SSO. The UI login permission alone does not challenge SSO users.

6. Lost or replaced phone. The correct administrator action is to disconnect the registered verification method from the user record and/or generate a temporary verification code (valid 1 to 24 hours). Resetting the password is a distractor; it does not fix the MFA device issue.

7. Exemptions. If a question asks how to exclude a specific user (such as a test automation account or an API-only user) from the org-wide MFA requirement, the answer is the Waive Multi-Factor Authentication for Exempt Users permission.

8. Auditing and troubleshooting. If the question asks where to see which verification method a user used or why a verification failed, the answer is Identity Verification History. For whether a session reached High Assurance, check Login History.

9. Recognize supported methods. Salesforce Authenticator, third-party TOTP apps, security keys (WebAuthn/FIDO2/U2F), and built-in authenticators such as Touch ID or Windows Hello are correct. Any answer listing SMS or email as an MFA method is wrong.

10. Lightning Login is MFA-compliant. If a scenario wants passwordless login that still satisfies MFA, the answer is Lightning Login with Salesforce Authenticator, requiring the Lightning Login User permission and the Lightning Login setting in Session Settings.

11. Eliminate distractors. Answers involving login IP ranges, login hours, password policies, or profile restrictions may improve security but do not implement MFA. Select them only if the question explicitly asks for something other than MFA.

12. Watch for the words direct and all. The org-wide setting Require MFA for all direct UI logins applies to username-password logins only. SSO users are affected by IdP settings or High Assurance requirements, not by this checkbox alone.

Summary
Multi-Factor Authentication in Salesforce is enforced through user permissions (UI and API), an org-wide Identity Verification setting, session security levels with High Assurance step-up, and login flows, and it is supported by strong verification methods such as Salesforce Authenticator, TOTP apps, security keys, and built-in biometrics. SMS and email are not valid MFA methods. Administrators manage MFA through permission sets, disconnecting methods, temporary verification codes, exemption permissions, and Identity Verification History. For the exam, focus on correctly matching each scenario to the specific permission, setting, or feature, distinguish MFA from device activation, and remember how SSO, API, and Lightning Login interact with the MFA requirement.