Identity Verification History
Identity Verification History is the Salesforce log capturing every identity verification attempt across the org.
Definition
Identity Verification History is the Salesforce log capturing every identity verification attempt across the org. Each row records the user, the verification method used (email code, SMS code, Salesforce Authenticator push, FIDO security key), the device and IP address, the timestamp, and the success or failure status. The log is the audit artifact for verification activity, alongside Login History (which captures every login attempt) and Identity Provider Event Log (which captures SSO events when Salesforce is the IdP).
The log appears under Setup > Identity > Identity Verification History. Retention follows standard Salesforce log retention; for longer horizons, Event Monitoring exports the data to an external SIEM. The log is read-only: events cannot be deleted or modified, only viewed and exported. Administrators use it for two main purposes: incident response when a verification-related anomaly arises, and adoption analytics to understand how often users encounter verification prompts and which methods they actually use.
What Identity Verification History captures
What each log row captures
Each Identity Verification History row contains: Username, Verification Type (Email, SMS, Authenticator, FIDO, etc.), Device (browser fingerprint), Login IP (the IP address from which verification was attempted), Login Geographic Location (derived from IP), Status (success, failure, expired, canceled), and Verified Date. Status codes distinguish specific failure modes: WrongCode (user entered the wrong verification code), Expired (code expired before submission), Canceled (user closed the prompt).
Successful verifications and trusted device creation
A successful verification entry typically corresponds to a new trusted device being added. The trust window applies from this timestamp; future logins from the same device within the trust period skip verification. The log entry is the audit trail of trust establishment: the timestamp shows when this device became trusted, the IP shows from where. Compare entries across a single user to see all trusted devices created over time.
Failure analysis
Failed verifications fall into categories. WrongCode failures are user errors (typo, expired code) and usually clear themselves up on the next attempt. Repeated WrongCode failures from the same user may indicate either confusion (user doesn't know which method to use) or an attack (someone trying to brute-force a code). Sudden Canceled clusters may indicate users abandoning verification due to UX friction or technical issues with the prompt rendering.
Cross-reference with Login History
Identity Verification History and Login History are separate logs. A login attempt may trigger verification (entry in Identity Verification History) and then succeed or fail (entry in Login History). For full incident response, query both: who attempted to log in, were they prompted for verification, did they succeed, did they ultimately log in. The two logs together tell the complete story; either alone is incomplete.
Adoption analytics use case
Beyond incident response, the log answers adoption questions. How many verifications per user per month? Which method dominates in your org? Are users abandoning verification (cluster of Canceled events)? Are office-network users hitting verification too often (sign of misconfigured Login IP Ranges)? Use the data to tune the user experience and reduce friction without weakening security.
Geographic analysis
The Geographic Location field surfaces where verification was attempted. Verifications from unexpected countries are an immediate flag for security investigation. Build a SIEM dashboard showing verification activity by country; clusters in unexpected regions indicate either travel anomalies (user on a business trip) or compromise attempts. Pair with the Login History geographic data for cross-validation.
Permissions and export
Viewing Identity Verification History requires View Setup and Configuration. Export to CSV is available through the standard list view export. For SIEM integration and longer retention, Event Monitoring is the path: enable the Identity Verification Event Type in Event Monitoring to stream the log to an external system. Compliance teams typically want both the in-Setup view (for ad-hoc review) and the SIEM export (for long-horizon audit).
Use Identity Verification History for audit and analytics
Working with Identity Verification History is mostly a periodic review and incident-response activity. The steps below cover the recurring tasks plus the SIEM integration setup.
- Open the log
Setup > Identity > Identity Verification History. Recent verification attempts appear in reverse chronological order.
- Filter to a specific user (incident response)
Use the column filter on Username to focus on a user under investigation. Cross-reference with Login History for the same user and time window.
- Look for failure patterns
Sort or filter by Status. Repeated failures from the same user, or clusters from a specific IP, warrant investigation.
- Build SIEM alerts
Through Event Monitoring, stream the log to your SIEM. Define alerts on patterns: 3+ failures per user in 10 minutes, verifications from new countries, repeated cancellations.
- Audit adoption metrics
Aggregate by Verification Type. Identify which methods are actually used; if email is dominant, encourage migration to Authenticator for security.
- Review office-network verification volume
High verification volume from corporate IPs suggests Login IP Ranges are not configured. Tune ranges to reduce friction on trusted networks.
- Document incident-response queries
For common investigation patterns, document the SOQL or filter recipe in the IR runbook. Repeated lookups are faster with a documented query.
Focus on a specific user for incident investigation.
Surface failed or canceled verifications for pattern analysis.
Aggregate by method to understand adoption.
Standard list view export for offline analysis or sharing with security teams.
Stream to external SIEM for long-horizon retention and real-time alerts.
- The log is read-only. Events cannot be deleted; only viewed and exported. Treat as durable audit artifact.
- Retention is limited without Event Monitoring. Compliance horizons usually require the SIEM export path.
- Successful verifications are most common; the log can be voluminous. Filter aggressively before scanning manually.
- Identity Verification History does not cover login outcomes. Pair with Login History for the complete login lifecycle.
- Geographic location is derived from IP and can be inaccurate for VPN users. Confirm location through the user before drawing conclusions in incident response.
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. Why is understanding Identity Verification History important for Salesforce admins?
Q2. What is the primary benefit of Identity Verification History for Salesforce administrators?
Q3. In which area of Salesforce would you typically find Identity Verification History?
Discussion
Loading discussion…