ServiceNow ITSM holds an organisation's incidents, change records, HR cases, asset data and integration credentials, and its security depends almost entirely on how each customer configures access control lists, public pages and integrations. The platform is hosted, but the ACLs, roles, integration users, MID Servers and AI agents are the customer's responsibility, and the 2023 public widget exposure showed how a default left in place can publish internal records to the internet. This guide covers the ServiceNow security model and ACLs, instance hardening with the High Security Settings plugin and ServiceNow Security Center, public pages, integration users, OAuth and REST API authentication, MID Server security, secrets in tickets and knowledge bases, Now Assist AI agents and the MCP server, and the 2024 exploited vulnerabilities. It is written for ServiceNow platform owners, administrators and the security teams that assess them.
Key takeaways
- Default deny is the foundation. Set glide.sm.default_mode to deny, keep the High Security Settings plugin active and require security_admin elevation for every ACL change.
- Anything public is on the internet. Review every ACL that grants the public role and every Service Portal widget marked public; restrict instance access by IP where external users do not need it.
- Integration users are privileged non-human identities. Give each integration its own account, scoped roles, OAuth or certificate authentication through REST API access policies, and never the admin role.
- The ITSM data is itself a secret store. Passwords, keys and tokens pasted into incidents, work notes and knowledge articles are found and used by attackers; scan, redact and rotate.
- AI agents inherit identity choices. Run Now Assist AI agents as the invoking user with role masking, use a fixed AI user only when justified, and expose MCP server tools deliberately through OAuth inbound integrations.
The ServiceNow security model
Access in ServiceNow is decided by roles and access control list (ACL) rules evaluated by the platform's security manager. A handful of platform settings decide how safe the defaults are.
- Roles: users and groups receive roles that ACLs and applications require; admin and the roles that can grant it are the main targets.
- security_admin and elevation: with the High Security Settings plugin, key security settings and ACLs can only be changed after elevating to security_admin. ServiceNow states the role "is not inherited by the admin role and must be explicitly assigned", so administrators work as normal users until they elevate. Admins can read protected system properties but must elevate to change them.
- ServiceNow High Security Settings plugin: ServiceNow documents it as "active by default on new instances". It adds read and write role restrictions to system properties, turns on security warning notifications and sets secure defaults for properties such as glide.ui.escape_text, glide.security.strict.updates and glide.security.use_csrf_token. Older, upgraded instances should confirm it is active rather than assume it.
- Default deny: the glide.sm.default_mode property should be deny. ServiceNow rates leaving it otherwise as high risk because "Non-administrator users can access objects that match the wildcard table ACL rules."
- Shared responsibility: ServiceNow runs the platform; ACLs, roles, public pages, integrations, MID Servers and AI configuration are customer controls that drift with every release. See the SaaS Security Guide.
ServiceNow ACLs: getting access control right
ServiceNow defines ACLs as rules "that control user access to various system objects such as tables, fields, and records." Each rule names the object, the operation and the conditions, and a user must pass every condition in the rule.
| ACL element | What it does | Security guidance |
|---|---|---|
| Decision type: Allow-If or Deny-Unless | Allow-If grants access when conditions pass; Deny-Unless explicitly denies unless conditions pass | Use Deny-Unless for sensitive tables (HR, security incidents, credentials) so a broad Allow-If elsewhere cannot open them |
| Operation | read, write, create, delete, execute and others such as report_on and list_edit | Cover reporting and export operations, not just read; report_on can expose data through reports |
| Required roles | User must hold one of the listed roles | Every ACL on non-public data should require a role; avoid the public role except for deliberately public content |
| Data condition and security attributes | Record-level conditions, for example assigned group or caller | Use for row-level restrictions; conditions are evaluated after the query |
| Script | Custom logic returning true or false | Keep scripts simple and peer reviewed |
| Table and field rules | Field rules (table.field) and table rules are both checked; wildcard rules catch everything else | Secure sensitive fields with their own rules rather than relying on the table rule |
- Empty checks: researchers who reported the 2023 exposure said an ACL with no role, condition or script check resolves to true, as reported by The Register. ServiceNow's documentation separately says the engine "completely denies access if an ACL is empty or invalid". Treat any ACL with no requirements as granting access to everyone it matches, and find and fix them.
- Pre-query versus post-query: roles are checked before a query, conditions and scripts on each returned record, so list counts can reveal that protected records exist.
- Change control: review ACL changes in update sets before promotion.
Instance hardening: High Security Settings and Security Center
ServiceNow instance hardening tooling has changed. Instance Security Center (ISC) gave a Daily Compliance Score against published hardening values and notifications for events such as Admin Login, Failed Login, High Privilege Role, Impersonation and Security Elevation. ServiceNow states that "Instance Security Center is a legacy product that will reach the end of sales by September 2024" and that ServiceNow Security Center (SSC) "is the recommended solution". SSC keeps the hardening score and comparison, adds more than 65 security metrics and a security scanner that runs scheduled scans with custom checks and suites.
| Area | Setting or control | Target |
|---|---|---|
| Default access | glide.sm.default_mode | deny |
| Security settings protection | High Security Settings plugin; security_admin elevation | Active; security_admin assigned to few named people |
| Request forgery and output encoding | glide.security.use_csrf_token; glide.ui.escape_text | Enabled (set by High Security Settings) |
| Network access | IP address access control on the instance | Allowlist corporate egress and integration sources where external users are not needed |
| Public exposure | Public role ACLs; Service Portal widgets with the public flag | Only deliberately public content |
| Hardening posture | ServiceNow Security Center hardening score and scheduled scanner | Tracked monthly; exceptions documented |
| Admin monitoring | Notifications for admin login, impersonation, security elevation and high privilege role grants | Routed to the security team, not only the platform team |
Authentication for people belongs in the corporate identity provider through single sign-on with phishing-resistant MFA, with local logins limited to a documented break-glass admin. See the Break-Glass Account Guide.
Public pages and the 2023 data exposure
In the October 2023 ServiceNow data exposure, a researcher showed that ServiceNow widgets, with the Simple List widget as the example, could return records to unauthenticated users when ACLs granted public access. The US Department of Health and Human Services HC3 analyst note of 18 October 2023 described it as "a misconfiguration in a component or widget in ServiceNow's system called Simple List", and ServiceNow published KB1553688 about it. ServiceNow told The Register: "We make these protocols extensible so our customers can configure them based on their unique security needs". The fixes recommended at the time remain the checklist for ServiceNow public pages:
- List every ACL that includes the public role and remove it where the data is not meant for anonymous users. HC3: "validate ACLs that contain the public role and remove it if necessary."
- Define role, condition and script checks on every ACL that protects non-public tables.
- Review Service Portal widgets and uncheck the public flag where employees, not anonymous visitors, use them, after assigning the right roles.
- Consider the Explicit Roles plugin, which requires a role the guest user does not hold on each ACL; HC3 warns that "Extensive preparation should be made prior to turning this plug-in on."
- Apply IP address access control if the instance does not need to be reachable from the internet. HC3: "Implementing IP restrictions for inbound traffic will entirely prevent public data exposure."
- Test from an unauthenticated session after every portal or catalog release.
Integration users, OAuth and the ServiceNow REST API
ServiceNow is a hub: monitoring tools create incidents, IGA and onboarding automation consume request fulfilment, and data teams use ServiceNow as a datastore for CMDB and service data. Each connection is a ServiceNow integration user or an OAuth client, and each is a non-human identity with standing access. ServiceNow's Machine Identity Console (plugin com.glide.identity.machine_identity_management) exists to manage these "service accounts used in ServiceNow integrations", score them and make recommendations.
- One integration user per integration: dedicated account, an owner, the minimum roles for the tables it touches, and no admin role. Mark it for web service access only so it cannot sign in to the user interface. See the Service Account Security Guide.
- ServiceNow OAuth over basic authentication: the inbound integrations experience supports authorization code, client credentials, JWT bearer, third-party token and resource owner password grants. Use client credentials or JWT bearer for system-to-system work; avoid the resource owner password grant, which still handles a password.
- REST API access policies: a policy maps allowed authentication profiles (Basic, ID token, certificate-based, OAuth, API key, HMAC) to a REST API, version, method or table, so you can refuse basic authentication on sensitive APIs. Creating them needs the api_service_admin and adaptive_auth_policy_admin roles.
- API keys: ServiceNow's token-based API keys (plugin com.glide.tokenbased_auth) are tied to a user, sent in the x-sn-apikey header, and must be bound to a REST API access policy; "Token Based Auth isn't allowed in the Global REST API Policy." An empty expiry field means the key never expires, so always set one. See the API Key Management Guide.
- Outbound ServiceNow credentials: credentials used for ServiceNow onboarding automation and request fulfilment integrations that provision into directories, cloud platforms and IGA are often admin equivalents. Scope them to the workflow's actions and rotate them.
- Third-party apps: govern OAuth clients and store apps like other SaaS OAuth grants. See the SaaS and OAuth App Governance Guide.
MID Server security
The ServiceNow MID Server (Management, Instrumentation and Discovery) runs inside the customer network and performs discovery, orchestration and integrations for the instance. Its credentials can often log on to servers, network devices and directories across the estate.
- Credential handling: ServiceNow stores discovery and orchestration credentials on the instance and sends them to the MID Server re-encrypted with the MID Server's key over TLS. The key stays in memory: "At no point is the credential password stored on the disk in an unencrypted format." Protecting the host still matters, because an attacker with control of the running MID Server process can use what it decrypts.
- Mutual authentication: ServiceNow's MID Server mutual authentication "removes the MID Server user name and password" and uses a client certificate instead. It requires RSA 2048-bit keys, rejects self-signed certificates, needs reachable OCSP and CRL endpoints and is requested through ServiceNow support. Without it, the MID Server user's password is a credential to vault and rotate.
- Least privilege for discovery accounts: discovery rarely needs Domain Admin. Use read-only or scoped accounts per credential type, restrict which MID Servers can use which credentials, and prefer gMSAs or vaulted rotated passwords. See the Group Managed Service Accounts (gMSA) Guide.
- Host hardening: treat MID Server hosts at the tier of the credentials they hold: dedicated servers, restricted local admin, patching and logging.
Secrets in tickets and knowledge bases
ServiceNow tickets collect passwords, API keys, connection strings and recovery codes pasted by users and engineers under pressure, and knowledge base articles often document service account passwords for the next person. ATT&CK T1213 Data from Information Repositories records a threat group that "gathered data from internal service ticketing systems to include credentials." Support tickets are also an attack path in their own right: the Canvas Instructure breach began with a poisoned support ticket that yielded a privileged token.
- Scan: run secrets detection over incidents, requests, work notes, comments, attachments and knowledge articles through the REST API using a read-only integration user, and alert the owning team.
- Redact and rotate: treat any secret found in ServiceNow as exposed. Rotate it first, then redact the record and its history. See the Leaked Credential Response Playbook.
- Restrict the ServiceNow knowledge base: limit who can read internal articles and never store credentials in them.
- Prevent: discourage pasting secrets in forms and give support teams a secure sharing method. See the Guide to the Secret Sprawl Challenge.
Now Assist, AI agents and the ServiceNow MCP server
ServiceNow AI agents built on Now Assist act on instance data, so their identity configuration decides what they can do.
- Run-as identity: agents and agentic workflows run either as a dynamic user, the default, inheriting the roles of whoever invoked them, or as an AI user, a dedicated sys_user identity whose roles stay fixed and can be higher than the caller's. ServiceNow recommends dynamic users by default and an AI user only where fixed elevated privileges are needed.
- Role masking: for dynamic users, role masking limits execution to "the intersection between the roles assigned to the invoking user and the" approved roles list, and "never grants additional roles beyond those of the user."
- ACLs govern invocation only: ServiceNow states that AI Agent Studio ACLs "only determine the roles required for users to invoke" an agent; runtime access comes from the run-as identity. Configure ACLs, run-as identity and role masking together. Avoid the Public option, which includes guests.
- Deny by default: newly activated instances start AI agents from a deny-by-default posture; upgraded instances must opt in.
- ServiceNow MCP server: the MCP Server Console lets administrators publish MCP servers that expose chosen tools and fields to external AI applications. Clients connect with OAuth 2.0 through an OAuth inbound integration per client or a third-party identity provider, and AI Gateway in AI Control Tower monitors MCP server access. Create one server per use case, expose the fewest tools and log every client. See the MCP Security Guide.
ServiceNow AI agents that read user-submitted tickets are also exposed to prompt injection. See the AI Agent Authorisation Guide.
Vulnerabilities and patching
In July 2024 ServiceNow addressed three vulnerabilities in the Vancouver and Washington DC releases (advisory KB1645154).
| CVE | Type | CVSS 3.1 (ServiceNow) | CISA KEV |
|---|---|---|---|
| CVE-2024-4879 | Input validation flaw allowing an unauthenticated user to execute code remotely | 9.8 | Added 29 July 2024, due 19 August 2024 |
| CVE-2024-5217 | Input validation flaw allowing unauthenticated remote code execution | 9.8 | Added 29 July 2024 |
| CVE-2024-5178 | Sensitive file read by an administrative user | 4.9 | Not listed in the CVE record's CISA data |
Confirm every instance, including sub-production clones, runs a fixed patch level; self-hosted instances are the customer's to patch. Unauthenticated remote code execution maps to ATT&CK T1190 Exploit Public-Facing Application; IP address access control reduces exposure while patches are applied.
Detection and measurement
Send ServiceNow security events and transaction logs to central logging and alert on admin logins, security_admin elevation, impersonation, new high-privilege role grants, ACL and system property changes, new OAuth clients or API keys, integration users signing in from new IP addresses or to the user interface, and bulk exports or unusual list and report volumes.
Metrics that show it is working:
- ServiceNow Security Center hardening score and number of failed checks (rising score, falling failures).
- ACLs granting the public role and widgets with the public flag, each with a documented reason.
- Integration users holding admin, and integrations still using basic authentication (target: zero for both).
- API keys without an expiry (target: zero).
- Secrets found in tickets and knowledge articles per month and time to rotate.
Implementation roadmap
- Baseline: run the ServiceNow Security Center scan, export ACLs with the public role, public widgets, admin and security_admin holders, integration users and API keys.
- Close exposure: fix public ACLs and widgets, test anonymously, and apply IP address access control if appropriate. Test IP rules in a sub-production instance first and keep a documented rollback.
- Harden: confirm High Security Settings, glide.sm.default_mode deny and security_admin elevation; move admin logins to SSO with MFA.
- Fix integrations: one user per integration, scoped roles, OAuth or certificates, REST API access policies blocking basic auth, expiry on API keys; migrate one integration at a time with the old credential disabled, not deleted, until proven.
- MID Servers: enable mutual authentication, scope discovery credentials and harden hosts.
- Clean data: scan tickets and knowledge bases for secrets, rotate and redact.
- Govern AI: set agent ACLs, dynamic users with role masking, and MCP server OAuth integrations before enabling agents in production.
Decision guidance
- Dynamic user or AI user: dynamic user with role masking whenever the agent acts for a person; an AI user only for background automation, with its own minimal roles and an owner.
- IP restriction or open instance: restrict when all users and integrations come from known networks; a public portal instead needs strict ACLs and anonymous testing.
- Small and large organisations: a single-instance team should focus on default deny, public ACLs, SSO, integration users and Security Center scans. Large, multi-instance estates add scheduled scanner suites, automated ACL review in the release pipeline, Machine Identity Console for integration inventory and SIEM correlation.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | CIS Controls v8.1 | ISO/IEC 27001:2022 | ATT&CK (v20) |
|---|---|---|---|---|
| ACLs, roles and default deny | AC-3, AC-6 | 3.3, 6.8 | A.5.15, A.8.3 | T1213 |
| Integration users, OAuth and API keys | IA-5, AC-2 | 5.5, 6.1 | A.5.17, A.5.18 | T1078 |
| Hardening and patching | CM-6, SI-2 | 4.1, 7.4 | A.8.8, A.8.9 | T1190 |
| Logging and monitoring | AU-2, AU-6 | 8.2, 8.11 | A.8.15, A.8.16 | Detection for the above |
Common failure patterns
- Public by default: widgets and ACLs left with the public role, found by anyone who knows the table names.
- Admin integration users: integrations given admin "to make it work", with basic authentication and passwords that never change. Integration token theft is how the Salesloft Drift breach spread across hundreds of tenants of another SaaS platform.
- API keys that never expire: keys created with an empty expiry field and tied to powerful users.
- Domain Admin on the MID Server: discovery credentials far broader than discovery needs, on a lightly managed server.
- Credentials in the knowledge base: service account passwords documented in articles readable by all employees.
Practitioner checklist
- Set glide.sm.default_mode to deny and confirm the High Security Settings plugin is active.
- Assign security_admin to a few named people and alert on every elevation.
- Remove the public role from ACLs and the public flag from widgets unless deliberately public; test anonymously.
- Give each integration its own non-admin user, OAuth or certificate authentication and a REST API access policy.
- Set an expiry on every API key and review keys quarterly.
- Enable MID Server mutual authentication and scope discovery credentials.
- Scan tickets, attachments and knowledge articles for secrets, then rotate and redact.
- Run AI agents as dynamic users with role masking and expose MCP tools only through OAuth inbound integrations.
- Track ServiceNow Security Center scores and patch levels across all instances.
Standards and references
- ServiceNow: Explore Access Control Lists
- ServiceNow: Exploring High Security Settings
- ServiceNow: Instance Security Center to ServiceNow Security Center migration
- ServiceNow: Enable MID Server mutual authentication
- ServiceNow: Implement access control in AI agents
- ServiceNow: Exploring MCP Server Console
- NIST NVD: CVE-2024-4879
- HHS HC3: ServiceNow Vulnerability Analyst Note
Related NHI Mgmt Group resources: SaaS Security Guide · Service Account Security Guide · API Key Management Guide · MCP Security Guide · SaaS and OAuth App Governance Guide