Adaptive Authentication is one of the most powerful security controls available on the ServiceNow platform — giving you the ability to enforce contextual access policies based on IP address, device trust, user roles, group membership, and authentication method. This blog will help you get it right the first time. We'll break down the three policy contexts that make up the framework, explain when each one runs, and walk through the logic that governs how they evaluate requests — so you can configure your policies with confidence and avoid common pitfalls along the way.
Why Do You Need Adaptive Authentication?
By default, anyone with valid credentials can log into your ServiceNow instance from any location. IP Address Access Controls (the ip_access.list table) provide basic IP filtering, but they don't give you the ability to make access decisions based on who the user is — their role, their group membership, or how they authenticated.
Adaptive Authentication adds a policy-driven layer on top of standard authentication. You can control:
| Control | Description | Example |
| Where | Which IP addresses or networks are permitted | Only from corporate VPN (10.0.0.0/8) |
| Who | Which roles or groups can access | Only users with itil or admin role |
| How | Which authentication method was used | SSO only — block local login |
| When | At which stage of the login process to evaluate | Block before login page vs after credential validation |
The Three Policy Contexts
When you activate the Adaptive Authentication plugin, ServiceNow creates three records in the sys_auth_policy_context table. Each represents a different stage in the authentication lifecycle, with distinct capabilities.
Figure 1: The complete execution flow. Pre-auth runs first, then post-auth, then ACR. A failure at any stage stops the flow.
Pre-Authentication Policy Context
This is your first line of defense. Pre-auth policies evaluate every incoming request before any credentials are processed. If the request fails, the user never sees a login page — they receive a 403 or 404 error.
What pre-auth can evaluate
- ✅ IP address — Is the request from a trusted network range?
- ✅ Trusted device — Has this device been registered via the Trusted Mobile App flow?
- ✅ Both session types — Interactive (browser) AND non-interactive (API, SOAP, MID server)
What pre-auth cannot evaluate
- ❌ Roles (the system doesn't know who the user is yet)
- ❌ Group membership
- ❌ Authentication scheme
Common pattern
Both pre-auth and post-auth contexts support Allow and Deny policies. Pre-auth additionally includes a Global Blocking Policy that applies to both interactive and non-interactive sessions (APIs, integrations, email actions).
The most common pre-auth configuration is an Allow policy with two conditions joined by OR logic:
| Condition | Criteria | Logic |
| Condition 1 | Trusted IP IS true | OR |
| Condition 2 | Trusted Mobile App IS true |
This permits access from trusted networks and trusted mobile devices. Either condition being true is sufficient.
⚠️ Important: Pre-auth policies affect non-interactive sessions too. If you set up a restrictive IP policy, it will block your REST API integrations and MID server connections unless their source IPs are in the trusted range.
Post-Authentication Policy Context
Post-auth policies run after the user has successfully submitted credentials. At this stage, ServiceNow knows exactly who the user is, enabling granular conditions based on identity.
What post-auth adds
- ✅ Roles — Does the user have
admin,itil, or a custom role? - ✅ Groups — Is the user a member of Service Desk, Change Management, etc.?
- ✅ Authentication scheme — Did the user log in via SSO, local credentials, or another method?
Interactive sessions only
⚠️ Important: Post-auth policies only evaluate interactive sessions (browser logins). They do not apply to REST API calls, SOAP integrations, or MID server connections. See the Non-Interactive Sessions section below for details on controlling API access.
Understanding Allow vs Deny logic
Both pre-auth and post-auth contexts let you create Allow or Deny policies. The policy type determines how the outcome of your conditions translates into an access decision. Filter criteria (IP range, role, group) return either true or false. In a Deny policy, you need the condition to be true for the user you want to block, not the user you want to allow — which feels counterintuitive at first.
Here's a quick reference for how each combination plays out:
| Policy Type | Condition Result | Access Outcome | Example |
| Allow | true | ✅ Granted | User has admin role → Allow policy condition is true → access granted |
| Allow | false | ❌ Denied | User lacks admin role → Allow policy condition is false → access denied |
| Deny | true | ❌ Denied | User is from blocked IP → Deny policy condition is true → access denied |
| Deny | false | ✅ Granted | User is not from blocked IP → Deny policy condition is false → access granted |
SSO — Account Recovery Context (ACR)
The ACR context handles a specific scenario: controlling whether users can bypass SSO by navigating directly to login.do for local authentication. It is the most common source of lockout incidents.
Default behaviour — and why people get locked out
Out of the box, the ACR context includes an Allow policy called "Non Local Login Users". The default condition allows access only when the authentication scheme is not local (i.e., the user came through SSO).
| Before enabling ACR | After enabling ACR |
|---|---|
| ✅ SSO login works | ✅ SSO login works |
| ✅ Local login (login.do) works | ❌ Local login (login.do) BLOCKED except for users registered for account recovery |
Common mistake: getting locked out of login.do
Administrators activate the plugin and enable glide.sso.acr.enabled, then discover they can no longer use login.do for break-glass access.
❌ Wrong approach: Enable ACR with default settings and assume login.do will still work.
✅ Correct approach: Modify the "Non Local Login Users" policy to add a role-based or group-based filter criteria that matches users who need local login access. For example, you could add a condition: Has snc_external Role IS true to ensure external users can still authenticate locally. Since conditions use OR logic, the policy will allow access if the user logged in via SSO OR matches your local login exception criteria.
Setting up Account Recovery users
Before enabling SSO on your instance, ServiceNow requires you to register at least one Account Recovery (ACR) user. This is your break-glass mechanism — if SSO becomes misconfigured or your identity provider goes down, ACR users can still log in via login.do using local credentials to fix the problem.
Here's how to set it up:
- Enable Account Recovery. Navigate to
Multi-Provider SSO > Account Recovery > Propertiesand set Enable account recovery to Yes. This must be done before enabling the multi-provider SSO property (glide.authenticate.multisso.enabled). - Register an ACR administrator. The administrator must have a local password set and must enroll in MFA (multi-factor authentication) before registering as an ACR user. Navigate to
Multi-Provider SSO > Account Recovery > Account Recovery Usersand add the user. - Register at least one additional ACR user. ServiceNow recommends registering more than one ACR user to avoid a single point of failure. If your sole ACR user leaves the organization or forgets their local password, you lose break-glass access entirely.
⚠️ Important: When an ACR user logs in via
login.do, they are logged in as an SSO Recovery User with limited permissions — restricted to modifying SSO configuration, certificates, and identity provider settings. They do not retain their full admin role during an ACR session. This is by design: ACR exists to fix authentication problems, not to serve as a general-purpose admin backdoor. However, the same user can also log in via SSO as usual — and when they do, their access is not restricted. They will have full access based on their assigned roles and permissions, just like any other SSO-authenticated user.Execution Order: How a Request Is Evaluated
Understanding the sequence is essential for predicting policy behaviour. Here's how an interactive login is processed:
- Pre-Auth evaluates first. Checks IP address and device trust. If an Allow condition fails or a Deny condition matches → 403/404, no login page shown.
- User authenticates. If pre-auth passes, the user sees the login page (or SSO redirect) and submits credentials.
- Post-Auth evaluates. Checks roles, groups, and auth scheme. If a Deny matches or Allow fails → session terminated.
- ACR evaluates (if enabled). Checks whether the authentication method matches expectations. If local login is used and policy only allows SSO → session terminated.
Putting It All Together
Figure 2: Use this decision tree to select the right policy context for your requirement.
Key properties reference
| Property | Purpose |
|---|---|
glide.authenticate.auth.policy.enabled |
Master toggle for pre-auth and post-auth policy evaluation |
glide.sso.acr.enabled |
Separate toggle for ACR context (independent of master toggle) |
glide.authenticate.blocked_response_code |
HTTP status code returned when blocked (default: 403) |
glide.authenticate.blocked_message |
Custom error message when access denied (default: "Access Denied") |
