ServiceNow Discovery: Security and Access Design

Role Model for Discovery Access Control

Discovery in ServiceNow requires a clear role model that separates who can configure discovery, who can view discovered data, and who can approve data promotion into the CMDB. A typical role model includes: Discovery Administrators who configure probes and reconciliation rules, Discovery Approvers who validate discovered data before CMDB promotion, CMDB Administrators who manage the promoted data, and Infrastructure Teams who use CMDB data but do not configure or approve discovery.

Define roles explicitly in your instance: which users or groups hold each role, what permissions each role grants, and who assigns roles. Document the role definitions and review them quarterly to ensure they remain aligned with team structure and compliance requirements.

Avoid consolidating roles. For example, do not make Discovery Administrators also approve data; this creates a scenario where one person can introduce bad data without oversight. Segregation of duties is a control principle: the person configuring discovery should not unilaterally approve the data it collects.

Least-Privilege Principle for Discovery Credentials

Discovery requires credentials to access target systems. These credentials should have the minimum necessary permissions: read-only access to configuration, no ability to execute commands or modify settings. For example, a Discovery account on a Windows domain should have read-only permissions to the registry and WMI, not administrator privileges.

Store credentials in a secrets management system (Vault, Secrets Manager, or ServiceNow’s own credential storage) rather than in plaintext configuration. Credentials should not be readable by users; only the Discovery framework should access them. Rotate credentials regularly—at least annually, and more frequently if turnover in teams with access to credentials occurs.

Document which credentials are used for which targets and who approved their use. This accountability trail helps during security reviews and incident investigations.

Segregation of Duties in Discovery Workflows

Discovery workflows should enforce segregation of duties at key decision points. For example, the workflow for promoting discovered data into the CMDB should include steps where different users or groups perform different activities: a data analyst validates accuracy, a subject-matter expert confirms the technical content, and a CMDB administrator approves promotion. No single person should drive the entire workflow.

Implement this in ServiceNow by configuring group-based approvals: certain activities are assigned to groups, not individuals, so the work is visible to all group members and can be picked up by anyone with permission. This prevents a single bottleneck and distributes accountability.

Audit Evidence and Access Logs

Audit discovery access and data changes: who accessed discovered data, when, and what they viewed or modified? ServiceNow’s audit framework logs these activities, but you must enable it for Discovery and CMDB tables.

Retain audit logs for as long as your compliance and regulatory requirements mandate, which varies by sector and jurisdiction. Use audit logs to investigate anomalies: if an unauthorized user accessed sensitive CI data, or if a large number of records were modified in an unusual way, audit logs provide evidence of what happened.

Report on audit data regularly: monthly or quarterly, pull reports showing access patterns, unusual activities, and changes to sensitive records. Share these reports with security and compliance teams as evidence of your access controls.

Data Protection and Sensitive CI Information

Discovered data can include sensitive information: passwords, encryption keys, personally identifiable information. Discovery should be configured to exclude sensitive fields or to mask them after collection. For example, if a probe collects passwords during credential validation, those passwords should be removed from the discovered CI record before it is stored in the CMDB.

Some organizations have policies that certain infrastructure information is sensitive and should have restricted access: for example, CIs in the HR systems or financial systems might be visible only to authorized staff. Implement CMDB security groups to enforce these restrictions: CIs tagged as HR-sensitive are visible only to authorized users, even though all users might see most CMDB data.

Review Cycle and Continuous Improvement

Conduct a security review of Discovery access and controls at least annually. Review who holds Discovery roles, whether segregation of duties is maintained, whether credentials are rotated regularly, and whether audit logs show any anomalies or concerns. Update the role model if organization structure changes or if new security requirements emerge.

Also review discovery scope: are you collecting data on systems that should be excluded for security reasons? Are agents probing systems they should not have access to? Scope creep in discovery can lead to unintended data collection or network access that creates security risk.

FAQ

Q: What permissions should Discovery credentials have on target systems?

Read-only permissions only: ability to query configuration and software inventory, but no ability to modify settings or execute commands. For Windows, this typically means read access to the registry and WMI. For Linux, read access to system files and ability to run non-privileged commands. Avoid administrator or sudo access; it is unnecessary for discovery and creates security risk if credentials are compromised.

Q: Who should approve promotion of discovered data into the CMDB?

Approval should come from someone other than the person who configured discovery: ideally a subject-matter expert who understands the infrastructure being discovered. In large organizations, this might be a dedicated Discovery Approver role or a subject-matter expert from the infrastructure team. Small organizations might have a single person fulfilling multiple roles, but document this and compensate with more frequent audits.

Q: How do we handle access to sensitive CI data?

Use CMDB security groups to restrict visibility: CIs tagged with a sensitivity classification are visible only to users in authorized groups. For example, HR-system CIs are visible only to HR staff and IT security. This allows most users to access most CMDB data while protecting sensitive information. Document which CI classifications are sensitive and who is authorized to access them.

Map each collection path before opening it

The access design on paper and the access design in the network are often different things. A rule that says collection points may reach the server segment is not specific enough to approve. The working question is which path each probe method needs: a remote login protocol for Linux hosts, a management interface for network gear, an API for cloud accounts, a query channel for database instances. Each method touches a different port, a different account and a different log. Write the path down per method before the firewall request is raised, because the request that is approved is often wider than the one that was needed.

When a change request arrives with the words “all ports to the server subnet”, send it back. Ask the discovery owner to list the methods that will run, the target classes for each, and the ports those methods use. The approved rule should match that list and nothing more. Many security reviews that go badly do so because the rule was approved as a bucket, and the bucket was never narrowed afterwards.

Match collection methods to the access they really need

Rotating discovery credentials without breaking scans

Rotation often fails because the credential is used in more places than the person rotating it knows about. The following order reduces the chance of a silent break.

1. Export the list of discovery credentials with the targets and segments each one serves. If that list does not exist, building it is the first task.
2. Create the new credential alongside the old one and test it against one representative target in each class.
3. Update the credential store entry in a maintenance window, then run a single scan of a small segment and check the result against the last good run.
4. Only after the test passes, retire the old credential on the target systems, and record the date.
5. Watch the next full cycle for authentication failures and treat any new failure as a rotation defect until it is explained.

How to tell the access design is working

A design can look correct at approval and still drift. Three signals show whether it is holding. The first is that authentication failures are rare and explained: an account that fails every week is either out of date or being used against a target it was never meant to reach. The second is that no one in operations has asked for a broader rule to fix a scan. Requests for widening are the earliest sign that the approved path does not match the real estate. The third is that the approved rule list can be reconciled to the method list without anyone reading the firewall console by hand.

When not to scan a segment at all

Some segments should be excluded from active collection even when the access exists. Industrial control networks, medical devices with fragile firmware and legacy hosts that have been flagged as unstable are common examples. Passive or manually supplied data may be the right source for these, and the exclusion should be recorded with the reason, the owner and the review date. An exclusion is a security decision as much as an operational one, and it belongs in the same governance record as the credentials.

Questions about discovery access, beyond the basics

Should discovery have its own network segment?

It often helps. A dedicated management path for collection points makes it easier to see discovery traffic, to apply tighter rules, and to isolate the collectors if one is compromised. It only works if the routing is kept simple, because a complex overlay often produces the intermittent failures that people then fix by widening rules.

What do we do when a target team refuses a read-only account?

Ask what they are worried about. The usual answers are fear of lockout, concern about performance and uncertainty about what the account can see. Address each one with evidence: the commands run, the scan schedule, and the test of the account’s rights. If the refusal stands, record the target as an exclusion rather than granting a broader account.

Can the same probe host serve several security zones?

Only if the zones have the same sensitivity and owner. Separate collection points per zone are easier to defend in an audit, even though they cost more to run.

Review the design with a specialist

If your access model has grown by exception, map each method to the access it needs and check where the rules are wider than that. The testing and acceptance checklist is the place to look for checks on access, and the MID Server security and access design page covers the collection point side of access. For the credential lifecycle, see the note on discovery credential governance.