IT Discovery for Utilities: IT and OT Asset Visibility in One View

Assets missing from the inventory usually miss patch reviews and audit sampling too. In a utility, that gap sits where IT and operational technology (OT) meet.

The North American Electric Reliability Corporation (NERC) sets CIP-002 categorization requirements for Bulk Electric System (BES) Cyber Systems. They apply to entities such as transmission owners and operators and generator owners and operators. A Critical Infrastructure Protection (CIP) Senior Manager or delegate must approve the identifications at least every 15 calendar months.

IT discovery for utilities gives that approval a current asset list to rest on. It places every asset that responds to IT-class discovery into one configuration management database (CMDB) and shows where the OT boundary starts.

Why utilities keep two asset inventories

Utility IT teams track laptops, servers, cloud workloads, network gear, and business applications. Operations teams track the systems that monitor and control the grid or plant. NIST SP 800-82 Rev. 3 covers that second group as OT, including industrial control systems that monitor and control physical processes.

The two groups use different tools, change windows, and vendors. Each team builds the list that fits its own work. Nobody owns the seam between them.

Shared equipment sits on that seam. A historian server feeding the corporate network, a remote-access jump host, and a firewall between zones belong to both worlds. This is where IT and OT convergence actually happens — not in a strategy deck, but in the handful of devices neither team fully owns. Without a shared list, each team can assume the other one reviews them. That assumption is how configuration data drifts out of sync with what is actually running. Auto discovery tool: Top 9 reasons to use one in 2025

Where IT and OT share the same assets

OT environments contain a large layer of IT-class equipment. Servers, workstations, switches, and firewalls in control-center and substation networks run standard operating systems and use standard network protocols. Virima IT discovery software can inventory these assets directly.

In practice, this reconciliation catches real gaps: a transmission operator preparing for a CIP-002 review has found historians still listed as active servers years after decommissioning, each one a line item an auditor could flag.

What IT discovery covers in a utility estate

Discovery uses three methods: lightweight agents on endpoints, credential-based agentless scanning, and network device discovery for routers, switches, and firewalls. It also inventories virtual machines on VMware and Hyper-V, and cloud assets on AWS and Azure.

Each asset record carries its operating system, hardware details, serial number, and installed software.

Hostnames change when a server is rebuilt, but hardware doesn’t. The serial number is the join key for physical servers, and the cloud instance ID plays that role for cloud workloads, so an asset’s history and relationships survive a rebuild instead of resetting under a new identity.

Multi-site support covers segmented environments such as separate plants, substations, and control centers. Discovery runs in scheduled cycles, so a scan of a control-center network can wait for an approved maintenance window.

Map vulnerability blast radius across the IT and OT boundary using discovery-sourced Trusted Runtime Truth.

Where OT needs a different approach

Field devices and many control-system components can be sensitive to unplanned network traffic. Active scanning against them needs engineering sign-off, and some zones may rule it out. Utilities typically watch those devices with passive OT monitoring tools built for industrial protocols.

Virima inventories the IT-class assets around those devices and the network equipment that connects the zones. OT monitoring tools keep the field-device view. Where such a tool holds device records, teams can bring them into the same CMDB through the Virima REST API.

That boundary layer still matters on its own: the firewall and historian in front of a PLC are usually where lateral-movement risk concentrates, so visibility there closes a real gap even without native protocol depth.

Teams should settle three points before the first cycle in any OT-adjacent zone:

• Which network ranges and credentials each cycle uses.
• Which assets receive an agent instead of a network scan.
• Who approves the schedule and who reviews the results.

One reconciled record for each asset

Utilities usually have several sources describing the same server. A discovery scan, a purchasing record, a monitoring tool, and an engineering spreadsheet each hold a partial view. Each source can disagree on owner, location, or software version.

Virima CMDB software merges these sources into one record per configuration item (CI) — the utility CMDB every later step depends on — and keeps the source of each value. Each CI links to its relationships, so a reviewer can see which firewall sits in front of a historian and which servers depend on it. The audit trail records every change to a CI, and role-based access control limits who can view or edit records.

For NERC CIP work, the CMDB supplies the asset population. The compliance team still assigns impact ratings under its own program. A reconciled inventory removes the manual matching of spreadsheets before each review. Audit-Ready Asset Management Dashboards With Continuous Discovery

NERC’s newer CIP-015 standard raises the stakes further. FERC approved CIP-015 in September 2025 under Order No. 907. It requires internal network security monitoring for high-impact BES Cyber Systems — control centers must comply by 2029, with other entities given an additional 24 months. Internal network monitoring depends on already knowing what is on each network segment — the reconciled asset list has to exist before that work starts. Compliance teams can track the full set of active standards on NERC’s CIP standards index.

Mapping the business services behind the assets

An asset list shows what exists. It does not show which grid or customer function depends on a given server. A security team that finds a vulnerable historian needs to know what that host supports before ranking the fix.

Service mapping answers that question. Utilities provide each service definition, such as outage management or customer billing. They add it through manual entry, a spreadsheet import, or an enterprise architecture integration such as LeanIX. ViVID™ service maps then build the dependency map from those definitions, from application through database, server, and network component.

The map traces a failing component to the business service it affects. A change manager sees the same chain before approving a firewall change at a boundary. Change Impact Analysis with CMDB: How to Assess Risk Before Every IT Change

How to evaluate discovery for a utility

Use these questions to evaluate OT asset visibility claims in a vendor review:

1. Which discovery methods apply to each zone, and which need an approved window?
2. Can operations control the discovery schedule and the network ranges it uses?
3. How does the tool join records from OT monitoring tools to IT records?
4. Does each CI keep its source and change history for audit review?
5. Which join key does the tool use when hostnames change?
6. Who provides service definitions, and in what format?

Ask each vendor to show the answers to questions 2 and 3 in a working environment. Written answers rarely expose how a tool behaves in a segmented network.

Start IT discovery for utilities at the IT and OT boundary

Begin with the assets both teams depend on: boundary firewalls, historians, jump hosts, and engineering workstations. Reconcile them in one CMDB, add service definitions for the five most critical services, and extend outward from there.

Use the vendor-evaluation questions above on your next call before committing to a platform — they surface the gaps a sales deck won’t.

Frequently Asked Questions