Brazil Platform security

brazil index.md
Raw file
  • Secure your instance -- Platform security provides capabilities to secure the instance.
  • ServiceNow Vault -- ServiceNow Vault provides a single location to review and implement data security tools, including encryption, data discovery and classification, anonymization, zero trust access, and log export, to protect sensitive data across its entire lifecycle.
  • ServiceNow Otto for Vault -- With ServiceNow Otto for Vault, you can generate custom data patterns, check role access for an encrypted column, and schedule data discovery jobs. ServiceNow Otto for Vault can make it easier for you to perform common tasks without going to multiple systems.
  • Platform Security -- Platform security provides capabilities to secure the instance.
  • Antivirus Scanning -- Use Antivirus Scanning to help protect your instance against virus infections that can be introduced by file attachments to your system records, such as incidents, problems, and stories.
    • Exploring Antivirus Scanning -- Use Antivirus Scanning to help protect your instance against virus infections that can be introduced by file attachments to your system records, such as incidents, problems, and stories.
    • Configuring Antivirus Scanning -- Configure Antivirus Scanning across your instance and at the table level.
    • Reviewing quarantined files -- Review quarantined file attachments and take further action as needed.
      • Review antivirus activity -- Review the Antivirus Activities log that tracks all activities that occur on potentially-infected files from the point that they are discovered and placed into quarantine.
    • Understanding Dictionary attributes -- Dictionary attributes alter the behavior of the table or element that the dictionary record describes. As an administrator, you can set the values of dictionary attributes to modify the behavior of the default Antivirus Scanning configuration.
  • HTML sanitizer -- Remove unwanted code and protect against security concerns such as cross-site scripting attacks by sanitizing HTML markup in HTML fields and translated HTML fields.
  • Auditing -- Track record changes on auditing-enabled tables. By default, the system tracks changes to the incident, change, and problem tables, among others.
    • Exploring Auditing -- Track record changes on auditing-enabled tables. By default, the system tracks changes to the incident, change, and problem tables, among others.
    • Configuring auditing for a table -- You can enable table auditing to track changes to all or some of the table's fields.
      • Enable inclusion list auditing for a table -- Enable a table to audit only those fields you explicitly designate. This is useful when you want to audit only a small number of fields in an audited table.
      • Enable impersonation tracking in audit logs -- Track users who perform actions through impersonation in audit logs.
      • Exclude a field from being audited (exclusion listing) -- Prevent the ServiceNow AI Platform from tracking a subset of fields in an audited table by excluding those fields from an audit.
      • Include a table field in auditing (inclusion listing) -- Track a subset of fields in an audited table by add those fields to an inclusion listing.
      • Enable auditing for a system table -- Deletions from tables with a sys_ prefix are not audited by default. To track deletions from these tables, add the table name to the glide.ui.audit_deleted_tables property. Enabling the Restore Deleted Records plugin adds several default values to this property.
      • Audit Management Console -- Use Audit Management Console module to experience a more enhanced way of defining and configuring the audit capability within your instance.
        • Setup your audit retention -- Use the Retention option to automate and simplify the deletion of audit data as per your requirement.
        • Enable an audit deletion estimate -- Enable the audit deletion estimation feature that calculates the approximate number of records that will be deleted based on retention policies. This information helps you make an informed decision before applying a retention policy, which permanently deletes audit data and cannot be reversed.
    • Viewing Sys Audit and Audit Relationship Change tables -- The ServiceNow AI Platform tracks inserts and updates to audited records in the Sys Audit (sys_audit) and Audit Relationship Change (sys_audit_relation) tables.
    • Knowing about History sets -- The system automatically generates History Set records as needed from the Audit table when a user either creates a record or views its history.
      • Differences Between Audit and History Sets -- The Audit [sys_audit], History Sets [sys_history_set], and History [sys_history_line] tables store the same data, but they serve different purposes and manage data differently.
      • Control access to history -- You can give a role access to view audit history by setting a system property.
      • Change the number of history entries -- By default, the history displays a maximum of 250 history entries, but you can change this value.
      • History List -- The history list displays each change as its own row in the change list.
      • History Calendar -- The history calendar shows you the days where the record was changed, who made the change, and when.
      • History Timeline -- You can view a timeline of changes for a CI and for its related records, relationships, baselines, and proposed changes for the CI. Timelines are available for CIs in the Configuration Item [cmdb_ci] table or a descendant of this table, if auditing is enabled for the tables.
      • Tracking changes to reference fields -- Administrators can track changes to reference field display values.
      • Tracking inserts -- By default, the system does not create Audit records for inserts because in a typical instance, inserts can account for over 80% of the size of the Audit table.
      • Tracking CI Relationships -- Changes to a CI relationship (CI Relations, CI/User Relations, or CI/Group Relations) appear in the history of the items on both sides of the changed relationship regardless of whether the change was manual or a result of Discovery.
    • Granular admin roles for Audit tables -- Granular admin roles replace broad admin access with targeted, feature-specific permissions. Use these roles to grant the administrative capabilities needed for specific tasks without assigning the admin role.
  • High Security Settings -- High Security Settings refer to several security options available in your instance.
  • Virtual Private Network (VPN) -- Use a virtual private network (VPN) to integrate your instance with external data sources over the Internet.
    • Exploring Virtual Private Network (VPN) -- Use a virtual private network (VPN) to integrate your instance with external data sources over the Internet.
    • Activating a VPN service -- For all VPN requests, including provisioning, modifications, or general questions, use the Service Catalog VPN Request form.
    • Configuring an address for VPN communication -- To prevent conflict or overlap with internal ServiceNow networks or with another customer's internal IP address schemes, the instance requires that all tunneled traffic in the encryption domain use non-RFC-1918 addresses on both sides of the tunnel.
  • Platform Privacy -- Privacy enables you to mask the sensitive date on the instance.
    • Exploring Data Privacy -- Use Data Privacy to classify sensitive data and to remove personally identifiable information (PII) from user data in a production instance and anonymize data in non-production instances. Once anonymized, the user data is no longer considered regulated private information.
    • Data Privacy -- Use Data Privacy to classify sensitive data and to remove personally identifiable information (PII) from user data in a production instance and anonymize data in non-production instances. Once anonymized, the user data is no longer considered regulated private information.
      • Data Privacy for ServiceNow Otto -- Set up and configure how to discover and anonymize sensitive data from generative AI prompts.
      • Data privacy for inbound emails -- The inbound email channel enables organizations to discover and mask sensitive data in inbound emails through the Data Privacy framework. This replaces the previous approach which used Active Data Patterns with a centralized, streamlined policy-based experience for managing sensitive data in emails.
      • Data Privacy for Virtual Agent -- You can use Data Privacy to detect and mask the sensitive data and PII during a Virtual Agent conversation.
      • Data privacy (Classic) -- Data privacy (Classic) is available as a family release. The last family updates were released in the Tokyo launch.
        • Activate data privacy (Classic) -- You can activate the data privacy plugin (com.glide.data_privacy) for Platform Security if you have the admin role. If the application doesn't include demo data or it doesn't install related applications and plugins, delete or revise the following sentence:The application includes demo data and installs related ServiceNow Store applications and plugins if they aren't already installed.
        • Installed with data privacy (Classic) -- Learn about the components installed with the data privacy plugin (com.glide.data_privacy).
        • Data privacy (Classic) configuration -- Learn how to create data privacy techniques and policies, and how to create and execute data privacy jobs.
          • Create a data privacy technique configuration -- Create a data privacy technique configuration to customize how data privacy anonymizes your data.
          • Create a data privacy policy -- Configure a data privacy policy to specify which data privacy techniques are used when anonymizing your data.
          • Configure a data privacy job -- Configure a data privacy job on your production instance to use anonymized data on your non-production instance for user and data class jobs.
          • Data privacy job rollback -- Database changes are captured for actions like jobs and scripts so that the changes can be rolled back. Roll back a data privacy job for when human error inadvertently anonymizes incorrect user information. The rollback de-anonymizes the data from the data privacy job.
            • Roll back a data privacy job -- Roll back a data privacy job on your non-production instance that uses anonymized data from your production instance to a state prior to de-identification of a data class or user job.
        • Data privacy clone -- As customer data are cloned from a source to a target instance, typically from production to non-production, sensitive data are de-identified on the target instance.​
          • Configure data privacy clone request -- Data privacy clone integration is configured using a PostClone script to create and execute data privacy jobs for configured policies on the target. After running the script, users will see de-identified data and will not have access to the original data.
        • Data Privacy Job Logs -- Review errors from Data Privacy jobs.
      • Data privacy -- The data privacy store app is a Next Experience refresh for data classification and data privacy with modern look, feel, and usability. Data privacy store app is supported in Utah and above.
        • Data privacy overview -- The Overview homepage is a starting point to manage your data and data privacy compliance.
        • Data classification -- Group data by type, using pre-defined or user-defined data classifications. If you have an assigned data classification administrator or auditor role, you can administer different data classes or visually analyze the current state of different types of data within the instance.
          • Create data classifications -- Create your own user-defined data classifications in the [data_classification] table that you can then assign to specific columns in specific tables. Create new data classes to start the classification process.
          • Classify data -- Group data by type, using pre-defined or user-defined data classifications. Assign data classifications to specific table columns in the Dictionary [sys_dictionary] table. When you assign data classifications, it creates entries in the Dictionary-Data Class [m2m_dictionary_dataclass] table, which you can then review in the Overview dashboard.
        • Data anonymization -- Anonymization provides a way to easily transform data so that it is unidentifiable and more compliant with data privacy regulations.
          • Create anonymization techniques -- Create a data privacy technique configuration to customize how data privacy anonymizes your data.
          • Create anonymization policies -- Configure an anonymization policy to specify which techniques are used when anonymizing your data.
            • Assign data anonymization techniques -- Assign anonymization techniques for data tables or columns, user specific data, or real time data.
            • Configure data anonymization clone request -- Data privacy clone integration is configured using a PostClone script to create and execute data privacy jobs for configured policies on the target. After running the script, users will see de-identified data and will not have access to the original data.
          • Create anonymization job -- Configure a data privacy job on your production instance to use anonymized data on your non-production instance for user and data class jobs.
          • Activate parallel jobs -- Use parallel jobs to reduce your anonymization job execution time.
          • Bring Your Own PII Detection Service -- Integrate your organization's PII detection service to discover and mask sensitive data during AI inference calls. Routing your sensitive data inline guardrails to an external service allows you to comply with legal requirements around AI & Data Governance.
        • Tokenization -- Tokenization masks sensitive data for unauthorized users using tokens, and stores a mapping of those tokens to the original data on the instance. Users with authorized roles can retrieve the original data by prompting within the ServiceNow Otto panel.
          • Create a tokenization policy -- Create a new tokenization policy to define which sensitive data should be anonymized through reversible tokenization.
          • Review de-tokenization job summaries -- View summaries of de-tokenization jobs, monitor access to original sensitive data, and review audit logs for compliance purposes.
        • Real time anonymization -- Use the real time anonymization(RTA) policy to anonymize data entries in real time.
        • Real time protection -- Analyze user input in real time at the field level to identify sensitive data and alert users about potential sensitive data entry.
          • Real time protection policies -- You can configure policies to protect sensitive data in real-time through alerts and blocking actions.
          • User sensitive data logs -- You can view the top 100 activity logs for specific real-time protection policies that contain the most sensitive data from the last month.
          • Alert data patterns -- Before you can define real-time protection policies, you must create your alert data patterns; reusable groups of data patterns that detect and then alert or block sensitive data across your organization.
          • Attachment quarantine policies -- Manage policies that automatically isolate suspicious attachments for security review and analysis.
          • Attachment scan findings -- You can review the findings of your attachment quarantine scans, and work with any quarantined or alerted attachments.
        • Activate data privacy -- Data Privacy includes data classification and anonymization and is installed from the ServiceNow Store.
      • Domain separation -- If any conrefs are broken, re-add them from the doc/source/reuse/domain-separation/domain-separation-overview.dita file. In the short description, edit the first sentence to state whether domain separation is supported or not and add the application name. Keep the conref at the end that describes domain separation.Domain separation is unsupported for data privacy. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.
      • Supported field types for anonymization -- Check which field types are supported when anonymizing data.
      • Data privacy roles -- Data privacy adds these roles.
      • Default data privacy configurations -- Data Privacy includes out-of-the-box default configurations that automatically activate for licensed Vault customers, providing immediate value without requiring setup. These configurations enable discovery of existing sensitive data and real-time alerting and user logs for new sensitive data entries in specific fields.
        • Default alerting policy for sensitive data entry -- The default alerting policy automatically detects sensitive data being entered into unstructured fields in real-time and alerts administrators, providing immediate visibility into sensitive data flows without requiring configuration.
        • Default data discovery job -- The Vault by Default data discovery job automatically runs on ServiceNow instances. It helps to identify sensitive data in primary sources, providing immediate value for trial and licensed Vault customers without requiring configuration.
          • Review default discovery job results -- After the default discovery job completes, review the findings to understand sensitive data exposure on your instance and plan protective measures.
    • Data Discovery -- Use Data Discovery to identify sensitive data within an instance, such as credit card information, emails, or social security numbers.
    • Data Classification -- Group data by type, using pre-defined or user-defined data classifications. If you have an assigned data classification administrator or auditor role, you can administer different data classes or visually analyze the current state of different types of data within the instance.
      • Exploring Data Classification -- Explore about data classification.
      • Installing plugin demo data -- When you upgrade to or install Brazil (and above), the Data Classification (com.glide.data_classification) plugin is automatically activated. However, you should manually install the demo data that comes with the plugin. It includes several important pre-defined data classifications, and it also assigns one of them to specific User [sys_user] table columns in your instance.
        • Components installed with Data Classification demo data -- When you upgrade to or install Brazil (and above), the Data Classification (com.glide.data_classification) plugin is automatically activated. However, you should manually install the demo data that comes with the plugin. It includes several important pre-defined data classifications, and it also assigns one of them to specific User [sys_user] table columns in your instance.
      • Creating data classifications -- Create your own user-defined data classifications in the Data Classification [data_classification] table that you can then assign to specific columns in specific tables.
      • Assigning data classifications to dictionary entries -- Assign data classifications to specific table columns in the Dictionary [sys_dictionary] table. When you assign data classifications, it creates entries in the Dictionary-Data Class [m2m_dictionary_dataclass] table, which you can then review in the Overview dashboard.
      • Analyzing data classifications -- The Overview dashboard reports the current state of data classifications within your instance and how your users are distributed by location.
      • Domain separation -- Domain separation is supported for Data Classification . Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.
  • Encryption -- Protect your sensitive data and stay compliant with regulatory  requirements and standards.
  • Access Management -- Access Management enables you to have access to ServiceNow instance securely.
    • Zero Trust Access -- Zero Trust Access (ZTA) is a security model in which no user or device is trusted by default.
      • ZTA -- Zero Trust Access (ZTA) is a security model that assumes that no user or device is trusted by default.
      • Activating ZTA -- Activate the Zero Trust - Policy Based Session Access com.snc.zero_trust_session_access plugin to enable security admins to reduce or limit user access in a session based on IP address, location, Identity Provider attributes, and user attributes using adaptive authentication policies.
      • Configure Session Access role -- Configure Session Access to reduce user access in a session based on IP, location, Identity Provider attributes, and user attributes using adaptive authentication policies.
      • System properties -- Use system properties to enable and customize Zero Trust Access to meet your security requirements.
        • Session Access Audits -- The Session Access Audits table displays the Session Access logs and information related to a user's session.
      • Use ZTA -- Use the Zero Trust Access feature with an end-to-end use case.
        • Configure IDP attribute for Session Access -- Use Identity Provider (IDP) attribute created from the Security Assertion Markup Language (SAML) response and OpenID Connect (OIDC) for removing or restricting user session access to the instance.
      • ZTA for Mobile -- Zero Trust Access (ZTA) is a security model that assumes that no user or device is trusted by default.
      • Continuous Authentication (CA) -- Continuous authentication in ServiceNow enables you to reverify and authenticate a user if they access resources that are protected by you.
        • Exploring CA -- ServiceNow's continuous authentication (CA) enables you to re-verify and authenticate a user if they access resources that are protected by you.
        • Pre-work for CA -- Perform the following pre-work before using Continuous Authentication (CA).
        • Activate CA -- To activate the Continuous Authentication feature on your instance, install the Zero Trust - Continuous Authentication (com.snc.zero_trust_continuous_authentication) plugin.
        • Configuring CA -- Configure continuous authentication (CA) policies to re-authenticate the users if there's an attempt to access resources that are protected by you.
          • Tutorial: Configure CA for a Table -- Procedure that describes end-to-end configuration of continuous authentication policy for a table and the impacts to the users due to the configuration changes.
          • Tutorial: Configure CA for a Data Class -- Procedure that describes end-to-end configuration of continuous authentication policy for a data class and the impacts to the users due to the configuration changes.
        • High assurance -- Establish a high assurance session with ServiceNow continuous authentication.
          • SSO login -- Establish a high assurance session for SSO login with ServiceNow continuous authentication.
          • Non-SSO login -- Establish a high assurance session for non-SSO logins (local or LDAP) with ServiceNow continuous authentication.
        • Audit logs -- Describes the details about Continuous Authentication (CA) logs. The CA logs display all the authentication attempts performed by the users.
    • Domain separation for service providers -- With the ServiceNow Platform, service providers (SPs) can provide their customers with faster onboarding, meet compliance, and protect their data using domain separation. You can separate client data, processes, and reports into logical groupings called domains. SPs control who sees and accesses what content.
      • Exploring domain separation -- With domain separation you can separate data, processes, and administrative tasks into logically defined domains.
        • Delegating configuration options to customers -- Domain separation is designed to give ServiceNow service providers (SPs) the ability to configure the services they offer to their customers. It is not designed to enable their customers to administer those services themselves, except in a few areas that this topic details.
        • Domain assignment -- By default, domain separation adds a domain field to tables and their extensions.
        • Visibility domains and Contains domains -- Visibility domains control what a specific user or group of users can see. "Contains" domains control what an entire domain of users can see.
        • Domain scope -- Domain scope defines what users can and cannot access.
        • Concepts for service providers -- These concepts work with the existing ServiceNow platform capabilities to help you solve for common use cases.
          • Global queue v.2 -- The global queue concept provides a single virtual view of tasks that reside in multiple instances. The concept creates a custom application to provide a fulfiller view of work that resides in multiple instances without having to replicate tasks or data.
          • Service provider connector -- The service provider connector application is a reference design for creating a ServiceNow Store application for your customers to use to integrate with your systems. Service provider applications help you speed on-boarding and create standardized integrations.
        • Installed with domain separation -- Several platform components are added or modified with domain separation.
      • Application support for domain separation -- Many ServiceNow applications support domain separation in the base system but not all. Some supported applications include limitations on the data and administrative settings that can be domain-separated. These definitions delineate the domain separation support levels from the perspective of actual use cases and the people who use them.
      • Recommended practices for service providers -- You can create, implement, and maintain domain separation for your applications and services.
        • Domain separation explained -- With domain separation, you can segregate application data, UI, and business logic, such as rules or workflows, in a single customer instance. Separating these elements into logically defined domains supports specific hierarchies for all customers using your applications.
          • Value proposition -- With domain separation, service providers can have a multitenant instance architecture that delivers offerings efficiently and securely to their clients. Strong universal process standards, data-driven process design, strict governance, and centralized administration help to maximize these benefits.
          • Definition of domain separation -- With domain separation (also known as the ServiceNow Multitenant Platform Architecture), you can segregate application data, UI, and business logic in a single customer instance that supports hierarchical modeling with cross-tenant (customer) intelligence.
        • Domain separation hierarchies -- Create a hierarchy when defining a domain architecture to track your processes and workflows.
        • Context and domain separation -- The context of a user's session determines the processes, data, and user interface (UI) as the user browses through list views, home pages, reports, and knowledge articles. The context is determined by the processes that you create, the business rules that you set, your workflows, and other factors.
        • Segregating and securing data -- You can segregate and secure data on the ServiceNow platform in multiple ways, depending on your customer's needs. 
          • Cross tenant intelligence -- A multi-tenant architecture is where you have a single instance serving multiple tenants. Data, metadata, business logic, and processing context for tenants is automatically handled with access to additional tenant data.
        • Alternatives to domain separation -- You can use a separate instance as an alternative to domain separation for your customers. A separate instance allows you the flexibility to meet the requirements for data separation within the groups and departments in an organization with little to no impact on others.
        • Evaluating the need for domain separation -- You may find that domain separation doesn't always work for your customers' organizations. It's best that you base your decision to go with domain separation by looking at your customers' needs.
        • Benefits of domain separation -- Domain separation may work better for your customers' organizations than any other method for separating the data between groups and departments.
        • How a database query works with domain separation -- Using database queries with domain separation in your customers' applications help them protect their data. These queries then speed up the configuration and build processes.
        • Domain separation levels of support -- Choose from three categories for domain separation of an application for your customers' organizations.
        • Service provider reference architecture -- Your customers can access service provider (SP) services by using a portal that is designed for them to reach their domain-separated instance.
          • Decision trees -- You can use decision trees and a comparison chart to determine if a new customer should be added to a shared instance or to their own dedicated instance.
          • Dedicated instances -- Service provider (SP) customers can access SP services by using a portal to a dedicated instance. SPs use these dedicated instances to manage their service delivery.
          • Hybrid solution -- Use the hybrid service provider (SP) reference architecture for a customized solution. Your customers require a dedicated instance for a specific service. They can still use the shared SP instance for other services, but it requires integration of each instance.
          • Service Integration Management (SIAM) -- The Service Integration Management Service Integration and Management (SIAM) for service provider (SP) architecture integrates services for a unified customer experience.
        • Domain separation terms -- With a ServiceNow instance, you can improve efficiency, add greater security, and increase performance for your customer organizations. It's helpful to understand some of the most common terms as you create your configurations.
        • Domain-separate a custom table -- You may need to create custom tables in separate domains. This topic covers both the procedure and the concept behind domain-separating a custom table.
        • Customizing domain properties and themes -- You can customize your customers' company properties and themes within the domains that you have configured. Customization makes their instances fit in with their companies' overall look and feel.
        • Managing domain separation for specific uses -- You can set up separate domains for email notifications and customize the properties of catalog, tables, users, groups, and views. This enables you to provide more specific behavior in each domain, giving your customers more flexibility.
        • Configuring domain separation with the domain picker -- Use the domain picker wisely, and remember the 80/15/5 approach so that you do not customize too much and impact the performance of your instance.
        • Performance considerations -- As you configure domain separation in your application and services, make sure that you consider the number and properties of domains you create. Too many property-heavy domains can impact the performance of your instance.
        • Setting up domain hierarchies -- You can avoid slowdowns and performance impacts in your instance by knowing how domain hierarchies work and by setting them up properly.
        • Checking domain logs for errors and warnings -- Check the domain logs to find errors or warnings in your domain path processes and hierarchy configurations.
        • Importance of the Default domain -- Organizing your domains is a crucial part of the domain separation process. If you don't set a default domain, new tasks and user records go to the global domain. Anyone can see the records in the global domain, which means that data can be seen when it is not supposed to.
        • Contains queries and domain access -- Use a "contains" query only in special cases, such as when users or groups need to see data from a domain that they don't have access to, but you don't want to move those users to a domain. Creating domain "contains" and user or group access for a domain should be an exception, only when absolutely needed.
        • Domain paths query method -- You can create effective queries with domain paths.
        • Slow queries and SQL debugging -- Debugging SQL and slow queries can help you resolve slowness issues in an instance.
        • Before Query business rules -- You can use a Before Query business rule to help support data segregation on an instance. ServiceNow applications that support domain separation may support the separation of data and data routing only, have advanced business logic separation, or support tenant (customer) level administration of the application.
        • Avoiding domain path in scripts -- Domain paths can cause the values of your script to change or even break, so don't use them in scripts.
        • Domain assignments -- How you assign a domain impacts the value of the sys_domain field. The assignments contain designs and business properties that affect how the application functions in each domain.
        • CSM plugin -- For the best outcome, be aware of how the properties in the CSM plugin work. When the plugin is enabled, you can see the status of your records in your domains.
      • Domain Separation Help -- Additional assistance with Domain Separation
      • Setup and administration -- Setting up domain separation involves requesting activation of a plugin, setting options, and assigning users and records to domains.
        • Request domain separation -- All domain support features are activated with a plugin called Domain Support - Domain Extensions Installer. Administrators can request activation of this plugin.
        • Domain separation plugin -- The Domain Support - Domain Extensions Installer plugin activates several domain separation features and properties at once. This plugin is typically referred to as the Domain Separation plugin.
        • Domain system properties and user preferences -- Administrators have access to properties and user preferences that control domain scope.
        • Create a domain -- You can create a domain by creating a record in the [domain] table.
        • Make a domain the default -- Made a domain the default domain to which the system automatically assigns task and user records that are not already assigned to a domain.
        • Manually manage the domain for particular records -- By default, the system automatically assigns a domain based on the user's company record. In some cases, however, domain administrators want to manually manage which domain a particular record belongs to.
        • Domain Separated Tables -- You can see at a glance which tables are domain-separated in your instance with the Domain Separated Tables feature.
        • Domain Override Viewer -- With the Domain Override Viewer, you can see and manage all your process overrides at once across the entire instance.
        • Enable or disable a domain -- When you activate or deactivate a domain, the activation status cascades to companies within the domain.
        • Add a domain field to a table -- As an administrator, domain-separate a custom table by adding a sys_domain field to it.
        • View domain relationships -- The domain map offers domain administrators a read-only representation of the active domains on the instance and how they relate to each other.
          • Select a primary domain -- The primary domain indicates the top-level domain in the domain map.
          • Create Contains relationships between domains -- Create a "contains" relationship between domains to change the domain hierarchy.
          • Expand domain scope -- By default, when a user in the global domain views a table containing a sys_overrides column, the user sees records from only the global domain. When an admin in the global domain views a process table, that admin sees only records that are in that process table.
            • Add domains to a visibility domains list -- Adding a visibility domain allows a user or group to see and potentially edit records from another domain regardless of the user or group's normal domain membership.
            • Grant visibility domains to an individual user -- While it is possible to add visibility domains for specific users on the User form, it's best to add them only via groups. This controls permissions and access should individuals change departments or leave the company.
        • Create a domain-specific choice list -- Administrators can configure choice lists to contain entries specific to a particular domain.
        • Advanced administration -- Administrators can view information about domain separation, identify potential issues, and change configuration settings.
          • Use domain selection menus -- The instance offers domain selection via two menu formats.
          • Application properties -- The Domain Separation plugin has two new tables to give service providers more flexibility in customizing their applications that use domain separation. These tables are the System Application Property table [sys_application_property] and the System Application Property Value table [sys_application_property_value].
        • Domain Migration Tool -- Use the Domain Migration Tool to move a customer from a domain-separated environment to their own dedicated instance.
        • Process administration -- Process administration allows administrators to set domain-specific policies.
        • Enable logging and debug messages -- Domain log and debug messages allow you to troubleshoot domain configuration errors.
        • Post-Production Domain Separation Activation Utility -- The post-production Domain Separation activation utility aids in the activation of Domain Separation in a live environment.
        • Domain Job Management -- Queue multiple Domain Separation updates sequentially into a single background job using the Domain Job Manager.
        • Delete by domain -- Clean up inactive leaf level domains in the domain hierarchy with a controlled and automated tool.
      • Domain Separation Center -- Audit your domains regularly to reveal problems.
    • Authentication -- ServiceNow's authentication validates the identity of a user who accesses an instance, and then authorizes the user to features that match the user's role or job function.
      • Adaptive authentication -- Use the Adaptive authentication policy framework to enforce contextual authentication controls to the right users at the right time. Adaptive authentication uses authentication policies to evaluate authentication requests and then either deny or allow access to your instance based on the specified policy conditions.
        • Activate adaptive authentication -- You can activate the Adaptive Authentication plugin (com.snc.adaptive_authentication) for Adaptive Authentication if you have the admin role.
        • Filter criteria -- Filter criteria (also called policy inputs) are used as inputs for policy conditions to verify and meet the requirements of an authentication request.
          • IP filter -- Use IP filter criteria to filter the users based on the user's IP addresses. Both IPv4 and IPv6 are supported.
            • Create IP filter criteria -- IP filter criteria enables you to filter users based on the user's IP addresses. You can configure an authentication policy to allow or deny access to a specific address or range of addresses.
          • Role filter -- Use role filter criteria to filter users based on their roles.
            • Create role filter criteria -- Role filter criteria enables you to filter users based on the roles. You can configure an authentication policy to allow or deny access to a list of user roles.
          • Group filter -- Use group filter criteria to filter users based on the user group to which the user belongs.
          • Location filter -- Location filter criteria can be used as filter input for users based on the user location.
          • Identity provider attributes filter -- Use the Identity Provider attributes that are received from the Security Assertion Markup Language (SAML) response and OpenID Connect (OIDC) from the Identity Provider (IdP) as filter criteria for authentication.
            • Attributes for SAML -- Use the Identity Provider attributes that are received from the Security Assertion Markup Language (SAML) response and OpenID Connect (OIDC) from the Identity Provider (IdP) as filter criteria for authentication.
              • Use as filter criteria for SAML -- Use the Identity Provider (IDP) attribute from the Security Assertion Markup Language (SAML) response as a filter criterion for authentication policy.
            • Attributes for OIDC -- Use the Identity Provider attributes that are received from the OpenID Connect (OIDC) from the Identity Provider (IdP) as filter criteria for authentication.
              • Use as filter criteria for OIDC -- Use the Identity Provider (IDP) attribute from the OpenID Connect (OIDC) response as a filter criterion for authentication policy.
        • Authentication policy contexts -- Use authentication policy contexts to determine how and when your instance enforces authentication policies.
          • Pre authentication context -- The pre authentication policy context defines how and when a policy is enforced during the login process. The policy used in this context executes before your users see a login screen.
          • Post-authentication context -- The Post Authentication policy context defines how and when a policy is enforced during the login process. The policy used in this context executes after your users see a login screen.
          • MFA context -- The Multi-factor Authentication (MFA) policy context uses a policy to define how and when MFA is enforced during the login process.
          • Account recovery context -- The account recovery context uses a policy to define how and when the account recovery can be established.
          • Session validation context -- Use the Session Validation Context as an additional layer of protection against session or cookie hijacking.
            • Activate session validation context -- Use session validation context to restrict access to ServiceNow when hijackers copy a user's session cookies from one device to another to impersonate the session or restrict the user's session access if they’re using an insecure network.
            • Configure session validation -- Configure session validation within the Adaptive Authentication framework to provide an additional layer of protection for session or cookie hijacking.
        • Authentication policies -- Authentication policies evaluate authentication requests based on the specified policy conditions and either allow or deny access depending on the output of policy conditions evaluation. For example, access is allowed only if all the policy conditions specified in Allow Access Policy evaluate to true.
          • Configure a policy -- Configure an authentication policy to define inputs and conditions to use to grant access to an instance or enforce multi-factor authentication.
          • Add to an authentication policy context -- Add an authentication policy to one of the authentication policy contexts. The authentication context uses the policy inputs and conditions to determine whether users are granted access to the instance, or whether MFA is enforced for your users.
        • Adaptive authentication events -- You can use the adaptive authentication events table to learn about the events.
        • Configure properties -- After activating adaptive authentication, configure adaptive authentication properties according to your security requirements.
        • Adaptive authentication for Trusted mobile apps -- Access your ServiceNow from untrusted networks by using the Now Mobile app.
      • API authentication -- Authentication configurations for API.
        • Certificate based authentication -- Certificate-based authentication lets you mutually authenticate inbound API requests using certificates from a trusted certificate authority (CA).
        • OAuth -- OAuth based authentication validates the identity of the client that attempts to establish a trust on the system by using an authentication protocol.
        • Token-based authentication -- Token-based authentication for inbound REST APIs configuration using API Key or HMAC.
        • Basic authentication -- Legacy API authentication method using username and password, with restricted usage and varying behavior in zBoot and upgraded instances.
          • Basic authentication restriction -- Basic authentication restriction is a security feature that controls which accounts can use basic authentication on a ServiceNow instance. Administrators can review identified users and assign per-account decisions before enforcement begins.
          • Basic authentication exceptions -- The Basic Auth Exceptions table lists accounts that have been identified as using basic authentication on the instance, along with their assigned decision and usage details.
      • API access policy -- API access policy defines the permissions and duration of access to an API.
        • REST API access policies -- REST API access policies enable you to restrict access to inbound REST APIs based on the authentication type and the specified filter criteria of the access policy.
          • Activate REST API access policy -- You can activate the REST API Access Policy plugin (com.glide.rest.policy) if you have the admin role. If the application does NOT include demo data or it does NOT install related applications and plugins, delete or revise the following sentence:The application includes demo data and installs related ServiceNow Store applications and plugins if they are not already installed.
          • Create an authentication profile -- Create an authentication profile and add one or more authentication policies to the profile. You can also configure the ID Token and OAuth Token authentication profiles that are available by default.
          • Create REST API access policy -- Create an API access policy and map an authentication profile to restrict the authentication type for a REST API. For example, you can create an API access policy that allows only ID token authentication for a REST API.
            • API access policy prioritization -- Learn about the policy prioritization logic if there are multiple API access policy configured for your ServiceNow instance.
          • REST API Auth Scope -- Use the REST API Auth Scope to provide access to a specific REST API
            • Activate REST API Auth Scope -- You can activate the REST API Auth Scope plugin (com.glide.rest.auth.scope) to link the OAuth entity with authentication scopes.
            • Properties and tables -- The REST API Auth Scope plugin (com.glide.rest.auth.scope) includes the following system properties, tables, and scripts.
            • Configure auth scope -- Link the OAuth entity with an auth scope to manage the token to access the REST APIs that are linked with the auth scope.
            • Troubleshooting -- Troubleshooting actions can help resolve common issues when setting up or running the REST API scope.
        • SOAP API access policies -- SOAP API access policies allow you to restrict access to inbound SOAP APIs based on the authentication type and the specified filter criteria of the access policy.
          • Activate SOAP API access policy -- For SOAP API access policy, install the SOAP API Access Policy (com.glide.soap.policy) plugin.
          • Create an authentication profile -- Create an authentication profile and add one or more authentication policies to the profile. You can also configure the ID Token and OAuth Token authentication profiles that are available by default.
          • Create SOAP API access policy -- Create an API access policy and map an authentication profile to restrict the authentication type for a SOAP API. For example, you can create an API access policy that allows only ID token authentication for a SOAP API.
          • Filter criteria for APIs -- Filter criteria contains filter conditions or queries that are used as policy inputs for an authentication policy. Policy inputs are used to group one or more filter criteria and define the policy conditions of an authentication policy. For example, IP filter criteria define an IP address in the Classless Inter-Domain Routing (CIDR) format or a range of IP addresses.
        • API authentication policies -- Authentication policies evaluate authentication requests based on the specified policy conditions and either allow or deny access depending on the matching criteria.
          • Create a policy -- Authentication policies enables you to enforce access restrictions on the APIs based on the specified filter criteria.
          • Configure global blocking policy for APIs -- Global blocking policy denies the authentication requests of users and APIs based on the specified policy conditions. This policy can be used as an alternative to the IP Address Access Control.
        • System or Export Processors -- System or Export Processors can use processor access policy to secure all the export endpoints.
      • Authentication factors -- Authentication factors help identify and verify callers, allowing only authorized users to access AI voice agents on the ServiceNow AI Platform.
        • Authentication factors for AI voice agents -- Authentication factors verify caller identity before granting access to AI voice agents. Combining multiple factors helps confirm that only authorized users interact with AI voice agents.
        • Authentication factor configuration for AI voice agents -- To secure voice agent environments, configure authentication factors that first identify the caller, then authenticate them before granting access.
          • Configure voice input for authentication factors -- Configure how callers provide authentication responses by speaking or using the phone keypad.
          • TOTP authentication -- A time-based one-time password (TOTP) is a secure authentication factor that verifies user identity by generating a unique, time-sensitive code.
          • Push notification - Okta Verify -- The Okta Verify app push notification enables users to securely approve authentication requests directly on their enrolled mobile devices.
          • Soft PIN authentication -- Soft PIN is a six-digit numeric PIN that verifies a caller's identity during an AI voice agent session.
            • Configure Soft PIN -- Users are required to configure Soft PIN before it can be used for authentication with ServiceNow AI Platform.
          • Step-up authentication -- Step-up authentication requires a caller who is already authenticated to complete an additional challenge before reaching an AI voice agent that handles a sensitive request.
            • Configure step-up authentication -- Configure step-up authentication to require an additional challenge before callers reach AI voice agents that handle sensitive requests.
          • SMS OTP authentication -- SMS one-time password (OTP) authentication is a method used to verify user identity by sending a temporary, numeric code to the user's registered mobile number. The user enters this code to complete authentication.
          • Email OTP authentication -- Email OTP for AI voice agents sends a one-time numeric code to the caller's email address. The caller retrieves the code from their email and provides it to the agent to verify their identity.
            • Configure Email OTP -- Configure the Email one-time password (OTP) to enable OTP-based authentication for users in your instance.
          • Knowledge-based authentication -- Knowledge-based authentication (KBA) is an identification and authentication method that verifies callers by prompting them to answer preconfigured questions across conversational AI channels, such as AI voice agents. KBA can be used to identify a caller, authenticate a caller, or both within the same interaction.
            • Configure KBA -- Configure knowledge-based authentication (KBA) to identify and authenticate callers by prompting them to answer preconfigured questions across conversational AI channels, such as AI voice agents.
        • Human-assisted SMS OTP authentication -- Human-assisted SMS OTP lets a human agent verify an end user's identity by sending a one-time passcode through SMS during a live interaction. The agent initiates OTP generation and validation through the platform's scriptable APIs, and the consuming application (for example, CSM or FSO workspace) handles the agent-facing workflow and user interface.
          • Configure human-assisted SMS OTP -- Configure the HA SMS OTP service to enable human agents to generate and validate one-time pass codes during live interactions.
      • Certificate-based authentication -- Certificate-based authentication lets you mutually authenticate user logins or inbound API requests using certificates from a trusted certificate authority (CA).
        • Set up -- Set up mutual authentication for either user interface-based logins or inbound web services.
          • Activate Certificate-based authentication -- You can activate the Certificate-based authentication plugin (com.glide.auth.mutual) for ServiceNow AI Platform if you have the admin role.
          • Register CA certificate -- Register root certificates or intermediate certificates to make them available for authentication.
          • Map PEM certificate to user -- Map Privacy Enhanced Mail (PEM) certificates to users to enable them to log in using personal identity verification (PIV) or Common Access Card (CAC) or to authenticate inbound requests. You can map multiple PEM certificates to a user.
          • Configure Certificate-based authentication properties -- Use system properties to enable or disable certificate-based authentication features.
        • Log in -- After your administrator sets up certificate-based authentication, you can register the client certificate and log in using your PIV (Personal Identity Verification) or CAC (Common Access Card) card.
          • Register client certificate for your PIV or CAC card -- After your administrator sets up certificate-based authentication, you can register the client certificate and log in using your PIV (Personal Identity Verification) or CAC (Common Access Card) card.
          • Log in to ServiceNow AI Platform using PIV or CAC card -- After your administrator sets up certificate-based authentication, you can register the client certificate and log in using your PIV (Personal Identity Verification) or CAC (Common Access Card) card.
          • Manage your client certificates -- After your administrator sets up certificate-based authentication, you can register the client certificate and log in using your PIV (Personal Identity Verification) or CAC (Common Access Card) card.
      • Custom instance URLs -- You can enable your ServiceNow instance to be accessible from a company-branded or custom URL.
        • Activate custom URLs -- Enable custom URLs to be set up on your ServiceNow instance. You can activate the Custom URL plugin (com.snc.customurl) if you have the admin role.
        • Set as the instance URL -- Add a custom URL to your instance configuration to use instead of your ServiceNow URL.
        • Identity Provider -- Set your custom URL with the Identity Provider to enable the user to log in with their IdPs.
        • Datacenter job information -- Every custom URL that is associated to your instance has a corresponding ServiceNow datacenter job which runs and shows URL information that is pertinent to your instance as described in the table.
        • Generate SP metadata for SAML/SSO -- A SAML or SSO installation needs the SP metadata generated for the IdP before the custom URL instance generates.
        • Custom URL errors and fixes -- A list of common errors and associated fixes for a custom URL setup and configuration.Target Audience: ServiceNow Admin
      • External authorization servers for the ServiceNow MCP Server -- Register an external authorization server, such as Microsoft Entra ID or Okta, as a trusted token issuer for the ServiceNow MCP Server, so that MCP clients can authenticate using tokens issued by your enterprise identity provider.
      • Installation exits -- Installation exits are customizations that exit from Java to call a script before returning back to Java.
      • IP range based authentication -- One way to secure a web-based application is to restrict access based on the IP address.
        • IP address access control -- Apply an IP access control to outbound traffic, inbound traffic, or bidirectional traffic. The system only blocks an IP address if a matching Deny rule exists and no matching Allow rule exists. By default, there are no restrictions on access to your instance.
        • Find denied IP addresses -- Find Denied IP addresses in the instance's node log files.
      • LDAP integration -- An LDAP integration allows your instance to use your existing LDAP server as the primary source of user data.
        • Understand LDAP integration -- An LDAP integration allows your instance to use your existing LDAP server as the primary source of user data.
        • LDAP integration requirements -- Review the requirements for LDAP integration, which include a PKI certificate an LDAP compliant directory services server.
        • LDAP integration setup -- Administrators can enable LDAP integration to allow sign-on of users from their company LDAP directory.
        • Import and map data -- LDAP import maps match fields in your LDAP database to fields in your instance.
        • LDAP integration troubleshooting -- If you are integrating your LDAP server and have questions, these items may help you troubleshoot the issue.
          • View the LDAP monitor -- You can view current information about LDAP servers and listeners using LDAP monitor.
          • LDAP error codes -- The LDAP Log file lists industry standard error codes for both LDAP and Active Directory (AD).
          • Send a one-time password when the LDAP server is down -- An LDAP property is available to send a one-time password to a user if the user is unable to log in because the LDAP server is down. You can also configure another property to control how long the password is valid.
        • LDAP record synchronization -- Administrators can synchronize inactive, disabled, or deleted LDAP records with their LDAP records.
          • LDAP refresh filters -- Filters on the LDAP refresh process can be used to specify processing that ignores inserts of disabled users.
          • LDAP extraction -- Implement an LDAP extraction process to detect inactive users.
          • Inactive LDAP user accounts -- Detect that an existing, current, user account is inactive or has been disabled or deleted from an Active Directory (AD) LDAP.
          • LDAP script examples -- The following script examples assume you use an Active Directory (AD) for your LDAP server.
        • Active Directory Application Mode (ADAM) -- Active Directory Application Mode (ADAM) is an Lightweight Directory Access Protocol (LDAP)-compliant directory service.
          • Configuring an instance -- The first install copies the ADAM files to your computer, registers requires components, and creates the application shortcuts.
          • Set up the ADAM console -- Set up the ADAM console. Even though there are many similarities between ADAM and Active Directory, the administration can be very different since there is no Users and Computers management console.
          • Create containers and organizational units -- Logically group objects stored in ADAM into containers and organizational units (OU) just as they would be in Active Directory.
          • Delegation with ADAM -- Once the OU structure is created, define the permission delegations to properly secure the objects to limited users.
          • Populating ADAM Objects -- ADAM Objects include User Objects, UserProxy Object, and Group Objects.
          • Testing and troubleshooting -- The primary tool used for testing is LDP. This allows you to fully test user authentication.
          • Backup and recovery -- All ADAM data can be backed up using standard file system backup methods.
          • Use LDAPS with ADAM -- The default configuration for userProxy object authentication is to enforce LDAPS (secure LDAP) communications. LDAPS requires SSL certificates to secure the network traffic.
            • Assign the certificate to ADAM -- Install an SSL certificate on the server and any LDAP client to support secure binds and encrypt the user and password information being transmitted.
            • Export the public key certificate -- LDAPS clients, including the instance need the public key certificate in order to make a secure connection to ADAM.
          • ADAM access account -- The system requires a user account to read the Active Directory Application Mode (ADAM) object information that is imported into the application instance.
          • Test the LDAPS connections -- Test the LDAPS connections. There are two console connections, one for Local Computer Certificates, and the other for Local Computer Services Certificates on the new ADAM service.
          • Use ADAMSync to populate ADAM -- Administrators use MS ADAMSync to populate LDAP directories that use MS ADAM.
        • Configure Microsoft AD for secure LDAPS communication -- Use certificate pairs to enable Microsoft Active Directory (AD) LDAPS communications.
        • LDAP global catalog usage -- A DC can be granted the Global Catalog (GC) role. Global Catalog (GC) role is an LDAP-compliant directory consisting of a partial representation of every object from every domain within a forest.
        • OpenLDAP minor schema modification -- In OpenLDAP 2.3 systems that use the back-bdb (Berkley backend), administrators make a minor modification to their schema to facilitate the integration.
          • Modify the schema -- Modify the OpenLDAP schema. These steps detail a schema modification to OpenLDAP 2.3 provided by one of our customers that helped them integrate with their instance.
        • Record LDAP deletions -- By default, the instance does not delete any entries after they disappear from LDAP.
      • Concurrent session limits -- You can limit the number of concurrent interactive sessions for a user or role on an instance across all nodes.
        • Concurrent session limits -- You can limit the number of concurrent interactive sessions for a user or role on an instance across all nodes.
        • Configure the plugin -- You can activate the Limit Concurrent Sessions plugin (com.glide.limit.concurrent.sessions) if you have the admin role.
        • Set a limit by user or role -- You can set a concurrent session limit on a specific user or on a particular role.
        • Disable a limit by user or role -- You can disable a concurrent session limit on a specific user or on a particular role.
      • Local authentication -- Use ServiceNow local authentication to secure user login on a local device.
        • Login and authentication security -- Configure login security options to control access to your instance.
        • Define login scenarios -- You can direct all users to the same page after login.
          • Employee self-service portal -- The system keeps track of the first starting page that a user is trying to access even if the user wants to log in to the Employee Self-Service Portal.
          • Specify a login landing page -- By default, users see their homepage on login. You can specify a different login landing page by using a system property or the content management system.
          • Specify lockout for failed login attempts -- The system provides inactive script actions that enable you to specify the number of failed login attempts before a user account is locked and to reset the count after a successful login.
          • Make UI pages public or private -- You can make pages public if you want your users to see the pages without logging in.
        • Password complexity requirements -- Passwords in your ServiceNow instance must meet complexity requirements.
        • Password Reset -- The default self-service Password Reset process enables a user to reset the password without assistance from service desk agents.
          • Modify notification email -- Users of the self-service Password Reset process receive an email notification when they request password reset. You can modify the text of the email and other aspects of the notification.
          • Configure properties -- You can specify properties that configure the Password Reset experience for end users.
        • Remember me -- When the Remember me check box is selected at login, a cookie is stored on the user's computer. This cookie automatically authenticates the user upon subsequent visits.
          • Change the default value of the Remember me check box -- When the Remember me check box is selected at login, a cookie is stored on the user's computer. This cookie automatically authenticates the user upon subsequent visits.
          • Remove the Remember me check box -- When the Remember me check box is selected at login, a cookie is stored on the user's computer. This cookie automatically authenticates the user upon subsequent visits.
        • Configure the logout confirmation prompt -- You can enable a logout confirmation prompt to prevent users from inadvertently logging themselves out.
        • Implement a nonce -- You can implement a nonce to be used with single sign-on digest authentication.
          • Nonce process flow -- When a customer has implemented the digested token Single Sign-on and wishes to add the security of a nonce, they follow a certain process flow.
          • Implement a nonce -- Add a cryptographic nonce to the authentication header for custom digest-based Single Sign- On (SSO) to confirm that each authentication token is valid for one use only. This implementation requires ServiceNow developer expertise.
      • Multi-factor authentication -- Learn how to activate, use, and configure Multi-factor authentication (MFA).
        • MFA enforcement -- MFA is enforced for non-SSO logins to ServiceNow starting with the Yokohama release.
        • Exploring MFA -- Multi-factor Authentication (MFA) is an authentication method that requires users to provide information other than their basic credentials.
        • Configuring MFA -- Configure multi-factor authentication (MFA) to improve your users' security posture when using ServiceNow.
          • MFA context -- The Multi-factor Authentication (MFA) policy context uses a policy to define how and when MFA is enforced during the login process.
          • MFA verification methods -- ServiceNow MFA supports verification methods such as authenticator app, Fast IDentity Online 2 (FIDO2) and time-based one-time password (TOTP).
          • MFA system properties -- Use system properties to enable and customize MFA to meet your security requirements.
          • MFA criteria -- Use MFA criteria to determine which users and roles must use two-step verification.
          • MFA with SSO -- You can use MFA with an SSO provider for your ServiceNow instance.
          • Reset MFA for users -- Administrators can reset MFA for users who deleted the app, lost access to the device, or have no alternative MFA associated with their device.
          • MFA References -- Lists each user's multi-factor authentication setup, browser fingerprints, and recently used factors.
          • MFA metrics -- View the different MFA metrics to understand the MFA adoption and usage.
        • Using MFA -- Learn how to use multi-factor authentication tools to securely access your instance.
        • MFA Dashboard -- View the different MFA metrics to understand the MFA adoption and usage.
          • User Metrics -- User Metrics displays the user MFA enrollment trends on ServiceNow.
          • Log in Metrics -- Log in Metrics displays the log in trends on the ServiceNow.
          • MFA Guided Setup -- Use the MFA Guided Setup to step through the initial configuration of the MFA module and understand the requirements for MFA enforcements.
      • Multi-Provider single sign-on (SSO) -- External SSO allows organizations to use several SSO identity providers (IdPs) to manage authentication as well as retain local database (basic) authentication.
      • Authentication Console -- The Authentication Console enables administrators to configure and manage authentication behavior across a ServiceNow instance, including identifier-first login policies and related settings.
        • Policy-based login experience -- The policy-based login experience routes each user to the appropriate authentication method based on administrator-defined policies, using an identifier-first login flow.
          • IFL policies -- Identifier-first login is the framework the policy-based login experience currently uses. Identifier-first login policies, evaluated through the policy-based login experience, determine how the instance routes a user to an authentication method after the user enters an identifier.
          • Policy evaluation order -- The instance evaluates identifier-first login policies in order and applies the first policy whose conditions match the user.
        • Activate the policy-based login experience -- Activate the policy-based login experience so that you can create and manage the identifier-first login policies that drive the policy-based login experience.
        • Use the IFL policies -- Use the identifier-first login policies to view, build, order, and maintain the authentication methods that route users in the policy-based login experience.
          • Manage IFL policies -- Create, edit, activate, deactivate, and delete the identifier-first login policies that drive the policy-based login experience.
            • Create an IFL policy -- Create an identifier-first login policy to route users to an authentication method based on conditions such as IP address, role, or group.
            • Activate or deactivate an IFL policy -- Control whether an identifier-first login policy is included in policy evaluation by activating or deactivating it.
            • Edit an IFL policy -- Modify the conditions, authentication method, or evaluation order of an existing identifier-first login policy.
            • Delete an IFL policy -- Permanently remove an identifier-first login policy from the Authentication Console.
        • Authentication Console settings -- Settings on the Settings tab of the Authentication Console control whether the policy-based login experience is active and how the identifier-first login page behaves.
        • IFL policy field reference -- Field descriptions for an identifier-first login policy in the Authentication Console.
          • Technical reference -- System properties, affected login routes, policy conditions, authentication methods, and fallback behavior for the policy-based login experience.
      • OAuth authentication -- OAuth based authentication validates the identity of the client that attempts to establish a trust on the system by using an authentication protocol.
        • OAuth 2.0 -- OAuth 2.0 lets users access instance resources through external clients by obtaining a token rather than by entering login credentials with each resource request.
          • Set up OAuth -- Set up and activate OAuth, enable the OAuth system property, create an OAuth application endpoint for external client applications to access the instance, and set OAuth parameters.
          • Activate OAuth -- By default, the OAuth 2.0 (com.snc.platform.security.oauth) plugin is active on new and upgraded instances. If the plugin is not active on your instance, you can activate it.
          • Set the OAuth property -- To generate OAuth 2.0 tokens to registered applications, the com.snc.platform.security.oauth.is.active property must be active for the instance.
          • Change OAuth password parameter -- Use this property to ensure only POST body parameters are accepted as input for all supported grant types.
        • OAuth inbound -- OAuth Inbound authentication allows trusted external applications to securely access ServiceNow APIs, helping to keep connections controlled and authorized.
          • Inbound integrations -- The new inbound integration workflow in the ServiceNow Machine Identity Console provides enhanced experience for managing inbound integrations.
            • Auth Code Grant -- The OAuth authorization code grant is a secure and widely used flow for web, mobile, or desktop apps that access user data with user consent. It supports both private clients (using a client secret), and public clients (using PKCE).
              • Authorization workflow -- ServiceNow handles both authentication and API access by acting as the authorization and resource server. When single sign-on (SSO) is enabled, it redirects users to the configured identity provider (IdP) for authentication and issues tokens after successful login.
              • Configuration -- Configure the OAuth authorization code grant to enable secure and interactive user authentication to enable applications to access resources on behalf of users. The OAuth authorization code grant verifies that the API access is granted based on the user identity and permissions.
            • Client credentials grant -- Use the OAuth client credentials grant type for back-end services or automated integrations that access ServiceNow APIs without user interaction. The client application authenticates directly using its client ID and secret, and receives an access token that represents the application itself, and not the user.
              • Client credentials workflow -- Authenticate a client application using a client credentials workflow. The client credentials grant workflow is used by back-end services or system integrations to access ServiceNow APIs without user involvement.
              • Configuration -- Configure the OAuth Client Credentials Grant for secure machine-to-machine authentication without user interaction. It authenticates applications using client credentials and grants-controlled API access with scoped permissions.
            • Third Party Token Grant -- The third party token grant enables ServiceNow to accept identity tokens from trusted external identity providers, such as Azure AD or Okta. Third party token grant provides secure, token-based access. This method supports secure access and single sign-on (SSO) in federated authentication scenarios.
              • User Token Flow -- This workflow can be used to integrate third-party identity providers (IdPs) with ServiceNow for secure API access. It allows client applications to obtain tokens directly from an IdP and use them to access ServiceNow APIs.
              • Service Token Flow -- Create a service account in ServiceNow to represent the identity of a third-party application accessing APIs through a trusted identity provider (IdP). This account maps the token claims to a user record and manages access with roles and permissions.
              • Configuration -- Configure a third-party ID token to enable secure authentication by verifying user identities through an external IdP. The third-party ID token improves security by reducing stored credentials, confirms seamless authentication, and supports interoperability with industry standards like OpenID Connect (OIDC).
            • JWT Grant -- Configuring an OAuth JSON Web Token (JWT) bearer grant secures token-based authentication without user interaction. Use this flow when a client application needs secure, unattended access to ServiceNow resources, either as itself or on behalf of a user.
              • Workflow -- Configuring an OAuth JSON Web Token (JWT) bearer grant secures token-based authentication without user interaction.
              • Configuration -- Configuring an OAuth JSON Web Token (JWT) bearer grant secures token-based authentication without user interaction. It enhances security with signed JWTs and reduces authentication overhead by eliminating repeated login attempts.
            • ROPC Grant -- Configuring an OAuth Resource Owner Password Credential (ROPC) grant enables applications to authenticate users by directly using their credentials to obtain an access token.
              • Password Grant Flow -- This flow is used in legacy or highly controlled environments where secure alternatives aren't feasible. The client app directly collects and sends user credentials to ServiceNow to obtain an access token, making it suitable only for trusted internal use.
              • Configuration -- Configuring an OAuth resource owner password credential (ROPC) grant enables applications to authenticate users by directly using their credentials to obtain an access token. This method is ideal for trusted applications and legacy systems that require authentication without browser-based flows, enabling secure token validation and controlled API access.
            • CIMD client integration -- CIMD lets the ServiceNow AI Platform accept an external OAuth client that identifies itself with an HTTPS metadata-document URL instead of a pre-issued client ID and secret.
              • CIMD workflow -- Configuring Client ID Metadata Document (CIMD) inbound support lets an instance accept an external OAuth client that's identified by a metadata document URL, without storing a client secret for that client.
              • Configure a CIMD client -- Register a Client ID Metadata Document (CIMD) client so that the instance accepts inbound OAuth requests from a client identified by a metadata document URL. You can fetch the client's configuration from its metadata URL or enter the details manually.
              • Update a CIMD client -- Update a registered Client ID Metadata Document (CIMD) client, including switching the metadata sync mode between Live and Static.
          • Old inbound integrations experience -- Old experience - Inbound integrations.
          • Manage OAuth tokens -- Open OAuth tokens to provide access to restricted resources.
            • Revoke an OAuth token -- You might want to revoke an OAuth access or refresh token for security reasons.
        • OAuth outbound -- OAuth outbound enables you to pull data from a third party provider to your instance.
          • Workload Identity Federation -- Authenticate outbound OAuth calls to Microsoft Azure and Google Cloud using a signed JWT that the cloud provider validates through the instance's public JWKS endpoint, so that no client secret needs to be stored on the instance.
          • Connect to a third-party OAuth provider -- Configure how the client ID and secret are sent to your OAuth provider.
          • JWT Bearer -- JSON Web Tokens (JWTs) enable the capability to configure server-to-server API interactions between ServiceNow and external API providers without requiring any user intervention.
            • Set up OAuth provider with JWT Bearer grant type -- JSON Web Tokens (JWTs) enable the capability to configure server-to-server API interactions between ServiceNow and external API providers without requiring any user intervention. This support enables Integration Hub or other automated tasks using JWTs to configure API and Service integrations with different providers.
              • Upload Java Key Store certificate -- JSON Web Tokens (JWTs) enable the capability to configure server-to-server API interactions between ServiceNow and external API providers without requiring any user intervention. This support enables Integration Hub or other automated tasks using JWTs to configure API and Service integrations with different providers.
              • Configure a JWT signing key -- JSON Web Tokens (JWTs) enable the capability to configure server-to-server API interactions between ServiceNow and external API providers without requiring any user intervention. This support enables Integration Hub or other automated tasks using JWTs to configure API and Service integrations with different providers.
              • Create a JWT provider with a JWT signing key -- JSON Web Tokens (JWTs) enable the capability to configure server-to-server API interactions between ServiceNow and external API providers without requiring any user intervention. This support enables Integration Hub or other automated tasks using JWTs to configure API and Service integrations with different providers.
            • Generate a JSON Web Token (JWT) -- Create a JSON Web Token (JWT) for representing claims securely between two parties on the ServiceNow AI Platform.
          • OAuth client APIs -- The OAuth client API provides methods to request and revoke OAuth tokens.
          • OAuth parameters for default profile support -- The default profile feature requires a set of parameters that you can use with the setParameter() API to specify the OAuth requestor, a context for the request, and the provider profile.
          • Private key JWT support for OAuth 2.0 client authentication -- Use private key JWT to authenticate OAuth 2.0 clients to the authorization server.
          • Create an outbound REST message -- Create outbound rest message to authorize instance as authorization server.
      • Outbound certificate policies -- Outbound certificate policies let you control how the instance validates a specific domain's fully qualified domain name (FQDN) SSL/TLS certificate on outbound connections. Use these policies instead of applying global validation settings to every host.
        • Add an outbound certificate policy -- Add an outbound certificate policy to control how the instance validates a specific domain's SSL/TLS certificates on outbound connections, adjusting individual validation checks for that domain.
        • Outbound certificate policies system properties -- System properties that control outbound certificate policy enforcement, and the global certificate validation properties that apply to domains without a policy.
      • Personal authentication -- Personal authentication enables you to securely connect and manage your OAuth-based integrations like Microsoft OneDrive or Google Drive.
        • Activate Dashboard -- You can activate the Personal Authentication plugin (com.snc.sn_ihub_personal_auth) for Integration Hub if you have the admin role. If the application does NOT include demo data or it does NOT install related applications and plugins, delete or revise the following sentence:The application includes demo data and installs related ServiceNow Store applications and plugins if they are not already installed.
        • Configure personal authentication -- Configure personal OAuth authentication with the REST step in Flow Designer.
        • Get OAuth token -- Check whether the user has a personal OAuth token. Use it to confirm valid access before running REST steps or integrations that require personal OAuth credentials.
        • Generate auth URL -- Generate the initial token for a user who doesn’t have access to the credentials page to configure personal authentication.
      • Self-registration to ServiceNow instance -- Use external user self-registration to onboard a large volume of external users to your instance. This feature enhances identity verification to improve customer experiences and supports commonly used registration flows.
      • Token based authentication (user logins) -- Token-based authentication verifies the identity of users who access a network and issues a unique access token.
      • Web embeddables -- Secure the web embeddables feature for authenticating the ServiceNow web components that are used in third-party portals.
        • Configure client session access role -- The Embedded Session Role Configuration (Client Access Role configuration) record is created by default, which removes admin and security admin roles (high privilege roles) for the users using the UI components on the third-party portals.
      • Web service security -- Enforce security using basic authentication, mutual authentication, or WS-Security.
    • Access Control Lists (ACLs) -- Access control lists (ACLs) restrict access to data by requiring users to pass a set of requirements before they can interact with it.
      • Explore Access Control Lists -- Explore access control lists (ACLs).
        • ACL types -- Create ACLs on different components of the system.
          • Datatype ACL -- The datatype ACL enables you to write ACLs that apply to all fields of a specific type.
        • ACL control of function fields -- When evaluating access to a function field, in addition to checking access to the function field itself, the system also checks access to the function's contributing fields. Contributing fields are those used as the arguments in a given function definition.
        • Security jump-start - ACL rules plugin -- The Security jump-start access control level (ACL Rules) plugin is installed automatically on all new instances. Use this plugin to quickly secure multiple system tables and expedite the production launch process for your organization.
        • Using the ACL explainer AI agent -- Ask the ACL Explainer AI agent about an access control list (ACL), a table, a field, or another resource in everyday language. Sample prompts and examples show how to phrase questions and the responses to expect.
      • Configure an ACL -- Configure custom access control list (ACLs) to secure access to new objects or to change the default security behavior.
        • Deny-Unless ACL -- A Deny-Unless ACL grants access only when a user meets all defined role, condition, and script requirements. If any requirement is unmet, access is denied.
        • Allow ACL -- Learn about Allow ACLs (access control lists).
        • Query ACLs -- Query ACLs enable more granular access control by defining who can query the data.
        • Secure records in an embedded list -- To apply security to the records in embedded lists, limit editing and deleting records in embedded lists to specific roles.
        • Related record access -- Related record access enable consistent control over what records users are able to access between related tables.
      • Contextual Security Manager -- Contextual Security Manager protects your data by controlling read, write, create, and delete authorization.
      • Advanced ACL configuration -- In addition to creating new ACLs or modifying existing ones, you can configure other aspects of ACL functionality.
    • Access Analyzer -- ServiceNow Access Analyzer is an access diagnostic tool for AI administrators or creators to validate the access controls configured within various resources and agentic assets (agentic workflows and AI agents).
    • Access findings -- Access findings feature displays the potential vulnerabilities that are discovered the last time access checks were ran on your ServiceNow AI Platform.
      • Explore Access findings -- Access findings feature displays the potential vulnerabilities that are discovered the last time access checks were ran on your ServiceNow AI Platform.
      • Use Access findings -- Use Access findings to view the potential vulnerabilities that are discovered the last time access checks were ran on your ServiceNow AI Platform.
    • Access management console -- ServiceNow AI Platform's Access management console to ensure that the right individuals have the appropriate permissions to the right resources at the right time.
      • Explore Access management console -- Use the Access Management Console within Security Center to review and remediate access issues and misconfigurations. The Access Management Console provides enhanced visibility and control of your Access Analyzer findings, and streamlines remediation efforts. Within the console you can track, prioritize, and resolve access issues by assigning tasks.
      • Use Access management console -- Use the Access management console to ensure that the right individuals have the appropriate permissions to the right resources at the right time.
    • Security Attributes -- Security attributes offer a flexible alternative to access control lists (ACLs).
    • Field Query Roles and Restrictions -- The Field Query Roles and Field Query Restrictionsattribute enable you to better control what information is available to users in tables.
    • Scripting Governance Tool -- Use the Scripting Governance Tool to provide a single, centralised control for managing scripting access across your ServiceNow AI Platform.
      • Explore Scripting Governance Tool -- The Scripting Governance Tool provides a single, centralised control for managing scripting access across your ServiceNow AI Platform.
      • Use Scripting Governance Tool -- Use the Scripting Governance Tool to provide a single, centralised control for managing scripting access across your ServiceNow AI Platform.
        • Scan for users who have scripted -- Scan your instance to find users who have scripted within a specific time frame. The scan queries the audit logs and identifies any user who has performed write or update to a table having script field.
        • Remove users from the Conditional Script Writer group -- Use the Manage scripting access to manually add or remove users from the Conditional Script Writer group to control who has scripting access.
      • Manage Scripting Governance Tool -- Enable or disable the Scripting Governance Tool on your instance by running the appropriate script. Only users with the security_admin role can run these scripts and modify the associated properties.
    • Machine identity access controls -- Define and enforce granular access control policies on specific resources for integration users.
      • Create a machine identity access control -- Enable administrators to define and enforce granular control for integration users by introducing User Access Profiles. This feature provides an additional layer of security and control, allowing admins to specify the exact resources (REST APIs and SOAP APIs) that an integration user can access, ensuring tighter governance and minimizing security risks.
    • Security data filters -- Security data filters restrict access to records based on role, or security-attribute related assertions.
      • Create a security data filter -- Learn how to create security data filter rules to grant your users' access to records and tables.
      • Default security filters -- Generally data filters are applied after absolute ACLs (also sometimes called table-level ACLs), and after row-level ACLs. They are applied by default, and can be impactful to system behavior if not used carefully.
    • Security Roles -- Security Roles provide added security, every user must have at least one role so that the instance can distinguish between internal and external users.
      • Explicit Roles -- You can give both internal users and external users access to your instance. However, you might not want both types of users to have the same level of access. To provide added security, every user must have at least one role so that the instance can distinguish between internal and external users.
        • Request Explicit Roles -- You can give both internal users and external users access to your instance. However, you might not want both types of users to have the same level of access. To provide added security, every user must have at least one role so that the instance can distinguish between internal and external users.
      • Elevated privilege roles -- Elevated privilege roles require you to manually accept the responsibility of using the role before you can access the features of the role.
        • Security_admin role -- The security_admin role is an elevated privilege role provided with High Security Settings that lets users create and change access controls and change High Security Settings.
        • Elevate to a privileged role -- The base system admin can elevate to a privileged role to have access to the features of High Security Settings.
        • Force administrators to manually elevate -- A property is available to force all users with the administrator role to manually select the role that they want to elevate to.
    • Connections and Credentials -- Credentials and connection information are required to gain access to a computer or network device for Discovery, Service Mapping, and Cloud Management or to perform work using Orchestration. When adding content to Share or AppStore, you can configure connections and credentials relevant to your environment without modifying built content.
      • Explore credentials, connections, and aliases -- All application integrations in the ServiceNow AI Platform use connections, credentials, and aliases to enable applications to access resources.
        • Scope protections -- You can classify certain types of Connection & Credential records as belonging to a scope, and extend scope protections to them. These scope policies protect records you create in a table, and prevent interactions with records that are private to another scope.
        • Domain separation and Credentials and Connections -- Domain separation is supported in Credentials and Connections. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.
        • Connection & Credential configuration templates -- Enable users with the admin and flow_designer roles to set up spoke integrations with third-party systems using a single, customizable form.
          • Configure a template for OAuth JWT Bearer grant type -- This example configuration template sets up Credential and Connection records using the JWT Bearer grant type to authenticate requests to Docusign.
          • Create a configuration template -- Create a template that defines the inputs required to set up a spoke. Set static key-value pairs to create records and set values that apply to every integration. Set dynamic key-value pairs to gather user input and set field values that may vary. Using this template, admins and flow designers can set up the spoke from a single form.
      • Get started with connections -- Use the connections table to set up a Basic, JMS, JDBC, or HTTP(s) connection to a target host.
      • Get started with credentials -- The MID Server uses the credentials you create in the Credentials [discovery_credentials] table to access resources for Discovery, Orchestration, Service Mapping, and Cloud Management.
        • Create a Connection & Credential alias -- Define an alias to label a credential or connection record.
        • Set up OAuth integration via MID Server -- Create a connection record that enables the sending of an OAuth token request to a third-party server via a MID Server.
        • Credential aliases for Discovery -- Credential aliases for Discovery allow an administrator to use specific credentials on Discovery schedules. You can configure behaviors for your aliases that determine how strictly the system enforces their use.
          • Create a Discovery credential alias -- Credential aliases for Discovery allow an administrator to use specific credentials on Discovery schedules. You can configure behaviors for your aliases that determine how strictly the system enforces their use.
        • Credential aliases for Orchestration activities -- Credential alias gives an administrator more control over the credentials used in Orchestration activities.
        • Create and test your credentials -- Create and test the credentials that Discovery, Service Mapping, Cloud Management, and Orchestration require to access hardware and software in your network.
          • Ansible Tower credentials -- Ansible Tower credentials are required to access your Ansible configuration management account. Use these credentials to manage Ansible resources through the Cloud Management application.
          • API key credentials -- An API key is a unique code that is passed in to an API to identify the calling application or user.
          • Applicative credentials -- Some applications require credentials in addition to the credentials the that host machine requires. Credentials required to access these applications are referred to as applicative credentials.
          • Basic authentication credentials -- The basic authentication credential type manages access to store basic authentication credentials.
          • Chef server credentials -- Chef server credentials access chef integrations with the instance.
          • CIM credentials -- The CIM credential type manages access to a CIM server (also referred to as a CIMOM - Common Information Model Object Manager) for information about VMware ESX servers. This credential type is available for Discovery.
            • Configure NetApp storage devices for CIM credentials -- The CIM credential type manages access to a CIM server (also referred to as a CIMOM - Common Information Model Object Manager) for information about VMware ESX servers. This credential type is available for Discovery.
          • Cloud credentials -- Cloud credential types manage access to cloud-based applications, including Amazon Web Services and the Microsoft Azure cloud.
          • Container image repository credentials -- The container image repository credentials manage access to private repositories for container image scanning. This credential type is available for Discovery.
          • Infoblox credentials -- Infoblox credentials are required to set up IP pools (IPAM) in the Cloud Management application.
          • JDBC credentials -- The JDBC credential type manages access to a Java Database Connectivity (JDBC) connection. This credential type is available for Discovery and Orchestration.
          • JMS credentials -- The JMS credentials type manages access to a Java Message Service (JMS). This credential type is available for Discovery and Orchestration.
          • OAuth 2.0 credentials -- OAuth 2.0 credentials enable ServiceNow to obtain access to user accounts on an HTTP service.
          • SAP credentials -- The SAP credential type manages access to SAP JCo systems. This credential type is available for Discovery and Orchestration.
          • SNMP credentials -- Discovery explores many kinds of devices (switches, routers, printers, and so on) using the SNMP protocol. Credentials for SNMP don’t include a user name, just a password, called the community string.
            • SNMP community credentials -- Discovery explores many kinds of devices (switches, routers, printers, and so on) using the SNMP protocol. Credentials for SNMP don’t include a user name, just a password, called the community string.
            • SNMPv3 credentials -- Discovery explores many kinds of devices (switches, routers, printers, and so on) using the SNMP protocol. Credentials for SNMP don’t include a user name, just a password, called the community string.
          • SSH credentials -- Discovery, Orchestration, and Integration Hub explore UNIX and Linux devices by using SSH credentials to execute commands over Secure Shell (SSH). SSH commands must run with root privileges, either with root credentials or through the use of sudo. SSH private key credentials provide additional security.
          • VMware credentials -- The VMware credentials type manages access to vCenter credentials.
          • Windows credentials -- Windows credentials provide access to Windows computers. This credential type is available for Discovery and Orchestration.
        • Credential affinity for Discovery and Orchestration -- Credential affinity is an association between a set of credentials and a device on your network.
        • Credentials troubleshooting -- Review the <credentials_debug> section of the ECC queue payload to troubleshoot issues with credentials.
        • External credential storage -- An instance can store credentials used by Discovery, Orchestration, and Service Mapping in an external credential repository rather than directly in a ServiceNow credentials record.
      • Authentication Algorithms -- Verify the identity of the sender using Authentication Algorithms
    • ServiceNow access control -- The SNC Access Control plugin (com.snc.snc_access_control) enables you to control which Customer Service and Support employees can access your instance, and when.
      • Explore ServiceNow access control -- The SNC Access Control plugin (com.snc.snc_access_control) enables you to control which Customer Service and Support employees can access your instance, and when.
      • Activate ServiceNow access control -- You request activation of the SNC Access Control plugin (com.snc.snc_access_control).
      • Configure ServiceNow access control -- Configure an access control record to specify one or more Customer Service and Support employees who have permission to log in your instance.
      • Audit logging -- The following logging tracks logins and activity by ServiceNow employees.
  • Identity -- Learn about the identities in the instance.
    • Global Identity -- Use ServiceNow Global Identity to help identify and manage users across multiple instances.
      • Exploring Federated ID -- The ServiceNow Identity system uniquely identifies users across multiple instances and assigns each resolved user a unique Federated ID for consistent identification.
      • Configure Federated ID Criteria -- Access and configure Federated ID Criteria to see the ID fields selected to generate the Federated ID unique identifier. The default setting is User ID and email.
      • Update ID fields -- To generate new Federated IDs, you can either use the existing user resolution search criteria or update the criteria before regeneration.
    • Identity and Access Audit -- Use the Identity and Access Audit to understand changes made to users, groups, roles, and ACLs.
    • Identity Center -- Enables you to monitor, manage, and minimize identity-based risk and security gaps.
    • Machine Identity Console -- Manage your service accounts which are used for integrations with ServiceNow.
    • Role masking for AI agents -- Role masking for AI agents and agentic workflows helps administrators enhance security by limiting the roles those agents use during tool execution, and by verifying that AI agents run with least-access privileges.
      • Agent Access Role Configuration -- Restrict the roles that an AI agent uses at runtime by creating an Agent Access Role Configuration record that limits the agent to a defined set of roles.
    • System for Cross-domain Identity Management (SCIM) -- The System for Cross-domain Identity Management (SCIM) API provides endpoints to create, read, update, and delete operations on users and groups using the SCIM protocol.
      • SCIM Provider -- The Service Provider provisions users and groups using the SCIM API.
      • SCIM Client -- The SCIM Client facilitates provisioning and updates on identity resources through CRUD operations exposed by SCIM endpoint on an external system.
        • Exploring SCIM Client -- The SCIM Client facilitates provisioning and updates on identity resources through CRUD operations exposed by a SCIM endpoint on an external system.
        • Activate the SCIM Client -- For SCIM Client activation, install the SCIM v2 - ServiceNow Cross-domain Identity Management Client (com.snc.integration.scim2.client) plugin.
        • SCIM Client properties, tables, scriptable APIs, and logs -- The SCIM v2 - ServiceNow Cross-domain Identity Management Client (com.snc.integration.scim2.client) plugin includes the following system properties, tables, scriptable APIs, and logs.
        • Create a REST message -- Configure a REST message for all outbound calls for a particular SCIM Provider.
        • Create a SCIM provider -- Create a SCIM Provider to fetch resource types and schemas information from the SCIM Provider with the REST message. Enable the configuration of the HTTP Method (PUT or PATCH) to update a resource in the SCIM Provider.
        • Create a SCIM Provider Resource Mapping -- Define the mappings of SCIM attributes to ServiceNow attributes for a particular resource type and SCIM Provider.
        • SCIM Client troubleshooting -- Troubleshooting actions can help resolve common issues when setting up or running the SCIM Client.
  • Access observer -- Use Access Observer to understand people and processes access data on your instance.
  • Granular admin roles -- Granular admin roles enables you to verify proper access management by assigning roles that define user permissions and responsibilities. By doing so, organizations can maintain security, enforce conformance, and optimize their operations effectively.
  • Additional resources -- If you’re looking for Platform Security best practices, troubleshooting, or other implementation guidelines, select a feature or resource type to discover ServiceNow resources on other relevant websites.
  • Agentic AI security and governance -- Learn how to secure your Now Assist applications and features.
    • Permissions-based access control -- Use Agent Role Inheritance, identity types, and granular roles to verify your AI agents have only the permissions they need, and can act only within their intended boundaries.
    • Data protection -- Learn how ServiceNow security tools such as the Key Management Framework, Field Encryption, and Data Classification work to keep your data secure.
    • Agent traceability and monitoring -- Learn how to use tools like AI Control Tower to track, monitor, and report on your AI assets.
    • Governance and admin safeguards -- Find guidance on preparing your instance for AI deployment, maintaining domain separation, and reducing risk across your Now Assist implementation.
    • AI threat protection -- Learn how Now Assist helps defend against AI-specific threats including offensive content, prompt injection, and sensitive subject detection using AI Guardian.
    • External AI agent security -- Learn how to monitor and govern AI agents from external providers, with visibility into third-party data flows and assurances that sensitive data stays properly isolated across your AI ecosystem.
Search documentation
Search document titles and file paths on the brazil branch