Identity Verification Settings
Identity Verification Settings is the Salesforce Setup page that controls how and when users prove who they are during login.
Definition
Identity Verification Settings is the Salesforce Setup page that controls how and when users prove who they are during login. It lives under Setup, in the Identity Verification node, and it applies to both your internal org and any Experience Cloud sites. From this one page an admin decides which verification methods are available, how one-time passcodes behave, whether email and SMS verification are allowed, and how device activation challenges work.
The page does not authenticate anyone by itself. It sets the rules that the login pipeline reads when a sign-in looks unfamiliar, such as a new browser or an IP address Salesforce has not seen for that user. Get it right and people verify only when the risk warrants it. Get it wrong and you either prompt trusted users too often or let risky logins through with too little proof.
What this page actually controls
Where it sits and who it covers
You reach the page from Setup by typing Identity in the Quick Find box and selecting Identity Verification. The settings span two audiences at once. The top sections govern internal org users, the people on Profiles inside your production org. Separate sections govern external Experience Cloud site users, your customers and partners. Keeping the two groups visually distinct matters because the right policy differs. Employees can be held to phishing-resistant methods without much friction. External users often need gentler options like SMS, because forcing every customer onto a security key would tank adoption. The page is org-wide in scope. There is no per-Profile copy of it. That single-control-plane design is convenient, but it means a change here lands on everyone in the relevant audience at once. Treat edits as production changes. Note the current state before you touch anything, change one setting at a time, and confirm a real login still works afterward. A careless toggle can lock out an entire population on their next sign-in from an unrecognized device.
The verification methods you switch on
Salesforce supports four method families for multi-factor authentication and device activation, and this page is where you decide which ones your users may register. Built-in authenticators use the platform biometrics already on a laptop or phone, such as Touch ID or Windows Hello. Security keys are physical FIDO devices like a YubiKey. Salesforce Authenticator is the free first-party mobile app that sends a push notification. Third-party authenticator apps cover any TOTP-compatible option such as Google Authenticator or Authy. Salesforce calls built-in authenticators and security keys the phishing-resistant methods, and the documentation recommends steering users toward them. The reason is simple. A push approval or a typed code can be socially engineered or relayed by an attacker in real time. A bound FIDO credential cannot, because it only responds to the genuine domain. The method list you enable here becomes exactly what users see when they enroll in Personal Settings. If you never enable security keys here, no user can register one, no matter how much they want to.
Email and SMS verification, and why they are weaker
Beyond the four MFA method families, the page exposes email and SMS identity verification. These are not accepted as standalone MFA factors under Salesforce's MFA requirement, but they still serve a role in device activation. When a user signs in from an unrecognized browser or IP, Salesforce can send a one-time passcode to their verified email address or, where supported, to their mobile number by SMS. The user types the code to clear the challenge. Both channels are convenient and both are weaker than a bound authenticator. An email inbox can itself be compromised, and SMS can be intercepted or SIM-swapped. SMS as a verification method is aimed mainly at external Experience Cloud users and is limited to a published list of supported countries, so it is not a universal answer. A common tightening for internal users is to lean on email and SMS only for device activation, while requiring a real authenticator or security key for the MFA step. The page also lets you require that users hold a verified email address at all, which closes a quiet gap where a passcode would otherwise have nowhere to land.
Device activation and the trusted-device idea
Device activation is the challenge a user meets when they log in from a browser or IP address Salesforce does not recognize for them. It is the everyday face of identity verification. Clear that challenge with a registered method and Salesforce records the browser as activated, so the same person on the same browser is not re-prompted on every visit. Switch browsers, switch machines, or clear cookies and the recognition resets, which is why people sometimes see a fresh challenge after a device wipe. This is the behavior most help-desk tickets are really about. Users do not say device activation, they say the system keeps asking me for a code. Understanding that the prompt is driven by an unfamiliar browser-and-IP signal, not by a random timer, lets you give accurate answers. The settings on this page tune how that activation flow looks: which methods can clear it, how one-time passcodes are formatted, and whether email and SMS are in play. The page covers device activation for both standard orgs and Experience Cloud sites in separate sections.
One-time passcode behavior and how it relates to MFA
The page includes controls for how one-time passwords behave, including their format and validity. Email and SMS one-time passcodes were lengthened in past releases to raise the cost of guessing, and the OTP behavior section is where that style of policy is surfaced. These codes apply to the email and SMS channels, not to push approvals or FIDO, which carry their own cryptography. It helps to separate two related but distinct features. MFA is the requirement that every interactive login present a second factor, configured through the Multi-Factor Authentication Assistant and Session Settings. Identity verification is the adaptive layer that challenges a login when it looks unfamiliar. They overlap because both draw on the same registered methods, and on this page you are mostly defining the menu of methods plus the email and SMS fallbacks that both features consume. An org with MFA fully enabled still relies on these settings to decide how a first-time-device challenge is satisfied. Configure the method list here first, then turn on MFA, so users already have a factor registered when the requirement bites.
Enrollment, lockout, and recovery
Switching a method on here only makes it available. Users still have to enroll. They register their chosen methods through Personal Settings, under Advanced User Details, in the identity verification area. The strong recommendation is to register more than one method. A person who only registered Salesforce Authenticator and then loses their phone has no way through the next challenge, and that becomes a support call. For those lockouts, an admin disconnects the user's registered methods from the User detail page, after which the user re-enrolls on their next login. Admins can also generate a temporary verification code from the same page to get a stuck user in for a short window. Both actions are sensitive and should be logged. Record who asked, who performed the reset, and why, and bake the steps into the help-desk runbook so resolution is quick and consistent. The same page links out to the flows for helping users register and for disconnecting lost devices, so the recovery path lives right next to the configuration it depends on.
Configure Identity Verification Settings
Use this flow to set which methods your users can register and how device activation challenges behave. Change one section at a time and verify a real login before moving on. Settings here apply org-wide to the relevant audience, so there is no undo by Profile.
- Open the page
From Setup, type Identity in the Quick Find box and select Identity Verification. Confirm you are looking at the right org and note the current state of each section before editing.
- Choose the allowed methods
In the method sections, enable the verification methods you want available. Favor built-in authenticators and security keys for internal users because Salesforce treats them as phishing-resistant. Keep email and SMS as device-activation fallbacks rather than primary factors.
- Set external user options separately
Scroll to the Experience Cloud site sections and decide method availability for external users on their own terms. Enable SMS only if your audience is in a supported country and you accept that it is weaker than an authenticator.
- Require a verified email and save
Turn on the option to require a verified email address so one-time passcodes always have a destination, then save. Sign in from a fresh browser session to confirm the challenge behaves as intended.
The set of MFA-grade methods you let users register: built-in authenticators, security keys, Salesforce Authenticator, and third-party authenticator apps.
Allows a one-time passcode to be sent to the user's verified email during a device activation challenge. Convenient but weaker than an authenticator.
Sends a passcode by text, aimed mainly at external Experience Cloud users and limited to supported countries.
Governs the format and handling of email and SMS passcodes used to clear challenges.
Ensures every user has a confirmed email on file so email-based verification can actually reach them.
- The page is org-wide, not per-Profile. A change lands on the whole relevant audience at their next unfamiliar login.
- Email and SMS are not valid standalone MFA factors under Salesforce's MFA requirement. Use them for device activation, not as your only second factor.
- Enabling a method here does nothing until users enroll it in Personal Settings. Communicate the rollout before tightening.
- Device activation resets when a user switches browsers or clears cookies, so expect a fresh challenge after a device wipe.
Prefer this walkthrough as its own page? How to Identity Verification Settings in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Identity Verification Settings.
Hands-on resources to go deeper on Identity Verification Settings.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does the Identity Verification Settings page control?
Q2. What is the trade-off when an admin shortens the trusted device duration in Identity Verification Settings?
Q3. How does an admin recover a user locked out because they lost access to every registered verification method?
Discussion
Loading discussion…