Identity Verification
Identity Verification is the Salesforce platform's mechanism for confirming that the person logging in is actually the user the account belongs to, going beyond just username and password.
Definition
Identity Verification is the Salesforce platform's mechanism for confirming that the person logging in is actually the user the account belongs to, going beyond just username and password. The platform requires identity verification under several scenarios: first login from a new device or IP address, login from a previously unverified location, and any access that risk signals flag as suspicious. The verification step typically asks the user to enter a code sent to their registered email or phone, or to use the Salesforce Authenticator app or a registered FIDO security key.
The feature is the platform's adaptive authentication layer, separate from but related to mandatory Multi-Factor Authentication (MFA). MFA is the prompt that requires a second factor on every login (or every session). Identity Verification is the prompt that appears when the platform detects something different about this specific login attempt. Both work together: an org with mandatory MFA may still trigger Identity Verification challenges when a known user logs in from a brand-new device, because MFA satisfies one risk signal but device unfamiliarity is a different signal.
How Identity Verification protects login attempts
When Identity Verification triggers
The platform triggers verification under specific risk signals. First login from a new IP address (unfamiliar location). First login from a new device or browser (unfamiliar fingerprint). Login after a long gap (the platform has not seen this user in some time). Access from an IP address flagged as suspicious by Salesforce threat intelligence. Each trigger is configurable in part through Login IP Ranges and trusted IP settings; the unfamiliar-device trigger is always on for non-trusted IPs.
Verification methods
Several verification methods exist. Email: a code is sent to the user's registered email; user enters the code into the prompt. SMS: a code is sent to the registered phone. Salesforce Authenticator: a push notification fires to the user's registered phone; user approves or denies. FIDO security key: user inserts and touches a YubiKey or similar registered key. Each method has its own enrollment process; users select which methods they want to register through Personal Settings.
Identity Verification versus MFA
The two features are related but distinct. MFA is the requirement to provide a second factor on every login (or session, depending on configuration). Identity Verification is the adaptive challenge that appears on suspicious login attempts. An org with mandatory MFA may still see Identity Verification prompts; an org without MFA still sees Identity Verification because it is on by default. The features layer: MFA establishes baseline security, Identity Verification responds to risk signals.
Configuration in Identity Verification Settings
The Setup > Identity > Identity Verification Settings page controls verification behavior. Administrators can adjust which methods are allowed, what triggers a verification prompt, how long a verified device remains trusted, and which user populations are affected. Most orgs leave defaults in place; specific industries (finance, healthcare) may tighten settings beyond default.
The trusted device concept
After successful verification, the platform marks the device as trusted for a period defined in settings (default 7 days; configurable). During the trust window, the same device does not trigger new verification prompts. The trust is per-device-per-browser; clearing cookies or using a different browser produces a new untrusted device. For users who hot-desk or use multiple browsers, frequent verification prompts are expected and worth communicating before MFA rollout.
Verification history
Every verification attempt produces a log entry in Identity Verification History (Setup > Identity > Identity Verification History). The log captures the user, the verification method used, the IP address, the device, and the success or failure status. Use this log for incident response (was there a flurry of failed verifications before an account compromise?) and for adoption analytics (how often are users hitting verification prompts?).
Common failure modes
Users on a trip without their registered phone cannot complete SMS-based verification. Users with email-only verification lose access if the registered email is unavailable. The recovery path is admin-triggered: the admin can reset verification on the User record, allowing the user to re-enroll. For organizations with traveling users, ensure multiple verification methods are registered to avoid lockouts. Salesforce Authenticator works offline once enrolled (it uses TOTP) but the initial enrollment requires connectivity.
Roll out Identity Verification
Identity Verification works out of the box; configuration is mostly about choosing methods and trust windows. The steps below cover the rollout and the user-facing setup.
- Review Identity Verification Settings
Setup > Identity > Identity Verification Settings. Confirm allowed methods (email, SMS, Authenticator, FIDO), trust window, and any user-population restrictions.
- Decide on MFA enablement
Identity Verification works regardless of MFA. If MFA is not already on, plan its enablement; MFA is the baseline, Identity Verification is the adaptive layer.
- Communicate to users
Send rollout communication explaining what verification looks like, why it appears, and how to register multiple methods. Without this, users assume each prompt is suspicious.
- Train users to register multiple methods
Personal Settings > Advanced User Details > Identity Verification. Users register Salesforce Authenticator (recommended), plus a backup method (email or SMS). Single-method users get locked out.
- Configure Login IP Ranges if appropriate
For trusted office networks, set Login IP Ranges per profile. IPs in the range skip verification, reducing prompts for in-office users.
- Monitor Identity Verification History
Schedule a weekly review of failed verifications. Patterns reveal misconfigured users or active attacks.
- Document the admin reset process
Write down the steps to reset a user's verification when they lock themselves out. Include in the IT runbook so the help desk can resolve quickly.
Code sent to registered email. Lowest friction; requires email access at login time.
Code sent to registered phone. Common, requires cellular connectivity at login.
Mobile app with push notifications. Strongest user-friendly method.
Hardware key. Strongest security; requires physical key.
How long a verified device stays trusted. Default 7 days; configurable.
- Identity Verification and MFA are different features. Enabling one does not enable the other; understand which is which when planning rollout.
- Single-method users get locked out when their registered device is unavailable. Train users to register multiple methods.
- Cookie clearing or switching browsers produces a new untrusted device. Trust window applies per-device-per-browser; communicate this to avoid surprise.
- Login IP Ranges skip verification for specified IPs. Over-permissive ranges weaken security; trust only known-good corporate networks.
- Admin reset of verification is an audit-able action. Document each reset with the requesting user and reason; an unaudited reset path is a security weakness.
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. Can a Salesforce admin configure Identity Verification without writing code?
Q2. Why is understanding Identity Verification important for Salesforce admins?
Q3. In which area of Salesforce would you typically find Identity Verification?
Discussion
Loading discussion…