Login History and Identity Verification History

5 minutes 5 Questions

In Salesforce, Login History and Identity Verification History are two key auditing tools that help administrators monitor user access and security events, which is essential knowledge for the Platform Administrator II exam. Login History (Setup > Login History) records every login attempt to the org, both successful and failed, for the past six months. Each entry captures the username, login time, source IP address, login type (e.g., Application, Other Apex API, Remote Access), status (Success, Failed: Invalid Password, Failed: Login Lockout, etc.), browser, platform, application, client version, API type and version, login URL, and country/city derived from geolocation. Administrators can filter, sort, and download up to 20,000 records as CSV or GZIP for the last six months, or use Login Forensics and Event Monitoring for deeper analysis. Login History is invaluable for troubleshooting access issues, detecting suspicious activity such as repeated failed logins from unfamiliar IPs, verifying IP range restrictions, and demonstrating compliance. Note that login attempts blocked by network restrictions or outside login hours are also captured with corresponding status values. Identity Verification History (Setup > Identity Verification History) tracks identity confirmation events over the past six months, typically triggered by multi-factor authentication (MFA), device activation when logging in from an unrecognized browser or IP, or step-up authentication for sensitive actions. Each record shows the user, verification time, method (Salesforce Authenticator, SMS, email, security key, built-in authenticator, or one-time password), status (Succeeded, Failed, or Pending), activity triggered (e.g., Login, Connected App access), source IP, and location. Admins can filter and download up to 20,000 records. Together, these tools complement Setup Audit Trail and Field History Tracking, allowing administrators to audit who accessed the org, from where, how they authenticated, and whether security policies like MFA are functioning correctly.

Login History and Identity Verification History: Auditing Who Gets In and How They Prove It

Why This Topic Matters
Every security program starts with one basic question: who is accessing the org, from where, and did they succeed? Salesforce answers this through two closely related auditing tools: Login History and Identity Verification History. For an Advanced Administrator, these are the first places you look when a user reports they cannot log in, when a security team suspects credential misuse, or when an auditor asks you to prove that multi-factor authentication (MFA) is actually being enforced. On the Advanced Administrator exam, this content lives under the Auditing and Monitoring domain, and questions typically test whether you know which tool answers which question, what data each tool retains, and how long that data is kept.

What Login History Is
Login History is a record of every login attempt made to your Salesforce org, whether successful or not. You find it in Setup under Identity > Login History (or by searching "Login History" in Quick Find). It is also visible on an individual user's detail page under the Login History related list, which filters the data to that one user.

Each login record captures details such as:
• Username that attempted the login
• Login Time (in the viewing user's time zone)
• Source IP address
• Location (approximate geolocation derived from the IP, such as city, country, and sometimes region)
• Login Type (for example Application, Remote Access 2.0, SAML, Other Apex API, Salesforce for Outlook, Chatter Communities)
• Status (Success, Failed: Invalid Password, Failed: Computer Activation Required, Failed: Login Hours Restricted, Failed: IP Restricted, Failed: API Login Not Allowed, Failed: Password Lockout, and so on)
• Browser and Platform (operating system)
• Application (Browser, Salesforce Mobile, a connected app name, Data Loader, etc.)
• Client Version and API Type / API Version for API logins
• Login URL and HTTP Method
• TLS Protocol and TLS Cipher Suite
• Authentication Service ID (when SSO is used)
• Login Subtype and Login Flow information in newer releases

Retention and Export
Salesforce retains Login History for the last six months in the Setup UI. This is one of the most frequently tested facts. You can download the data as a CSV or GZIP file directly from the Login History page. If your organization needs data older than six months, you must either export it periodically, pull it from the LoginHistory object via the API (SOQL or Data Loader), or subscribe to Event Monitoring (part of Salesforce Shield or available as an add-on), which provides richer Login event log files and longer, more granular storage.

Filtering Login History
The Setup page lets you create filtered views on fields such as Username, Status, Login Type, Source IP, Browser, Platform, and Application. This is extremely useful in practice: for example, filtering Status to "Failed: Invalid Password" and sorting by Source IP can quickly reveal a brute-force attempt against a single account from a single address. You can also filter by Application to identify which users are still logging in with a legacy integration tool you are trying to retire.

Practical Troubleshooting Scenarios with Login History
• User says "I can't log in": Check their Login History related list. A status of Failed: Login Hours Restricted means their profile's login hours block them. Failed: IP Restricted means their IP is outside the profile's login IP ranges. Failed: Password Lockout means too many bad attempts; unlock the user from the user record. Failed: Computer Activation Required means the identity verification challenge was never completed.
• Security asks which integration still uses an old API version: Filter Login Type to API and review API Version.
• Suspicious activity: Look for successful logins from an unexpected Location or Source IP outside the user's normal pattern, especially at odd hours.
• Confirming TLS compliance: Review TLS Protocol to find clients still negotiating deprecated versions.

What Identity Verification History Is
While Login History answers "who tried to log in and did it work," Identity Verification History answers a more specific question: when a user was challenged to prove their identity beyond a password, how did they respond? It is found in Setup under Identity > Identity Verification History. It logs every identity verification attempt from the past six months, covering up to 20,000 records displayed in the UI (with the full set available via download or the VerificationHistory object).

Identity verification is triggered in several situations:
• Device activation: a user logs in from a new browser, device, or IP address not previously recognized, and Salesforce sends a verification code (email, SMS, authenticator app, or security key).
• Multi-factor authentication (MFA): the user's profile or permission set requires an additional verification factor on every login.
• Session security level step-up: a user with a Standard security session tries to access a resource that requires a High Assurance session (such as Reports and Dashboards, Connected Apps, or Setup pages, when configured under Session Settings).
• Resource-level policies: for example, requiring verification before changing an email address or exporting data when configured with Session Security Levels.

Each Identity Verification History record includes:
• Username
• Time of the verification attempt
• Verification Method: Email, SMS text message, Salesforce Authenticator, Time-based One-Time Password (TOTP app such as Google Authenticator), Security Key (U2F / WebAuthn), Built-in Authenticator (Touch ID, Windows Hello), or Temporary Verification Code
• Status: Succeeded, Failed, Pending, Expired, Automated (for Salesforce Authenticator automatic approvals based on trusted location), Denied, Sent, Resent, and so on
• Activity or Policy: what triggered the challenge, such as Login with MFA, Device Activation, Access to a High Assurance resource, or Connected App access
• Source IP and Location
• Login Geolocation details such as country and city
• Trigger information and Remarks describing the context

Why the Distinction Matters
Think of it this way: Login History tells you the outcome of an authentication attempt; Identity Verification History tells you the story of the second factor. A single login might produce one Login History row with Status = Success and one or more Identity Verification History rows showing that the user was challenged via Salesforce Authenticator and the request was approved. If an attacker steals a password but cannot pass MFA, Login History may show a failure, and Identity Verification History will show the Denied or Expired challenge, which is the proof that MFA stopped the attack.

Related Tools You Should Not Confuse With These
• Setup Audit Trail tracks configuration changes (who changed a profile, created a field, modified a validation rule) for the last 180 days. It does not track logins.
• Field History Tracking records changes to specific record field values. Not related to authentication.
• Session Management (Setup > Session Management) shows currently active sessions and lets you remove them; it is a live view rather than a historical log.
• Event Monitoring provides downloadable event log files (Login, Logout, API, Report Export, and dozens more) with far more detail and longer retention; it requires Shield or the Event Monitoring add-on.
• Login Forensics and Transaction Security Policies are Shield features that analyze login patterns and can block or alert on anomalous logins in real time.
• Identity Verification Settings under Session Settings control how verification works (which methods are allowed, whether to require MFA), whereas Identity Verification History is the log of what happened.

How It All Works Together in a Typical Login Flow
1. The user enters a username and password. If that fails, Login History logs a Failed status immediately and no verification is attempted.
2. If the password is correct, Salesforce evaluates profile Login Hours and Login IP Ranges. A violation is logged in Login History as the corresponding Failed status.
3. If the IP is not in a trusted range (Network Access) and the device is unrecognized, or if MFA is required, Salesforce issues an identity verification challenge. This creates an Identity Verification History record.
4. If the user passes the challenge, Login History shows Success, the device may be registered as activated, and the session is created at the appropriate security level (Standard or High Assurance depending on the method used).
5. If the user fails or ignores the challenge, Identity Verification History shows Failed, Denied, or Expired, and Login History may show Failed: Computer Activation Required.

Exam Tips: Answering Questions on Login History and Identity Verification History

Tip 1: Memorize the retention windows. Login History in Setup retains six months. Identity Verification History retains six months and displays up to 20,000 records. Setup Audit Trail retains 180 days. If a question asks about retaining data beyond these limits, the answer involves exporting (CSV/GZIP download, API extraction of the LoginHistory or VerificationHistory object) or Event Monitoring.

Tip 2: Match the question to the tool. If the scenario mentions who logged in, failed login, source IP, browser, API version, login type, the answer is Login History. If it mentions MFA, verification code, Salesforce Authenticator, device activation, high assurance, second factor, the answer is Identity Verification History. If it mentions who changed a setting or profile, the answer is Setup Audit Trail. If it mentions ending a user's current session, the answer is Session Management.

Tip 3: Know the Failed status meanings. Expect scenario questions like "A user in Chicago cannot log in from a hotel. Login History shows Failed: IP Restricted. What should the admin do?" The correct answer relates to the profile's Login IP Ranges, not to password resets or MFA. Similarly, "Failed: Login Hours Restricted" points to profile Login Hours, and "Failed: Password Lockout" points to unlocking the user and reviewing Password Policies.

Tip 4: Understand Network Access versus profile IP ranges. Trusted IP ranges under Network Access (Setup > Security > Network Access) skip the identity verification challenge for device activation but do not block logins. Profile Login IP Ranges actually block logins from outside the range. Exam questions often test this distinction indirectly by asking why a user is or is not being challenged.

Tip 5: Recognize where to find per-user data. The Login History related list on the user detail page is the fastest way to review a single user. The Setup Login History page is for org-wide analysis with filters and downloads.

Tip 6: Watch for "beyond standard capabilities" wording. When a question asks for real-time alerts on suspicious logins, blocking logins based on patterns, or retaining detailed login data for a year or more, the answer is Event Monitoring, Transaction Security Policies, or Shield, not standard Login History.

Tip 7: Remember that time zones matter. Login History times display in the time zone of the admin viewing them, which can cause confusion when comparing to a user's reported experience. A question may hinge on this detail.

Tip 8: Identify what verification methods exist. Be able to recognize Email, SMS, Salesforce Authenticator, TOTP authenticator apps, Security Keys, Built-in Authenticators, and Temporary Verification Codes as valid methods that will appear in Identity Verification History. Also know that an admin can generate a Temporary Verification Code for a user who has lost their device, and that this action is logged.

Tip 9: Eliminate distractors. Wrong answer choices often propose tools that sound plausible but are wrong, such as using Field History Tracking to see logins, using Setup Audit Trail to see failed passwords, or using Reports to query Login History directly (standard reports do not cover Login History; you need the API or Event Monitoring analytics apps). Rule these out quickly.

Tip 10: Think like an auditor. Many questions are framed as compliance requests: "The security team needs proof that all users are using MFA." The answer combines Identity Verification History (to see verification events) with user and permission set reviews. "Management wants a monthly report of all API logins" points to downloading or extracting Login History filtered by Login Type.

Summary
Login History and Identity Verification History are the two core, native Salesforce tools for understanding authentication activity. Login History records every login attempt with rich context such as IP, location, browser, application, API details, and a precise Status that explains failures. Identity Verification History records every MFA, device activation, and step-up verification challenge along with the method used and whether it succeeded. Both retain six months of data in Setup and can be downloaded or accessed via the API for longer retention, with Event Monitoring available for deeper analysis. Master the retention periods, the meaning of each Status value, the difference between these tools and Setup Audit Trail or Session Management, and the distinction between Network Access trusted IPs and profile Login IP Ranges, and you will be well prepared for any question the exam asks in this area.
Test mode:

Admin II - Login History and Identity Verification History Example Questions

Test your knowledge of Login History and Identity Verification History

Question 1

Which information does Identity Verification History in Setup provide that Login History records do not provide?

Question 2

At Northern Trail Outfitters, multi-factor authentication is not yet required. A sales rep reports a login she never made. Login History shows a successful login for her from an unfamiliar country. Identity Verification History shows that, moments earlier, a device activation challenge for her succeeded using an emailed code. Her profile has no login IP ranges, and no trusted network entry covers that address. What does this evidence indicate, and how should the administrator respond?

Question 3

At Cloud Kicks, the administrator turned on multi-factor authentication. The security team now wants to know which verification method each user completed when challenged, such as an authenticator app or an emailed code. It also wants to know which challenges failed. The administrator checked Login History, but it shows only login times, source IP addresses, and status. Which tool should the administrator use to get the details the security team needs?

More Login History and Identity Verification History questions
30 questions (total)