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.