Introduction

ServiceNow Identity Management is the foundation for controlling who can access a ServiceNow instance, how users authenticate, how accounts are provisioned, and what permissions they receive after login. In a typical enterprise implementation, ServiceNow does not operate as an isolated user directory. Instead, it works with corporate identity platforms, directories, and provisioning systems to establish a controlled identity lifecycle.

For example, an organization may use Microsoft Entra ID as its enterprise identity provider, Active Directory as its directory, and ServiceNow as the ITSM platform. When an employee joins the company, the identity platform creates the employee account. The employee is assigned the appropriate ServiceNow application or group access. When the employee leaves, access should be removed without depending on a ServiceNow administrator to manually disable the account.

This is where identity management becomes more than simply creating users.

A production implementation normally needs to address:

• Authentication

• Single Sign-On (SSO)

• Multi-factor authentication

• User provisioning and deprovisioning

• Group synchronization

• Role assignment

• LDAP integration

• SCIM provisioning

• OAuth and API authentication

• Service accounts and machine identities

• Access analysis

• Least-privilege security

• Audit and compliance

ServiceNow documentation separates authentication from authorization: authentication validates the identity of the user or client, while authorization determines what that identity can access based on roles and other controls.

What Is ServiceNow Identity Management?

ServiceNow Identity Management is the collection of capabilities and integrations used to manage identities and their access throughout the ServiceNow platform.

A useful way to understand it is through four lifecycle stages:

Consider an employee named Priya joining an organization.

The HR system creates Priya’s employee record. The corporate identity platform creates her identity. The identity platform provisions the required ServiceNow account. Priya signs in using corporate SSO. ServiceNow receives the authenticated identity and establishes a ServiceNow session. Her groups and roles determine whether she can access incidents, changes, knowledge articles, reports, or administrative functionality.

When Priya changes departments, her identity attributes or group memberships can change. When she leaves the company, the provisioning process should disable or remove her ServiceNow access.

This lifecycle is the practical meaning of identity management.

ServiceNow Identity Management Architecture

A common enterprise architecture looks like this:

                  HR System
                      |
                      v
             Identity Governance
                      |
                      v
        Corporate Identity Provider
          /                    \
         /                      \
   SSO Authentication       SCIM Provisioning
       |                         |
       v                         v
                  ServiceNow
                       |
             +---------+---------+
             |                   |
          Groups               Roles
             |                   |
             +---------+---------+
                       |
                       v
               Access Controls
                       |
                       v
              ServiceNow Resources

There are usually two separate flows.

Authentication Flow

User
  |
  | Login
  v
Identity Provider
  |
  | SAML/OIDC authentication
  v
ServiceNow
  |
  | Validate identity
  v
ServiceNow session

Provisioning Flow

Identity Provider
      |
      | SCIM
      v
ServiceNow
      |
      +--> User
      +--> Group
      +--> User attributes
      +--> Activation status

Keeping these two flows conceptually separate is important.

SSO answers: “Who are you?”

Provisioning answers: “Should you have an account, and what identity information should ServiceNow know about you?”

Key Identity Management Components

1. User Records

The ServiceNow User table, sys_user, contains user identity information used throughout the platform.

Typical attributes include:

• User ID

• Name

• Email

• Department

• Manager

• Company

• Active status

• Authentication-related attributes

• Groups

• Roles

A common implementation mistake is to treat the ServiceNow user table as the master identity source.

In many enterprises, it should instead be treated as a downstream representation of the enterprise identity.

2. Groups

Groups are heavily used to organize users and drive access.

For example:

Rather than manually assigning every individual role, administrators can design group-based access models.

This makes employee movement easier to manage.

3. Roles

Roles determine what functionality users can perform.

Examples can include roles associated with:

• Incident management

• Change management

• Service catalog

• Knowledge management

• Administration

• Reporting

• Application-specific capabilities

A practical enterprise design usually avoids giving users administrative roles simply because they need access to a particular application.

The objective is to provide the smallest permission set required to perform the user’s job.

Real-World ServiceNow Identity Management Use Cases

Use Case 1 – Employee SSO

A company has 15,000 employees and wants users to access ServiceNow using their corporate credentials.

The company configures its identity provider and ServiceNow for SAML or OIDC-based SSO.

The user experience becomes:

Employee → Corporate Login → MFA → ServiceNow

The employee does not maintain a separate ServiceNow password.

ServiceNow supports Multi-Provider SSO and documents SAML and OIDC as supported identity-provider options.

Use Case 2 – Automated Joiner/Mover/Leaver

An employee joins the company.

The identity platform creates the account and provisions the user into ServiceNow.

Later, the employee moves from Finance to IT.

The identity governance process changes the employee’s group memberships.

Finally, the employee leaves.

The identity platform deactivates the identity and provisioning removes or disables ServiceNow access.

This avoids relying on manual administrator actions.

Use Case 3 – External Vendor Access

Suppose an organization uses external consultants for six months.

Instead of creating permanent accounts with broad privileges, the organization can create controlled identities with:

• Limited groups

• Limited roles

• Defined activation dates

• Appropriate authentication requirements

• Periodic access review

At the end of the contract, the identity should automatically become inactive.

This is especially important for organizations subject to compliance requirements.

Use Case 4 – Integration Service Accounts

A ServiceNow implementation may contain integrations with:

• Oracle Fusion Cloud

• Microsoft Entra ID

• HR systems

• Monitoring platforms

• ERP systems

• CMDB discovery tools

• External applications

These integrations frequently require machine identities or service accounts.

A service account should not be treated like a normal employee account.

It should have:

• A clearly defined owner

• A documented purpose

• Minimum required permissions

• Controlled credentials

• Rotation procedures

• Monitoring

• Deactivation procedures

ServiceNow’s current security capabilities also include machine identity management, while Access Management provides tools for analyzing access and permissions.

Prerequisites for ServiceNow Identity Management

Before configuring identity management, gather the following information.

Identity Provider Information

For SSO, obtain:

• Identity provider name

• Entity ID/issuer

• SSO URL

• Certificate

• NameID configuration

• User attribute mapping

• Logout configuration if required

For OIDC, obtain the required:

• Issuer

• Client ID

• Client secret

• Authorization endpoint

• Token endpoint

• User information endpoint

• Scopes

Provisioning Information

For SCIM, identify:

• Provisioning source

• ServiceNow instance URL

• Authentication mechanism

• SCIM endpoint

• User attribute mappings

• Group mappings

• Deactivation behavior

ServiceNow’s SCIM documentation states that SCIM can create, read, update, and delete users and groups, and its SCIM API works with the sys_user table for user resources.

Security Information

Define:

• Who owns identity management?

• Who approves access?

• Which groups map to which roles?

• What is the administrator population?

• What is the service-account policy?

• How frequently will access be reviewed?

• What happens when an employee leaves?

Step-by-Step: Configure SSO in ServiceNow

The exact screens can var