Most ServiceNow instances hold dozens of integration users and OAuth clients with standing access to incidents, the CMDB, HR cases and request fulfilment, and many of them still authenticate with a password and carry an admin-level role. Monitoring tools open incidents, IGA platforms read and close catalogue tasks, discovery reads the whole estate through MID Servers and AI agents now call the instance through MCP. Each of those connections is a non-human identity. This guide goes deeper than the ServiceNow Security Guide on one part of the platform: how integration identities authenticate, which roles they should and should not hold, which Security Center settings close the common gaps, and how to detect misuse. It is for ServiceNow platform owners, IAM engineers and security architects responsible for ITSM data.
Key takeaways
- Every integration is an NHI with a user record. ServiceNow evaluates API calls against the roles and ACLs of the sys_user record the integration authenticates as, so the integration user's roles define the blast radius.
- Web service access only is the first control. Setting web_service_access_only on integration users stops them signing in to the user interface and is what ServiceNow's basic authentication restriction expects integration accounts to use.
- Move off passwords. Basic authentication and the OAuth resource owner password grant both handle a reusable password; prefer OAuth client credentials, JWT bearer or certificate-based authentication, and disable ROPC once nothing depends on it.
- No admin roles on integration users. ServiceNow's own hardening checks list admin, security_admin, discovery_admin, credential_admin and more than 100 other admin-level roles that must not be assigned to MID Server users; apply the same rule to every integration.
- ITSM data is a secrets store whether you like it or not. Tickets and attachments contain passwords, keys and HAR files, so an over-scoped integration token is also a credential-harvesting tool.
How identity and access work in ServiceNow
ServiceNow has one identity table, User [sys_user], for people and machines alike. Roles are granted through User Roles [sys_user_has_role], often via groups, and access to tables, fields and scripts is enforced by access control lists (ACLs). An API caller is just another user: if a read ACL fails, ServiceNow's ACL documentation notes, the user cannot retrieve records through web service protocols either. There is no separate permission model for integrations, which is why integration users so often end up with broad roles.
| Integration identity type | Typical use | Authenticates with | Main risk |
|---|---|---|---|
| Integration user (sys_user, web service access only) | Inbound REST or SOAP from monitoring, IGA, HR or DevOps tools | Basic authentication, OAuth token, API key, mutual TLS | Admin or itil_admin roles granted "to make it work"; long-lived password |
| OAuth client (Application Registry entry) | System-to-system or user-delegated access from external apps | Client ID and secret, JWT, or certificate; issues access and refresh tokens | Secrets in config files; ROPC grant; tokens that never expire |
| API key or HMAC secret (token based authentication) | Simple machine clients | Static key in a request header | Keys without expiry; expired keys retained |
| MID Server user | Discovery, orchestration and integrations reaching the internal network | Dedicated user with the mid_server role | Shared across MID Servers; admin roles; UI login allowed |
| Outbound credentials (Connection and Credential Aliases) | ServiceNow calling other systems: AD, cloud, IGA, ticketing | Stored credential records used by flows and Discovery | Domain admin or cloud admin equivalents held in the instance |
| MCP and AI agent clients | External AI clients calling ServiceNow tools | OAuth inbound integration per client | Token reuse across scopes; agents acting with a user's full roles |
Admin roles and privileged access
Integration security starts with the human admins who create integrations, because anyone with admin can create a user, grant roles and register an OAuth client.
- Elevated roles: creating or updating ACLs requires elevating to security_admin, according to ServiceNow's ACL documentation. Limit security_admin to a few named people and alert on every elevation.
- MFA for admins: ServiceNow's Security Center check for role based multi-factor authentication sets glide.authenticate.multifactor to true with the "Role based multi-factor authentication" criteria record active, covering admin, security_admin and user_admin. Federated admins should get phishing-resistant MFA at the identity provider instead.
- Who can register integrations: restrict creation of OAuth Application Registry entries, API keys and credential records to a small integration team. Treat changes to these records as privileged changes with change tickets.
- Roles that must never be on an integration user: admin, security_admin, user_admin, credential_admin, discovery_admin and module admin roles such as itil_admin, cmdb_ms_admin and knowledge_admin (all named in ServiceNow's MID Server access level check).
See the Privileged Access Management Guide for the wider programme those admins belong to.
Integrations, API tokens and service accounts
Choosing the authentication method
| Method | Credential exposure | When to use | Controls |
|---|---|---|---|
| Basic authentication | Password sent on every call | Legacy tools only, while migrating | Web service access only; basic auth restriction; long random password in a vault; rotate |
| OAuth resource owner password (ROPC) | Client holds the user's password | Avoid | Set glide.oauth.inbound.ropc.grant_type.disabled to true once migrated |
| OAuth client credentials | Client secret, short-lived access tokens | Default for system-to-system | Secret in a vault; token lifetime set deliberately; one client per integration |
| OAuth JWT bearer | Private key stays with the client | Where the client can sign assertions | Key rotation; certificate pinned to the registry entry. See the JWT Client Authentication (private_key_jwt) Guide |
| Certificate (mutual TLS) | Private key, no shared secret | High-value integrations with PKI in place | Certificate lifecycle and revocation |
| API key or HMAC | Static header value | Simple clients that cannot do OAuth | Always set an expiry; bind to a narrow API policy; automatic cleanup of expired keys |
Design rules for integration users
- One identity per integration, per environment. A shared "integration" user across five tools makes attribution, rotation and revocation impossible.
- Set web_service_access_only to true. ServiceNow recommends it for every MID Server user and its basic authentication restriction guidance says integration accounts should be converted to Web Service Access Only where possible.
- Grant table-level roles, not module admin. Build a custom role per integration that grants only the tables and operations it uses (for example, create on incident, read on cmdb_ci), and test it against ACLs.
- Name an owner. Record a human owner and the upstream system on the user record and in the integration inventory. See the NHI Ownership Guide.
- Keep secrets out of the instance where possible. Outbound credentials stored in ServiceNow should be scoped to the workflow's actions. For Discovery, ServiceNow's credential alias check recommends setting the MID Server property alias_filtering_behavior to strict so schedules can only use the credentials their alias allows (the page marks this property as deprecated, so check the replacement on your release).
- Separate MID Server users. Security Center checks for unique MID Server users and for the mid_server role only. A shared MID Server account turns one compromised server into access to all of them.
Where identity platforms connect
IGA and identity platforms often integrate in both directions: they read catalogue requests from ServiceNow and write back fulfilment status, and ServiceNow flows provision into directories with powerful outbound credentials. Those outbound credentials are frequently equivalent to directory or cloud administrators. Treat them as Tier 0 or Tier 1 secrets with the same rotation and monitoring as the systems they reach. The SaaS API Token Security Guide covers token lifecycle across SaaS platforms in general.
AI agents and MCP clients
ServiceNow's MCP Server Console requires an OAuth inbound integration for each MCP client. Security Center adds com.snc.platform.security.oauth.mcp.aig_scope_support (recommended true), which makes AI Gateway cache tokens per scope combination so a narrow request cannot reuse a token issued with broader scopes. See the Securing ServiceNow AI Agents Guide.
Hardening baseline
The settings below come from ServiceNow's Security Center hardening documentation. Test each in a sub-production instance and check the documented functional impact first.
| Setting | Default | Recommended | Effect |
|---|---|---|---|
| glide.authenticate.basic_auth.restriction.active | true | true | Evaluates basic-auth API calls from interactive-login accounts; first enable runs in tracking mode, logging to sys_user_basic_auth_exception |
| glide.authenticate.basic_auth.allow_snc_external | true | false | Removes the exemption for snc_external users (ServiceNow rates the risk High, CVSS 8.1) |
| glide.oauth.inbound.ropc.grant_type.disabled | false | true | Stops OAuth tokens being granted from a username and password |
| glide.basicauth.required.api | true | true | Requires authentication on inbound REST; a non-revertible "safe harbour" property, so never change it |
| glide.basicauth.required.soap, .wsdl, .xml and related | Yes | Yes | Requires authentication on legacy web service and export processors |
| com.snc.platform.security.token.auth.cleanup | true | true | Deletes expired API keys and HMAC secrets |
| ...days.expired.api_key.is.kept and ...hmac_secret.is.kept | 7 | 7 or less | Shortens the window in which expired tokens remain |
| sys_user.web_service_access_only (MID Server and integration users) | true for MID Server users | true | Blocks UI login for machine accounts |
| com.snc.platform.security.oauth.mcp.aig_scope_support | false | true | Scope-aware token caching for MCP flows |
Rolling out the basic authentication restriction: the first activation is a tracking period. Review the accounts that appear in sys_user_basic_auth_exception, convert each integration to web service access only or to OAuth, record a decision for each listed account, then let enforcement begin. ServiceNow describes switching the property off as a temporary emergency measure only, which is your rollback path.
Implementation approach
- Discover (weeks 1 to 3): query sys_user for accounts with web_service_access_only set, accounts with no interactive logins in 90 days but recent API transactions, and every holder of admin-level roles. Export the OAuth Application Registry, API keys, credential records and MID Server users. Match each to an upstream tool and owner.
- Triage (weeks 3 to 4): rank integrations by data reached (HR cases, security incidents and CMDB first) and by credential type (basic authentication and ROPC first).
- Track (weeks 4 to 8): activate the basic authentication restriction in tracking mode and review the exception table weekly. Build per-integration custom roles in a sub-production clone and test each integration's calls against them.
- Migrate (months 2 to 6): move integrations one at a time to OAuth client credentials, JWT bearer or certificates, store secrets in a vault, set API key expiry and swap admin roles for custom roles. Keep the old credential disabled, not deleted, for one release cycle as a rollback.
- Enforce (month 6 onward): enforce the basic authentication restriction, disable ROPC and the snc_external exemption, and make the inventory part of the quarterly access review.
Decision guidance: a small instance with a handful of integrations can move straight to OAuth client credentials and per-integration roles in a single project. A large, multi-instance estate should run the tracking period for longer, standardise one integration role template per pattern (event ingestion, IGA fulfilment, reporting read-only) and require new integrations to use it. Where a vendor connector only supports basic authentication, accept it temporarily with web service access only, a long random vaulted password, IP restrictions where available and a dated exception.
Logging and detection
- Transaction logs (syslog_transaction): record REST and SOAP calls with the user and URL. Baseline each integration's normal tables, volumes and source addresses; alert on new tables, bulk exports (large sysparm_limit values or many pages) and calls from new IP ranges. Bulk reads map to ATT&CK T1213 Data from Information Repositories.
- Login events (sysevent and the login history): an integration user with an interactive login is a finding in itself; repeated failures suggest password spraying (T1110.003).
- Role changes: audit inserts into sys_user_has_role for integration users and any security_admin elevation (T1098 Account Manipulation).
- New credentials: new OAuth registry entries, API keys, credential records and MCP clients (T1098.001 Additional Cloud Credentials is the closest technique).
- Basic auth exception table: new entries after enforcement show either a missed integration or someone using a human account for automation.
- Export to the SIEM: stream these tables to the SIEM, because instance logs alone do not survive an admin who deletes them. See the SaaS Security Guide.
| Metric | Target |
|---|---|
| Integration users with web_service_access_only set | 100% |
| Integration users holding any admin-level role | Zero |
| Integrations still on basic authentication or ROPC | Falling each quarter, zero for those touching HR or security data |
| API keys without an expiry date | Zero |
| Integrations with a named owner and inventory entry | 100% |
| Integration credentials older than the rotation standard | Zero |
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | CIS Controls v8.1 | ISO/IEC 27001:2022 |
|---|---|---|---|
| Integration identity inventory and ownership | AC-2, IA-4 | 5.5 | A.5.16 |
| Machine authentication and credential handling | IA-5, IA-9 | 5.2 | A.5.17, A.8.5 |
| Least-privilege roles for integrations | AC-6, AC-3(7) | 6.8 | A.5.15, A.8.2 |
| Logging of integration activity | AU-2, AU-6, AC-6(9) | 8.2 | A.8.15, A.8.16 |
Common misconfigurations
- The shared "svc_integration" admin: one admin-role user used by several tools, password in each tool's config. Revoking one integration breaks all of them, so nobody ever rotates it.
- Human accounts used for automation: scripts running as an engineer's personal account, which stop working when they leave or keep working after they do. The basic authentication restriction's tracking mode is a good way to find them.
- Never-expiring API keys and retained expired keys: keys created without an expiry, and cleanup disabled so expired keys linger.
- ROPC left on: OAuth "modernisation" that still sends a password, often because a vendor connector was configured with it.
- Over-scoped readers of ticket data: analytics or chatbot integrations with read access to all incident and case tables. In the Salesloft Drift breach, attackers with stolen integration tokens exported Salesforce support cases and searched them for AWS keys, passwords and Snowflake tokens. ServiceNow incident and case tables carry the same kind of data.
- Password-only service accounts without network restriction: the Snowflake breach showed what infostealer-harvested passwords do to accounts with no second factor. Integration users on basic authentication are in the same position unless restricted by source IP and moved to stronger methods.
Practitioner checklist
- Build an inventory of every integration user, OAuth client, API key, MID Server user, MCP client and outbound credential, with owner and upstream system.
- Set web_service_access_only on every integration and MID Server user.
- Remove admin-level roles from integration users and replace them with per-integration custom roles.
- Enable the basic authentication restriction, work through the tracking table, then enforce.
- Migrate integrations to OAuth client credentials, JWT bearer or certificates, then disable ROPC.
- Set expiry dates on all API keys and keep automatic cleanup on with seven days or less retention.
- Give each MID Server its own user with only the mid_server role and strict credential aliases.
- Stream transaction logs, login events and role changes to the SIEM and alert on bulk reads and new tables.
- Scan tickets and attachments for secrets and rotate anything found.
- Review integration access quarterly with the owners.
Standards and references
- ServiceNow: Enable basic authentication restriction
- ServiceNow: Restrict basic authentication external role exemption
- ServiceNow: Disable ROPC in OAuth 2 token grants
- ServiceNow: Ensure MID Server users have appropriate access levels
- ServiceNow: Set automatic token cleanup for token credentials
- ServiceNow: Restrict MID Server users from authenticating using the UI
- ServiceNow: Enforce least privilege on scoped MCP OAuth tokens
- ServiceNow: Exploring High Security Settings
Related NHI Mgmt Group resources: ServiceNow Security Guide · SaaS API Token Security Guide · Securing ServiceNow AI Agents Guide · Service Account Security Guide · SaaS and OAuth App Governance Guide