How many people have admin access on your instance right now? If you had to think about it, you're not alone, and that's exactly the kind of thing the right scans can answer for you.
In our last post, we talked about how Security Scanner inside ServiceNow Security Center helps you catch misconfigurations before they become problems. The default Auditor suite covers a lot of ground right out of the box, with 25 built-in checks for things like empty ACLs, public REST endpoints, and outdated password hashes. It's a great starting point, and it's included with every instance.
But here's the part nobody really talks about: the Auditor suite is built to catch what every ServiceNow instance should care about. It doesn't know about your org's policies, your custom apps, or the cleanup tasks your security team has been meaning to get to for a while now.
The good news? You can create it. Building your own custom checks is one of the most powerful features of Security Scanner, and one of the least used. Once you understand how, you can scan for almost anything that matters to you and your organization.
The use case: finding stale admin accounts
Every ServiceNow instance has admin accounts. Some belong to active platform owners. Some belong to a contractor whose project wrapped up last summer. Some belong to a former teammate who needed admin access for a migration once and never had it taken away.
The thing is, all of them can still log in. An admin account that hasn't been used in 90 days isn't really a dormant account, it's a live account with the most privileged role in your instance, sitting unwatched. If those credentials ever get compromised, no one is going to notice anything unusual, because no one was watching that account to begin with.
This is something every customer should care about, regardless of size or maturity. The default Auditor suite has a check called "Review roles that contain the admin role," but it doesn't filter for activity. The risk is real, it's universal, and there's no built-in check that catches it.
So let's build one!
Building the check
Scanner checks live under All > Security Center > Security Scanner > Checks.
If you're on the Australia release with Security Center 3.2 or later, assign the Security Center Admin role (sn_vsc.security_center_admin), which grants admin-level access to the Security Center features while following least-privileged access principles. If your instance is on an earlier release where that role isn't available yet, you may still need elevated access to author checks today, which is another great reason to scan for and clean up any admin access you don't need.
From the Checks list, click New, and you'll be asked to pick a check type. For this one, we want Create a new Table Check, since we know exactly which table and which condition we're looking for.
Fill out the form like this:
- Name: Stale admin accounts
- Short Description: Identifies active users with the admin role who haven’t logged in within 90 days.
- Priority: 2
- Active: true
- Table: User [sys_user]
- Resolution Details: Review each finding. If the user no longer needs admin access, remove the admin role or deactivate the account. If the account is legitimately needed but inactive, document the business justification and consider rotating the password.
For the Conditions:
Active is true
AND Role is admin
AND Last login at or before 90 days ago
That's the whole check, super simple to build out. Three conditions, one table, no script. Save it and you're ready to test!
Testing before you trust it
Before adding this to a suite and scheduling it, test it in a sub-prod instance to ensure it works. The easiest approach is four test cases covering what should and shouldn't trigger a finding. You don't even need new users, just adjust the roles and active status on existing accounts to match each case.
Set up four users like this:
- Test User 1: Active, admin role, last login over 90 days ago → should trigger
- Test User 2: Active, admin role, last login within 90 days → should NOT trigger
- Test User 3: Active, no admin role, last login over 90 days ago → should NOT trigger
- Test User 4: Inactive, admin role, last login over 90 days ago → should NOT trigger
To find accounts with an old enough last login, navigate to the Users list and filter on Active is true AND Last login on or before 90 days ago. Any account that comes back already has a stale login, so you can add or remove the admin role and toggle the active flag to build each test case.
One you run your check, you should see findings for Test User 1 only. Each of the other three confirms a different condition is doing its job: User 2 proves the date filter works, User 3 proves the admin role filter works, and User 4 proves the active filter works. If all four work as expected, your check is successful.
This kind of test is worth building for any custom check, not just this one. It takes about ten minutes and saves you from publishing a broken check to your whole instance. And remember to undo any test changes afterward, so an account you temporarily gave admin to doesn't show up as a real finding the next time your check runs.
Bundle it into a suite
A check on its own doesn't run on a schedule, suites do. Clone the Auditor suite (or create a new one), add your custom check, and set a schedule. Now you have a recurring scan that enforces your org's policy along with the built-in checks, and you can compare findings over time using scan comparison.
Creating another check: scan for all your admins
The nice part about building that first check is with one small change, it can become an entirely different check.
If we remove the last-login condition from our earlier check, we’re left with this:
Active is true
AND Roles contains admin
Now we have a check that reveals every active admin on our instance. Running this regularly will give you a clean, current list for access reviews, audit prep, or just keeping an eye about how many people are walking around with the keys to the instance.
Once you've built one check, you have the basic formula to build others: pick a table, write a condition that represents risk, save it, test it, schedule it. The next check you write might be about users still in privileged groups after offboarding, or ACLs on custom tables without roles assigned.
The default Auditor suite is a great starting point, but by creating custom checks, you are truly able to make Security Scanner yours.
Challenge: Build it yourself
We just built a check for stale human admins, but humans aren't the only idle accounts on our instances. Service accounts, integration users, and other non-human identities (NHIs) go stale too, often more quietly and with more privilege.
So here's a quick challenge: try to build a check that surfaces stale service, integration, or other NHI accounts.
Take the basic formula we just mentioned and try applying to it create a new check. Then bring your check to our Office Hours on June 9 and we'll work through it together, whether you succeeded or just want to see how we'd approach it.
Want to see this in action?
Join us on June 9th at 10AM PT/1 PM ET for Open Office Hours: Scanning with Purpose, part of our ongoing Instance Security webinar series. This one's a live Q&A format, so bring your scanning questions, your half-built checks, or any general Security Center questions, and we'll work through them together.
Register here for free: https://servicenow.zoom.us/meeting/register/-zI8mxznRoCRwXuaSDSVSg
Have questions or want to stay in the loop on future webinars? Reach out to us anytime at InstanceSecurity@servicenow.com we'd love to hear from you!
Want to dig deeper? Check out the official ServiceNow documentation on creating new scan suites and scan checks.
