Identity Verification History
Identity Verification History is the Salesforce log that records every attempt your users make to verify their identity beyond a password.
Definition
Identity Verification History is the Salesforce log that records every attempt your users make to verify their identity beyond a password. Each entry captures who attempted verification, what they were trying to do, the method used (such as Salesforce Authenticator, an email code, a one-time SMS code, or a security key), the source IP and geographic location, the date, and whether the attempt succeeded or failed. The same data is exposed as the VerificationHistory object in the API, which holds the past six months of attempts.
You reach it under Setup by searching for Identity Verification History. The view is read only, so rows cannot be edited or deleted, only viewed and exported. Admins lean on it for two jobs. The first is incident response when a verification anomaly shows up. The second is adoption analysis: seeing how often people hit a verification prompt and which method they actually pick.
Reading the verification trail end to end
What each entry records
Every row answers a few plain questions: who, what, where, how, and did it work. The User column names the person. The User Activity field (Activity in the API) describes what they were doing that triggered the prompt, with values such as Login, AccessReports, ConnectToopher (connecting Salesforce Authenticator), and ConnectU2F (registering a security key). The Triggered By field (Policy in the API) names the setting that forced verification, for example DeviceActivation when someone signs in from an unrecognized browser or a new IP. The Method column records how the user proved their identity, and the Status column says whether it passed. Source IP and the derived geographic location pin down where the attempt came from. The verification date and time stamp it. Read together, one row tells you that a named user, doing a named activity, was challenged by a named policy, answered with a named method, from a named place, at a named time, and either cleared the check or did not. That is the full shape of a single identity event, and it is why the log is the canonical record for verification activity.
Successful checks and device trust
A passing entry usually marks a moment of trust being established. When DeviceActivation triggers a challenge and the user answers correctly, Salesforce can treat that browser as recognized going forward. The successful row is the audit trail for that decision: the timestamp shows when the device became trusted, and the source IP shows from where. If you line up the passing entries for one user over time, you get a picture of every device and location that has cleared verification for them. This matters during access reviews. Say a user reports a lost laptop. You can scan their history for the devices and IPs that have passed verification, then decide which sessions or trusted devices to revoke. The log will not revoke anything for you, but it tells you exactly what to act on. It also helps explain why a given login did not prompt for verification: if the device already cleared a recent check, the next sign-in from it can skip the prompt within the trust window your settings allow.
Reading failures and abandoned prompts
Failed and incomplete attempts are where the security value lives. A wrong-code failure is often harmless, a typo or a code that expired before the user pasted it, and it usually clears on the next try. The signal you care about is volume and pattern. Several failed attempts in a few minutes against one user can mean genuine confusion about which method to use, or it can mean someone is guessing at codes. The log gives you the raw events; your judgment, plus context from other logs, tells you which it is. Abandoned prompts are the other tell. A cluster of canceled or unfinished checks can point to user-experience friction, a method people no longer have access to, or a rendering problem with the prompt on a particular browser. If you see the same user repeatedly starting and dropping verification, that is worth a direct conversation before it becomes a support ticket. Treat repeated failures from a single account, especially paired with an unfamiliar location, as a prompt to investigate rather than a number to ignore.
Pairing it with Login History
Identity Verification History and Login History are two different logs, and each tells half the story. A sign-in can trigger a verification challenge, which lands in Identity Verification History, and then the login itself succeeds or fails, which lands in Login History. Reading only one leaves a gap. To reconstruct an incident properly, you want both: did the person attempt to log in, were they challenged to verify, did they pass the challenge, and did the login ultimately go through. In practice you join the two on the user and a tight time window. Identity Verification History tells you the verification answered correctly from a given IP at a given second. Login History confirms whether a session was actually created and from where. When the two disagree, for example a verification passed but no matching successful login appears, that mismatch is itself a clue worth chasing. Keep both open side by side during any verification-related investigation, because the combined timeline is far harder to misread than either log alone.
Adoption and friction analysis
The log is not only a security tool. It also answers operational questions about how verification feels for your users. Count attempts per user per month and you learn whether people are getting challenged constantly or rarely. Group by method and you see which option actually dominates in your org, which tells you where to focus training and where a method might be safe to retire. A run of canceled entries hints that something in the flow is annoying enough that people give up. One common finding is office staff getting challenged far more than expected. That pattern usually points back to a settings problem rather than a security need, such as Login IP Ranges that do not cover the corporate network or a setting that re-verifies too aggressively. Before you loosen any verification control, read the history first. The data often shows the friction is concentrated in a few activities or a few locations, which means a targeted fix rather than a blanket change that would weaken protection for everyone.
Geographic signals
The geographic location, derived from the source IP, is one of the fastest fields to scan for trouble. Verification attempts from a country where you have no users stand out immediately. They might be benign, such as an employee verifying while traveling, or they might be an early sign of an attempted account takeover. Either way, the location field turns a wall of rows into a map you can reason about. A practical approach is to build a view or an external dashboard that buckets verification activity by country and flags anything outside your expected regions. Pair it with the geographic data in Login History so you are cross-checking two independent records rather than trusting one. Sudden activity from a new region against an account that also shows failed attempts is a stronger signal than either fact alone. Geography will not tell you intent, but it narrows a long list down to the handful of events a human should actually look at.
API access, export, and longer retention
Viewing the page in Setup requires the View Setup and Configuration permission. The same six months of data is available programmatically as the VerificationHistory object, supported in API version 36.0 and later, so you can pull it with SOQL for reporting or feed it into your own tooling. That makes scheduled checks and custom dashboards straightforward without anyone clicking through Setup. Retention is the catch. The standard history covers a rolling six-month window, which is fine for recent investigations but short for many compliance programs. For a longer horizon, the path is event monitoring. The IdentityVerificationEvent platform event, available in API version 47.0 and later, stores verification events and can stream them to an external system, which is how teams keep years of audit data outside the org. Compliance functions usually want both: the in-Setup view for quick ad hoc review, and the streamed export for long-term retention and SIEM correlation.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Identity Verification History.
Hands-on resources to go deeper on Identity Verification History.
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 each row in the Identity Verification History log record?
Q2. A status of WrongCode in Identity Verification History most directly indicates what?
Q3. Why pair Identity Verification History with Login History during an incident investigation?
Discussion
Loading discussion…