Session Validation Context: The Security Layer You're Probably Missing

[Sandeep_Know24]

Session Validation Context

The Security Layer You're Probably Missing

The Blind Spot in Your Adaptive Authentication Setup

If you've configured Adaptive Authentication on your ServiceNow instance, you've likely set up Pre-Auth policies for IP filtering, Post-Auth policies for role and group-based access, and maybe even Account Recovery Context (ACR) for SSO break-glass scenarios. That's solid — more than most organizations have in place.

But here's the catch, after a user logins and establishes a session, the platform trusts it until timeout or logout. If an attacker steals a session cookie — through an XSS exploit, a man-in-the-middle attack on public Wi-Fi, or browser malware — they can replay that cookie from a completely different network. Your authentication policies won't fire again. They've already done their job.

⚡ This is session hijacking, and it's the exact gap that Session Validation Context (SVC) closes. SVC complements Post Authentication context.

SVC extends the Adaptive Authentication framework from a one-time login check into continuous session monitoring — allowing security policies to be evaluated continuously throughout a user session, not just at login.

Whether you're a security admin hardening your instance, a platform architect designing access controls, or an IT leader evaluating your ServiceNow security posture — this post will walk you through the concepts, configuration, and practical advice to get started.

---

Zero Trust Principles: Why One-Time Checks Aren't Enough

Zero Trust rejects the traditional "trust but verify" model. Instead, it operates on three foundational principles that translate directly into how Session Validation Context is designed:

🔒 Least Privilege Access

Users receive only the minimal access necessary for their duties. Session-based access policies already enable this by restricting privileges based on IP, location, and identity provider attributes at login. But privileges granted at login persist for the entire session — even if conditions change.

🔍 Verify Explicitly

Authentication is not a one-time event. Session Validation Context embodies this principle by re-evaluating security conditions on every request during the session, not just at the front door.

🛡️ Assume Breach

Security controls are designed assuming attackers may have already compromised credentials or sessions. If a session cookie is stolen, SVC limits the blast radius by binding the session to its original network context and terminating it when that context changes.

These principles help organizations reduce risk from stolen credentials, session hijacking, and insider threats — especially at the application layer where your ServiceNow instance lives.

---

How It Actually Works

The mechanism is straightforward — no scripting or custom business rules required:

1. A user authenticates successfully. The platform records the originating IP address tied to that session.
2. On every subsequent request, the platform compares the current IP against the policy conditions you've defined.
3. If the IP falls outside the valid range — the session is terminated immediately.

It plugs into the same Adaptive Authentication policy framework you already know — same IP filter criteria, same role filter criteria, same condition builder, same sys_auth_policy_context table.

⚙️ The key design choice is how strict you want to be. You can configure SVC to either restrict sessions to a defined trusted network range (allowing IP changes within that range without disruption) or require re-login on any IP change whatsoever. The first approach balances security with user experience. The second is more secure but less user-friendly. Most organizations start with the trusted-range approach.

---

Real Scenarios Where This Matters

🌐 The vendor portal problem

A common recommendation is to combine post-authentication context policies with API access policies and Session Validation Context for comprehensive coverage. For organizations exposing portals to third-party vendors who connect from uncontrolled networks, continuous session monitoring adds protection that one-time authentication checks can't provide.

🔎 The "users getting dropped" mystery

While most cases of unexpected logouts stem from glide.ui.session_timeout misconfiguration or browser caching issues, some are caused by legitimate IP changes mid-session — VPN reconnections, Wi-Fi-to-cellular transitions, or proxy failovers. Understanding SVC helps you distinguish between a security event and a network event, and configure accordingly.

☁️ The integration IP headache

A common challenge with Adaptive Authentication pre-auth policy is blocking REST API traffic from cloud providers like AWS and Azure, where source IPs are dynamic. One practical workaround is moving everything to post-auth checks to bypass API evaluation, but Session Validation Context offers a more targeted option — broader valid IP ranges for session continuity while keeping tight Pre-Auth controls for initial access.

---

Setting It Up: A Practical Walkthrough

The following walkthrough covers the end-to-end configuration steps you can follow on your own instance.

📋 Prerequisites

• Adaptive Authentication plugin (com.snc.adaptive_authentication) — activated
• admin or security_admin role
• No extra licensing required — SVC is included within the Adaptive Authentication plugin with no additional SKU.

Step 1 - Define Your Trusted Network

Navigate to Adaptive Authentication > IP Filter Criteria. Create (or reuse) an IP filter criteria record representing the networks you trust for ongoing session validity. Add IP ranges for your corporate offices, VPN exit pools (use full CIDR blocks, not individual IPs), and any known remote work ranges.

💡 Tip: The IP filter criteria table lacks a per-range description field — unlike the old ip_access table. Use the criteria-level description field to document what each range represents. And critically, avoid creating separate criteria for each range — that adds significant performance overhead.

Step 2 - Define Role Filter Criteria

Navigate to Adaptive Authentication > Role Filter Criteria. Create role-based criteria to distinguish admin users from regular users — for example, users with the admin role requiring a trusted network, and all non-admin users allowed from any network.

Step 3 - Create the Adaptive Authentication Policy

Navigate to Adaptive Authentication > Authentication Policies and create a new policy combining the criteria from Steps 1 and 2. Build conditions using the condition builder:

• Condition 1: Admin Role IS true AND Trusted Network IS true → Allow
• Condition 2: Admin Role IS false → Allow (non-admin users can access from anywhere)

These conditions use OR logic between them — if either is satisfied, the session continues.

Step 4 - Assign the Policy to Both Contexts

This is the critical step. Assign the same policy to two contexts:

🔐

Post-Authentication Context — evaluated once at login – Default OOB policy is - Deny Access Policy

🔄

Session Validation Context — evaluated continuously during the session – Default OOB policy is - Session Validation Policy

By pairing both contexts with the same policy, you get comprehensive protection: the policy gates the door at login and watches the session afterward. This dual-assignment pattern is the recommended approach.

Step 5 - Enable the Platform Properties

• glide.authenticate.auth.policy.enabled — must be true (master toggle for all Adaptive Auth policy evaluation including SVC)
• Enable the Session Validation Context-specific property - session.validation.enabled

Step 6 - Test and Validate

⚠️ Always test in a sub-production instance first.

• Log in from a trusted network — confirm the session passes both post-auth and session validation policies
• Change your network mid-session — disconnect VPN, switch to a mobile hotspot, or connect from a different network
• Observe the result — the session should terminate immediately with your custom message
• Enforcement events for session validation context policies are logged in the Adaptive Authentication Events Table. Administrators can track how often sessions are terminated due to policy violations and analyze policy effectiveness.

Additional edge cases to test:

• VPN pools that rotate exit IPs — ensure the entire CIDR block is in your criteria
• Mobile users switching between Wi-Fi and cellular
• Load-balanced proxy architectures where source IPs may shift between requests

---

Your Turn

If you're ready to try Session Validation Context, set up a sub-production environment, enable Adaptive Authentication, and experiment with the admin-on-trusted-network pattern described above. Monitor the Adaptive Authentication Events Table to validate enforcement.

Share your use case in the comments: Are you protecting vendor portal access? Securing external contractor sessions? Locking down internal admin accounts? I'd love to hear how you're applying SVC — and the community benefits from every real-world implementation story.

Tags: Platform Security · Adaptive Authentication · Zero Trust Access · Session Validation Context · Session Hijacking · Instance Security