Built something you're proud of? Tell the story. A quick G2 review of App Engine or Build Agent helps other developers see what's possible on ServiceNow. Share your experience.

CCB6314 : Security Simplified Built-In Controls You Didn’t Know You Had Resources

Dhruvii
Kilo Sage

yesterday

Security Simplified: Built-In Controls You Didn't Know You Had

Knowledge 2026 · Platform Security · CCB6314

It Started with a Conversation

A few months before Knowledge 2026, I had a requirement land on my desk a legal one, no option to defer. I was convinced I needed to build a custom solution and had already started mentally scoping the effort.

So I pinged Pratik. He hopped on a call, listened to the use case, and said: "We already have something for that. It's a platform feature."

My instinct kicked in immediately. I told him there was no way I'd get budget approved for a separate product.

He said: "Bro. It's built in. No license. No strings attached."

I paused. Then I asked: "What else do you have up your sleeve?"

And he showed me a few more.

That conversation became the foundation of this session. If I didn't know these features existed — after all the time I've spent on this platform — I figured a few of you probably don't either.

So this talk is that list. No theory. No things you need to go buy. Just the controls that are already there, waiting to be turned on.

Speakers

Pratik Bhatt — Sr. Principal Product Manager, Platform Security, ServiceNow Connect on LinkedIn

Dhruv Gupta — AI Governance Lead, NN Group Connect on LinkedIn

What We Covered

The session was structured around three lines of defense : authentication, authorization, and debugging. Here's a summary of every topic we covered and why it matters.

Line 1 — Authentication: The Front Door

Most teams configure SSO, turn on MFA, and consider authentication done. The problem is that SSO tells you who someone is. It doesn't tell you whether they should be let in right now, from this device, from this location, using this method.

There's a difference between "I recognise this user" and "I trust this session."

Adaptive Authentication

By default, anyone with valid credentials can log in from anywhere. The basic IP filtering table — ip_access.list — exists, but it cannot make access decisions based on who the user is. Their role, their group, their authentication method. It doesn't know.

Adaptive Authentication adds a policy-driven layer across three stages:

  • Pre-Authentication — Fires before credentials are even processed. Evaluates IP address and device trust. A failed check returns a 403 or 404 before the login page is shown. Important caveat: pre-auth applies to non-interactive sessions too — REST APIs, SOAP, MID server connections. If you restrict by IP here, your integration source IPs must be in the trusted range or you will break your own integrations.
  • Post-Authentication — Fires after credentials are submitted. Now the platform knows who the user is, so you can evaluate roles, group membership, and authentication method. Did they log in via local credentials when you expect SSO only? This is where you enforce that. Note: post-auth applies to interactive browser sessions only — not API calls.
  • Account Recovery (ACR) — The most overlooked and the most common source of admin lockout incidents. ACR controls whether users can bypass SSO via login.do. The default policy only permits access when the authentication scheme is not local. When an ACR user logs in through this path, they come in as an SSO Recovery User with limited permissions — restricted to fixing the authentication configuration. This is a recovery mechanism, not an admin backdoor. Register at least two ACR users before enabling SSO. A single ACR user is a single point of failure.

Session Validation Context

After login, the platform trusts the session until timeout or logout. Authentication policies don't fire again. Which means if an attacker steals a session cookie — via XSS, a man-in-the-middle attack, or browser malware — they can replay it from a completely different network. Nothing stops them. Authentication already succeeded.

Session Validation Context closes this gap. When a session is created, the platform records the originating IP. On every subsequent request — not once at login, every request — it compares the current IP against your defined valid ranges. IP falls outside that range? Session terminated. Immediately.

This is not the same as VPN. VPN is a network control evaluated at connection time. SVC re-evaluates on every single request throughout the session lifetime. VPN doesn't protect you from a cookie stolen before VPN connected, from VPN pool IP rotation mid-session, from vendor portals on uncontrolled networks, or from cloud integrations with dynamic IPs. SVC handles all of these.

Setup: assign the same Adaptive Auth policy to both the Post-Authentication context and the Session Validation context. That dual assignment is the key step. No additional licensing — SVC is included in the Adaptive Authentication plugin.

Line 2 — Authorization: Protect the Data

Once a user is inside, the question shifts: what can they actually see and do? Authorization is where most of the complexity lives — and where most misconfigurations happen.

The design logic is: Identity → Permission → Visibility. In that order. Each layer has the right tool.

How Access Is Evaluated: Human vs Machine

Every request hits one of two paths:

Human path — Interactive session: Authentication → Role Evaluation → ACL Evaluation → Security Data Filters → Access Granted.

Machine path — Web service session: Authentication → Machine Identity Control (is this API whitelisted?) → Table Whitelist Check (is this table whitelisted?) → ACL Evaluation → Security Data Filters → Access Granted.

The machine path has two additional gates before ACLs even run. Most teams design their ACL strategy entirely for humans and forget that every integration user, every API call, every OAuth token takes this second path — with potentially open doors if Machine Identity Control and table whitelisting haven't been configured.

ACLs: The Foundation

ACLs evaluate across five criteria in performance order — fastest to slowest:

  1. Roles — The user must possess the defined role. Fastest check. If no match, evaluation stops here.
  2. Security Attributes — Reusable subject and environment conditions. Define once, apply across multiple ACLs and Security Data Filters.
  3. Data Conditions — Field-level conditions on the record. Use indexed fields here — unindexed fields in conditions will slow your list loads.
  4. Controlled by Reference — Inherit access from a related record. Useful for child tables.
  5. Scripts — Custom logic. Most expensive check. Last resort, not first move.

Non-Contextual vs Contextual ACLs

This distinction is where most ACL performance problems come from.

A non-contextual ACL makes its access decision based entirely on user properties — roles, groups, session attributes. It doesn't look at the record. The decision is the same regardless of which record is being evaluated. Evaluate it once per request — done.

A contextual ACL makes its decision based on record-level data. It has to look at the actual row. In a list view with 100 records, the platform runs that evaluation 100 times — once per row. This is what triggers the "security constraint" message on list views.

The diagnostic question: does your ACL script reference current?

  • No → non-contextual
  • Yes → contextual

Must-Use Features

These four features were the heart of the session. All built-in. No plugins. No additional licensing.

Deny-Unless ACL Standard ACLs ask: should this person be allowed? Deny-Unless asks: can I confirm a valid reason this person should be allowed — and if I can't, deny them. It evaluates before Allow-If ACLs. If it fires a denial, the Allow-If ACL never runs. Use this on your most sensitive tables — HR data, financial records, anything where you need a hard guarantee that misconfiguration elsewhere in the ACL hierarchy can't leak data.

Security Data Filter Instead of fetching all records and checking each one against an ACL, SDFs append a WHERE clause to the database query. Only authorised rows come back. No per-row ACL check. No security constraint message. Faster lists. Better user experience. This is the fix for contextual ACL performance problems.

Query ACL Two types: query_match controls exact-match searches on a field; query_range controls range-based searches. A user who can't see a salary field value can still search for records with salary above a threshold and infer values from the results. Query ACLs prevent this. You can't see the data — and you can't search for it either.

Role Management v2 Duplicate roles in the User Roles table are a silent security problem. They inflate effective permissions and are nearly invisible in a standard role review. Role Management v2 eliminates existing duplicates and prevents new ones from being created. Simple to enable, immediate impact on your security posture.

Tips: The Layered Model

Think of your controls in three layers:

  • Security Data Filter — filters who is allowed to approach at all. Most records never returned.
  • Deny-Unless ACL — validates the business reason for accessing records that did come back.
  • Allow-If ACL — confirms the right permissions. This layer should do one job only.

In the past, most instances put everything into one scripted Allow-If ACL — filtering, validating, and permitting all at once. Complex, fragile, slow. With SDFs and Deny-Unless ACLs, each layer does its own job. Allow-If stays clean.

The two optimizations:

Non-contextual scripted ACL → Security Attribute If your script doesn't reference current — it's checking user properties only. Move it to a declarative Security Attribute. Faster evaluation, reusable, easier to audit.

Contextual scripted ACL → Security Data Filter If your script references current — it's checking record data. Move the condition to a Security Data Filter. Database-layer filtering eliminates per-row evaluation and removes the security constraint message entirely.

REST API Access Policies

These sit across both authentication and authorization. The default problem: UI permissions equal API permissions. All APIs accept OAuth, ID Token, mTLS, and Basic Auth by default. REST API Access Policies add the missing control layer across four dimensions:

  • Who — which roles or groups can access this API
  • How — which authentication methods are permitted (note: adding an API Key profile blocks all other auth methods — not additive, exclusive)
  • From Where — IP address restrictions
  • What — specific APIs, versions, and HTTP methods

Advanced API Controls: OAuth Entity Linking and MIAC

OAuth Entity Linking — API Access Policies don't distinguish between different OAuth applications. If a policy allows OAuth, any OAuth app that meets the conditions gets through. OAuth Entity Linking links a specific OAuth application to a specific policy. Only that app gets through. Every other OAuth app is denied — even with a perfectly valid token.

Machine Identity Access Control (MIAC) — Policies control the conditions for access but not which APIs an integration user can actually call. A user with the right role can call anything that role permits across your entire instance. MIAC switches this to deny-by-default. Once enabled for an integration user, all API access is blocked unless explicitly listed — which APIs, which tables. Works regardless of roles, including admin.

Practical example: your monitoring tool needs incident data via Table API. With MIAC, restrict it to exactly that — Table API and incident table only. Someone repurposes that account to pull HR data — blocked.

Least privilege for machine identities. The same principle we've always applied to humans — finally applied to integrations.

Line 3 — Debugging and Troubleshooting

[Covered by Pratik Bhatt — see session recording for full content including Access Analyzer walkthrough, AI Agent security model, and role masking.]

Resources

Everything referenced in the session, in one place:

Topic Link
Access Analyzer Documentation
ACL Best Practices Community Blog
REST API Access Policies — Part 1 Community Blog
REST API Access Policies — Part 2 (OAuth Entity Linking, MIAC) Community Blog
Role Masking Documentation
Role Management v2 Documentation
Security Data Filter — Blog Series Community Blog
Session Validation Context Documentation

Start Here

If you're leaving this session and want to know where to begin — this is the order:

  1. Access Analyzer — run it on a user who shouldn't have access to something sensitive. You'll see exactly why they can or can't reach a record. It's the fastest way to understand your current posture and the most useful tool for everything covered in this session.
  2. Role Management v2 — enable it. Eliminate existing duplicate roles and prevent new ones. Quick win, immediate impact.
  3. The diagnostic question — look at your five most-used scripted ACLs. Does the script reference current? Use that answer to decide whether each one should become a Security Attribute or a Security Data Filter.
  4. Session Validation Context — if you already have Adaptive Authentication enabled, adding SVC is a configuration change, not a project. Assign your existing policy to the Session Validation context and enable session.validation.enabled.
  5. REST API Access Policies — audit which integration users have web service access. Pick the three most critical and define explicit policies for them. Add MIAC from there.

Let's Keep the Conversation Going

Questions, war stories, things that didn't work the way you expected — we're both happy to continue the conversation.

Pratik Bhatt → linkedin.com/in/pratik1490 Dhruv Gupta → linkedin.com/in/dhruvceh

Session CCB6314 · Knowledge 2026 · Platform Security Track

 

0 Helpfuls
  • 129 Views
0 REPLIES 0