3.5 Identity, Login History, MFA, and Session Risk

Identity Comes Before Data Access

A user cannot reach object permissions, record sharing, reports, or Agentforce features until Salesforce accepts the login and creates a session. Identity troubleshooting starts with the user record. Is the user active? Is the username correct? Is the profile assigned? Is the user frozen? Has the password expired or been reset? Are login hours or login IP ranges blocking the attempt? Is single sign-on configured, and is the identity provider sending the expected assertion?

Profiles can include login hours and login IP ranges. Org-level Network Access can define trusted IP ranges. Session Settings can control timeout, session security level, and related behavior. Connected Apps can enforce policies for OAuth-based integrations. Permission sets and session-based permission sets may control access after a higher assurance session is established. These identity controls are related, but they are not the same as role hierarchy or sharing rules.

Login History As Evidence

Login History is an admin's first stop for many access tickets. It can show successful and failed attempts, timestamps, source IP, login type, browser or client details, platform, and failure messages. In Setup, search for Login History. For one user, you can also open the user record and inspect related login information where available.

Use Login History to verify the facts before changing settings. If the failure reason points to invalid password, resetting sharing is irrelevant. If the source IP is outside the profile's allowed range, changing a permission set will not help. If SSO is failing, compare Salesforce user federation identifiers, username mapping, certificate validity, identity provider policy, and connected app settings depending on the SSO model.

Login History is also useful after a fix. If a user says the issue remains, confirm whether they attempted a fresh login after the configuration change and whether the failure reason changed. Evidence prevents circular troubleshooting.

MFA And Identity Assurance

Multi-factor authentication adds proof beyond username and password. Salesforce administrators should understand approved MFA methods in the org, enrollment status, recovery procedures, and how MFA interacts with SSO or an external identity provider. The correct support response to an MFA problem is usually to verify enrollment, reset or reconnect the approved verification method, review identity provider policy, or apply an approved temporary access process. It is not to grant broader data permissions.

MFA is sometimes enforced outside Salesforce by the organization's identity provider. In that case, the Salesforce admin still needs enough context to route the ticket. If SSO is the only login path, a user who cannot satisfy MFA may need help in the identity provider. If Salesforce Authenticator or another Salesforce-supported method is used directly, the admin may work from Salesforce setup tools and policy.

Do not promise that one MFA configuration is always current for every org. Administrators should verify the org's current Salesforce security settings, identity provider standards, and company policy. Certification study should focus on the decision logic: MFA raises login assurance; it does not grant record access, field visibility, or object CRUD.

Session Risk And Policy

A session is the authenticated connection Salesforce trusts for a period of time. Session risk controls include timeout, locking sessions to IP address, requiring secure connections, high assurance session requirements, and connected app session policies. Some actions can require a high assurance session, meaning the user must satisfy stronger authentication before using the feature.

Session troubleshooting asks four questions:

1. Did the correct user authenticate?
2. Did the login come from an allowed network, device, app, and time?
3. Did the session meet the required assurance level for the action?
4. Did the session expire, get revoked, or fail because of connected app policy?

Scenario: A finance admin logs in successfully but cannot access a sensitive setup feature until completing an additional verification step. That points to session assurance, not record sharing. Scenario: A sales rep can log in from the office but fails from a hotel network with an IP restriction message. That points to login IP policy, not field-level security.

Admin Support Workflow

Use this workflow for login and identity tickets:

1. Confirm the user's exact username and whether the user is active or frozen.
2. Ask for timestamp, location, network, client, and screenshot of the error when policy allows.
3. Review Login History for the matching attempt.
4. Check profile login hours and login IP ranges.
5. Check org Network Access and Session Settings if the symptom is network or session related.
6. Check SSO, connected app, and identity provider settings if the login type is federated or OAuth.
7. Check MFA enrollment, device change, recovery, and high assurance requirements.
8. Apply the narrowest approved fix and require a fresh login test.
9. Document evidence and any security exception.

This workflow is safer than changing several settings at once. If you reset a password, relax IP ranges, and assign a permission set together, you may close the ticket but never learn which control mattered. On an exam, that creates the same problem: broad answer choices may sound helpful but fail the specific symptom.

Exam Traps

Authentication and authorization are different. Authentication proves who the user is and whether the session is trusted. Authorization decides what the user can do after login. Login History is about login events, not every record access decision. Role hierarchy does not fix password or MFA failure. Permission sets do not bypass login hours. OWD does not change trusted IP ranges.

Also be careful with integration users. Connected apps, API access, OAuth policies, profile restrictions, MFA or high assurance requirements, and user status can all affect integrations. A good admin uses dedicated integration users or named principals according to company policy, assigns least privilege, monitors login activity, and avoids sharing personal credentials.