Session Settings and High-Assurance Sessions

Why Session Settings and High-Assurance Sessions Matter

Authentication proves who a user is at the moment they log in. A session is what keeps that user authenticated afterward, often for hours. If an attacker hijacks a session cookie, walks up to an unattended laptop, or exploits a long-lived session, the strongest password policy in the world is irrelevant. That is why Session Settings sit at the heart of the Advanced Security and Access domain of the Salesforce Advanced Administrator exam. They control how long a session lives, where it can be used, how it is protected against web attacks, and, most importantly for the exam, how Salesforce decides whether a session is trustworthy enough to reach sensitive data such as reports, dashboards, connected apps, and critical Setup pages.

In the real world, this knowledge lets an admin satisfy compliance requirements (for example, forcing a second factor before anyone exports financial reports) without forcing every user through MFA on every single login. On the exam, it lets you distinguish between a password problem, an IP restriction problem, and a session security problem, which are frequently mixed together in scenario questions to test whether you understand the difference.

What Session Settings Are

Session Settings are found at Setup > Security > Session Settings. The page is organized into several groups:

1. Session Timeout
The Timeout value sets how long a session can remain idle before Salesforce ends it. Options range from 15 minutes to 24 hours, with the default being 2 hours. Two companion checkboxes refine the behavior:
- Disable session timeout warning popup: normally users see a warning before timeout and can click to extend the session. Checking this removes the warning.
- Force logout on session timeout: when the session expires, the user is fully logged out and returned to the login page rather than being left on a stale screen.

Remember that the org-wide timeout can be overridden on a profile (Profile > Session Settings). A profile-level timeout always takes precedence over the org-level value, which lets you give contact center agents a long session while giving executives who view sensitive data a short one.

2. Session Settings (Locking and Transport)
- Lock sessions to the IP address from which they originated: the session cookie only works from the IP address where the login occurred. This is strong protection against cookie theft but can break access for mobile users or anyone behind load-balanced proxies whose IP changes mid-session.
- Lock sessions to the domain in which they were first used: ties the session to the domain it was created in (for example, your My Domain), which helps prevent cross-domain session reuse.
- Require secure connections (HTTPS): always enabled in modern orgs.
- Force relogin after Login-As-User: after an admin uses Login As to troubleshoot, they must log in again rather than being dropped back into their own session.
- Require HttpOnly attribute: prevents JavaScript from reading the session cookie, mitigating XSS-based session theft.
- Use POST requests for cross-domain sessions: avoids exposing session IDs in URLs.
- Enable caching and autocomplete on login page and Enable secure and persistent browser caching: convenience versus hardening trade-offs.
- Enable user switching: lets users switch between multiple Salesforce accounts from the profile menu.
- Let users use a security key (U2F/WebAuthn) and Allow location-based automated verifications with Salesforce Authenticator: identity verification conveniences.

3. Browser Protection Settings
Clickjack protection (for Setup pages, non-Setup pages, Visualforce pages, and customer-facing sites), CSRF protection on GET and POST requests, Content Sniffing protection, and XSS protection. These are mostly best-practice toggles; the exam expects you to recognize that clickjack protection can be relaxed only for specific Visualforce or Lightning pages that must be framed by an external application.

4. Identity Verification
Options such as Require identity verification for change of email address, Let users verify their identity by text (SMS), and settings that control when users are challenged for a verification code, for example on login from an unrecognized browser or device (device activation).

5. Session Security Levels
This is the section that defines Standard versus High Assurance sessions and is the single most tested concept in this topic.

6. Session Security Level Policies
Where you declare which resources demand a high-assurance session.

7. Lightning Login
Allow Lightning Login and Require permission to log in with Lightning Login. Lightning Login is password-free login via Salesforce Authenticator and is treated as high assurance.

What a High-Assurance Session Is

Every Salesforce session carries a security level, which is simply a label reflecting how confident Salesforce is in the identity behind that session. There are exactly two levels:

- Standard: the default level for most login methods.
- High Assurance: a session established with a stronger form of authentication.

In the Session Security Levels section of Session Settings, each login method is placed in one of two columns, and the admin can drag methods between them. The default mapping is:

Standard: Username and Password, Delegated Authentication, Activation (device verification), Lightning Login is NOT here, SAML/Single Sign-On, Authentication Provider (social sign-on), Passwordless Login.

High Assurance: Multi-Factor Authentication (Two-Factor Authentication) and Lightning Login.

A classic exam twist: SSO via SAML is Standard by default, even if your identity provider performs its own MFA. If the company wants SAML logins to count as high assurance, the admin must move SAML into the High Assurance column, or require MFA inside Salesforce in addition to SSO.

How It Works: Requiring and Raising Session Level

There are two distinct ways high assurance is enforced, and the exam expects you to know both.

Method 1: Require High Assurance at Login (Profile Level)
On a profile, under Session Settings, the field Session Security Level Required at Login can be set to None or High Assurance. If set to High Assurance and the user logs in with a Standard method such as username and password, Salesforce immediately prompts them to complete identity verification (MFA) before the session is created. This is the heavy-handed option: every login for that profile requires the stronger factor.

Method 2: Step-Up Authentication for Specific Resources (Session Security Level Policies)
This is the more elegant and more frequently tested approach. In Session Settings, under Session Security Level Policies, resources such as Reports and Dashboards and sensitive Setup functions (managing encryption keys, password policies, login access policies, IP addresses, profiles and permission sets, roles, sharing, users, certificates, and MFA in the API) can each be set to:

- None: no special requirement.
- Raise session to high assurance: when a user with a Standard session tries to reach the resource, Salesforce steps up by prompting them to verify their identity (for example, approve in Salesforce Authenticator or enter a TOTP code). Once verified, the entire session is elevated to High Assurance and the user is not challenged again for the rest of that session.
- Block: users with a Standard session simply cannot access the resource at all in that session; they would need to log out and log in with a High Assurance method.

The same concept applies to Connected Apps. On the connected app's Manage page, under Session Policies, the High assurance session required option forces step-up verification when the app is accessed with a Standard session.

For step-up to work, the user must have an identity verification method registered (Salesforce Authenticator, a third-party TOTP authenticator app, a security key, or, if allowed, SMS or email). If a user has nothing registered, they are walked through registration on first challenge.

Related Tools You Should Connect to This Topic

- Session Management (Setup > Security > Session Management): lists all active sessions with user, session type (UI, API, OAuth, etc.), login type, source IP, and security level. An admin can select sessions and click Remove to terminate them immediately, for example when an employee is terminated or a device is lost.
- Login History and Identity Verification History: audit who verified, when, and by what method.
- Login Flows: can add custom steps or extra verification during login but are not the mechanism for high-assurance session levels.
- Password Policies, Login Hours, and Login IP Ranges: often confused with Session Settings. These govern whether and when a user can log in; Session Settings govern what happens after login.
- Multi-Factor Authentication for User Interface Logins permission: when assigned via profile or permission set, every UI login requires MFA, which produces a High Assurance session by default.

Exam Tips: Answering Questions on Session Settings and High-Assurance Sessions

Tip 1: Identify which layer the scenario is about. If the question mentions idle time, lost laptops, cookie theft, or users staying logged in too long, the answer lives in Session Settings. If it mentions complexity, expiration, or lockout, it is Password Policies. If it mentions location or office hours, it is Login IP Ranges or Login Hours. Eliminating the wrong layer usually removes two distractors instantly.

Tip 2: Know the step-up keywords. Phrases such as only when accessing, without requiring MFA on every login, sensitive reports, before viewing dashboards, or additional verification for a connected app point to Session Security Level Policies set to Raise session to high assurance, not to the profile-level login requirement. If the scenario says all users in the Finance profile must always, then choose Session Security Level Required at Login = High Assurance on the profile.

Tip 3: Remember the default mappings. MFA and Lightning Login are High Assurance by default. Username and password, SSO (SAML), Authentication Providers, delegated authentication, passwordless login, and device activation are Standard by default. A favorite question describes users logging in through SSO who are unexpectedly challenged when opening reports; the correct explanation is that SAML is Standard and the reports policy requires High Assurance, and the fix is either to move SAML to High Assurance or accept the step-up.

Tip 4: Raise versus Block. Raise prompts for verification and then grants access; Block denies access for the duration of a Standard session. If the question wants users to still get in after proving identity, choose Raise. If it says the resource must never be reachable from a Standard session, choose Block.

Tip 5: Profile overrides org for timeouts. When a question says most users need 8 hours but one group needs 30 minutes, the answer is to leave the org default and set the shorter timeout on that group's profile. Never pick an answer that suggests permission sets control session timeout; they do not.

Tip 6: Watch for the IP-locking trap. If a scenario describes mobile or traveling users being logged out randomly or unable to stay connected, suspect Lock sessions to the IP address from which they originated. It is a security feature, but it is the wrong choice for users whose IP changes mid-session.

Tip 7: Terminating sessions is done in Session Management. Deactivating a user or resetting a password are valid actions, but when the question specifically asks how to immediately end an existing active session (for instance, a stolen device), the precise answer is to remove the session from Session Management.

Tip 8: Login-As hygiene. If the question concerns administrators remaining logged in as themselves after using Login As, or wanting admins to re-authenticate afterward, the setting is Force relogin after Login-As-User.

Tip 9: Connected apps have their own policy. A high-assurance requirement for a single integration or mobile app is configured on the connected app's session policies, not in org-wide Session Settings. Choose the connected app answer when the scope is one app.

Tip 10: Read for scope and least disruption. Salesforce exam answers favor the solution that meets the requirement with the least impact. Forcing MFA on every login when the requirement only concerns dashboards is technically possible but is a distractor; the step-up policy is the intended answer. Conversely, if the requirement explicitly says every login, do not choose a resource-specific policy.

Quick Reference Summary
- Session Settings: Setup > Security > Session Settings; timeout 15 min to 24 hrs, default 2 hrs.
- Profile session timeout overrides org timeout.
- Two security levels: Standard and High Assurance.
- High Assurance by default: MFA and Lightning Login. Everything else is Standard, including SSO.
- Admins can reassign login methods between levels by dragging.
- Enforce at login: Profile > Session Security Level Required at Login.
- Enforce per resource: Session Security Level Policies (None, Raise, Block) for Reports and Dashboards and sensitive Setup areas.
- Enforce per integration: Connected App > Session Policies > High assurance session required.
- Once raised, the session stays High Assurance until it ends.
- Session Management lets admins view and remove active sessions.

Master these distinctions and you will be able to answer virtually any Session Settings or High-Assurance question on the Advanced Administrator exam by asking three questions: What layer is this (login rule, password rule, or session rule)? What scope is this (org, profile, resource, or app)? And does the requirement call for a challenge, a block, or a timeout?