Asset Inventory and Monitoring

Why the inventory comes first

"You cannot protect what you do not know" is true everywhere, and more so in operational technology (OT). An OT asset inventory is a maintained list of every device and system in the industrial environment, from controllers and remote terminal units to switches, human-machine interfaces (HMIs), engineering workstations and the serial-to-Ethernet converters nobody remembers installing, with the attributes needed to secure and operate them.

Almost every other measure on the next pages starts from this list:

• Segmentation needs to know which devices belong in which zone (see the Purdue model and OT architecture).
• Vulnerability management needs vendor, model and firmware version to match an advisory to your devices (see patching and vulnerability management in OT).
• Monitoring needs to know what is normal before it can say what is new.
• Incident response needs to know what a device controls and whom to call before anyone touches it.

OT inventories are hard for reasons that IT inventories are not. Devices stay in service for decades, many have no agent you could install and no management interface you would dare to query, and the knowledge often sits in engineering drawings, project files and the heads of the people who commissioned the site. The same approach as in IT applies in principle (see asset inventory first and the CMDB); the methods for gathering the data have to be gentler.

The topic gets steady attention from government agencies. As of 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) and partner agencies published "Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators" (August 2025), and CISA and the UK National Cyber Security Centre followed with guidance on keeping a definitive record of your OT architecture (September 2025). The draft of NIST SP 800-82 Rev. 4 (published September 2026; Rev. 3 is still the final version) expands its guidance on asset management and monitoring.

What to record

An inventory entry is only useful if it answers the questions you will ask later: "are we affected by this advisory?", "is this device allowed to talk to that one?", "what happens if it stops?" and "who decides?". A practical minimum:

The CISA guidance mentioned above structures the work in steps: define the scope, identify the assets, decide which attributes to collect, sort them into a taxonomy (for example by function and criticality), manage the data, and keep it current over the asset's lifecycle. A taxonomy matters more than it sounds: "PLC" and "plc" and "controller" in three spreadsheets make every later query unreliable.

Finding devices: passive and active

There are three sources of inventory data, and a good inventory uses all of them: documentation (engineering project files, configuration backups, drawings, purchase records and a physical walk-down of the cabinets), passive discovery and, carefully, active queries.

Passive discovery

Passive discovery builds the inventory by listening to a copy of the network traffic, without sending a single packet to the devices. A sensor that understands industrial protocols can learn a lot from what it overhears: which addresses talk to which, over which protocol, how often, and often vendor, model and firmware version, because many devices announce them in normal traffic or in replies to the HMI. CISA's 2026 joint guide on zero trust for OT notes that OT inventory tooling "generally relies on passive monitoring, which avoids the risk of disruption".

The limitation is just as clear: passive discovery only sees devices that talk, and only where you listen. A spare controller that is switched off, a device that only communicates over a serial link, or a network segment without a sensor stays invisible.

Getting a copy of the traffic: SPAN and TAP

There are two ways to give a sensor a copy of the traffic. A SPAN port (Switched Port Analyzer, also called a mirror port) is a switch feature that copies the traffic of chosen ports or VLANs to one port where the sensor is connected; the same technique is used for packet captures in network troubleshooting. It costs nothing extra, but the switch gives mirroring a low priority and may drop copies when it is busy, and not every industrial switch supports it.

A network TAP (test access point) is a small hardware device placed in a cable that copies every frame passing through it to a monitoring port. It sees everything, including errors, and cannot be misconfigured into sending traffic back. Unidirectional TAPs only pass traffic out to the sensor, by design. The catch: putting a TAP into a link means briefly disconnecting that link, which in OT is a planned change in a maintenance window, not a quick job.

Active scanning and its risks

Active scanning in OT means sending packets to devices to discover them or ask for their details: a ping sweep, a port scan, a vulnerability scan or a request in the device's own protocol. In IT this is routine (see vulnerability scanning). In OT it is risky, because many field devices have small network stacks built for a few known peers. Traffic they did not expect, such as malformed packets, many connections at once or simply a high packet rate, has made controllers freeze, reboot or drop into a fault state, and a stopped controller stops the process it runs.

Used this way, targeted active queries fill the gaps that passive discovery leaves: silent devices, exact firmware versions, and modules inside a controller rack. Many commercial OT platforms combine both for this reason.

Building and maintaining the inventory

The first version usually comes from merging sources: the engineering documentation says what should be there, passive discovery says what is talking, and a walk-down settles disagreements. After that, the hard part is keeping it current. Three habits help:

• Tie it to change management. A device that is added, replaced or upgraded through a change updates the inventory as part of closing that change.
• Compare continuously. Let passive monitoring compare what it sees with what the inventory expects, and treat every difference as something to explain.
• Review periodically. Walk-downs and owner reviews catch what monitoring cannot see, such as devices that only wake up during maintenance.

Example: expected versus observed

The comparison is simple in principle. This sketch takes the expected inventory, keyed by MAC address, and the devices a passive sensor reported, and lists three kinds of finding: a device nobody registered, a registered device whose firmware or address changed, and a registered device that was not seen at all.

# Compare the expected OT asset inventory with what passive monitoring observed.
EXPECTED = {
    "00:00:5e:00:53:11": {"name": "PLC-PUMP-1", "ip": "192.0.2.11", "firmware": "2.4.1"},
    "00:00:5e:00:53:12": {"name": "PLC-PUMP-2", "ip": "192.0.2.12", "firmware": "2.4.1"},
    "00:00:5e:00:53:21": {"name": "RTU-NORTH", "ip": "192.0.2.21", "firmware": "5.0.3"},
    "00:00:5e:00:53:31": {"name": "HMI-CTRL-1", "ip": "192.0.2.31", "firmware": "n/a"},
}

# What a passive sensor reconstructed from traffic it saw on a mirror port.
OBSERVED = [
    {"mac": "00:00:5e:00:53:11", "ip": "192.0.2.11", "firmware": "2.4.1"},
    {"mac": "00:00:5e:00:53:12", "ip": "192.0.2.12", "firmware": "2.5.0"},
    {"mac": "00:00:5e:00:53:31", "ip": "192.0.2.31", "firmware": "n/a"},
    {"mac": "00:00:5e:00:53:99", "ip": "192.0.2.99", "firmware": "unknown"},
]


def compare(expected, observed):
    findings = []
    seen = set()
    for device in observed:
        mac = device["mac"]
        seen.add(mac)
        known = expected.get(mac)
        if known is None:
            findings.append(("NEW", mac, f"unknown device at {device['ip']}"))
            continue
        if device["ip"] != known["ip"]:
            findings.append(("CHANGED", mac, f"{known['name']} IP {known['ip']} -> {device['ip']}"))
        if device["firmware"] != known["firmware"]:
            findings.append(("CHANGED", mac,
                             f"{known['name']} firmware {known['firmware']} -> {device['firmware']}"))
    for mac, known in expected.items():
        if mac not in seen:
            findings.append(("MISSING", mac, f"{known['name']} not seen"))
    return sorted(findings, key=lambda f: (f[0], f[1]))


results = compare(EXPECTED, OBSERVED)
for kind, mac, detail in results:
    print(f"{kind:<8} {mac}  {detail}")
print(f"{len(EXPECTED)} expected, {len(OBSERVED)} observed, {len(results)} findings")

CHANGED  00:00:5e:00:53:12  PLC-PUMP-2 firmware 2.4.1 -> 2.5.0
MISSING  00:00:5e:00:53:21  RTU-NORTH not seen
NEW      00:00:5e:00:53:99  unknown device at 192.0.2.99
4 expected, 4 observed, 3 findings

Each finding has an innocent and a worrying explanation. The changed firmware on PLC-PUMP-2 may be last week's planned upgrade that nobody recorded, or an unauthorized change; check the change records first. RTU-NORTH may be switched off for maintenance, may sit on a segment without a sensor, or may have failed. The new device at 192.0.2.99 may be a contractor's laptop or a test device left behind. In every case the answer is a conversation with the owner, not a firewall rule.

Network security monitoring in OT

OT network security monitoring is the continuous, passive analysis of traffic in industrial networks to detect unauthorized or unusual activity. It builds on the same ideas as an intrusion detection system, with two important differences.

First, it is protocol-aware. A generic IDS sees "TCP port 502"; an OT monitor decodes the Modbus request inside and knows whether it reads a value or writes one, and likewise for DNP3, IEC 60870-5-104, IEC 61850 and the other industrial protocols. Second, it relies heavily on a baseline. Office traffic is chaotic; industrial traffic is remarkably regular. The same HMI polls the same controllers for the same values every second, for years. After a learning period, the monitor knows what normal looks like, and almost anything new deserves a look:

• New devices or connections: a host that never talked before, or a known host talking to a controller it never addressed.
• Unusual function codes: writes from a host that normally only reads, a controller being put into stop or program mode, a program or firmware download, outside a planned change.
• Protocols that do not belong: remote desktop or file sharing into the control level, or traffic to the internet from a device that should never leave its zone.
• Timing: engineering software connecting to controllers at night, or polling that suddenly stops.

2026-10-06 02:14:07 UTC  severity: high
rule:     program download to controller outside change window
source:   198.51.100.40 (not in inventory)
target:   192.0.2.11 PLC-PUMP-1 (zone: substation-north control)
protocol: vendor engineering protocol, function: download program block
baseline: source never seen talking to this zone before

Accurate timestamps matter when alerts from many sensors and systems are correlated; make sure sensors use the same time source as the rest of the network (see NTP).

Process anomalies versus network anomalies

A network anomaly is unusual traffic. A process anomaly is unusual physical behavior: a measured value outside what the equipment can physically reach, a value changing faster than physics allows, a valve that moves while the controller says it is closed, or two sensors on the same pipe that disagree. Its cause can be a failing sensor, a genuine process upset, an operator mistake or manipulation.

The two signals complement each other. An attacker who has stolen an operator's credentials and uses the operator's own tools produces traffic that looks perfectly normal; in the December 2015 attacks on Ukrainian distribution companies, breakers were opened remotely with legitimate credentials. In such a case the process values may be the first sign. Conversely, a process anomaly without any network explanation points to the field equipment.

Example: range and rate checks

The simplest process checks need no machine learning, only knowledge of the equipment. This sketch checks a series of transformer oil temperatures, one reading per minute, against a plausible range and a maximum rate of change. The limits are illustrative; real ones come from the equipment's engineers.

# Flag suspicious readings in a transformer top-oil temperature series (one per minute).
LOW, HIGH = -25.0, 105.0      # physically plausible range for this sensor, in degrees C
MAX_STEP = 2.0                # oil this size cannot heat or cool faster than this per minute

readings = [61.2, 61.5, 61.9, 62.1, 71.4, 71.6, 62.4, 62.6, 140.0, 62.9, 63.0]


def check(series, low, high, max_step):
    alerts = []
    previous = None
    for minute, value in enumerate(series):
        if not low <= value <= high:
            alerts.append((minute, value, "out of range"))
        elif previous is not None and abs(value - previous) > max_step:
            alerts.append((minute, value, f"changed {value - previous:+.1f} in one minute"))
        if low <= value <= high:
            previous = value   # only plausible values become the new reference
    return alerts


for minute, value, reason in check(readings, LOW, HIGH, MAX_STEP):
    print(f"minute {minute:>2}: {value:6.1f} C  {reason}")

minute  4:   71.4 C  changed +9.3 in one minute
minute  6:   62.4 C  changed -9.2 in one minute
minute  8:  140.0 C  out of range

Minutes 4 and 6 show a jump of about 9 °C and back: the oil of a large transformer cannot change temperature that fast, so either the sensor or its signal path is suspect. Minute 8 is outside the physical range altogether. The out-of-range value is deliberately not used as the reference for the next reading, so one bad value does not trigger a second alert. Statistical and AI-based methods go further (see anomaly detection), but simple physical rules are easy to explain to operators, which matters when an alert asks them to distrust their own screen.

Tools

The tools below are examples, named neutrally and as of 2026; this market changes quickly.

• Zeek: an open-source network security monitor that turns traffic into detailed logs. It ships with analyzers for some industrial protocols, such as Modbus and DNP3, and more can be added as packages.
• Malcolm: an open-source traffic analysis suite from CISA and Idaho National Laboratory (INL), under the Apache 2.0 license. It bundles Zeek, Suricata, Arkime and OpenSearch, with parsers for Modbus, DNP3, IEC 60870-5-104, S7comm, BACnet, EtherNet/IP, PROFINET, OPC UA and more. A good way to learn what passive monitoring shows.
• Commercial OT monitoring platforms, which combine passive discovery, inventory, vulnerability matching and anomaly detection: for example Nozomi Networks (fully owned by Mitsubishi Electric since January 2026), Claroty, Dragos and Microsoft Defender for IoT, and others such as Forescout, Tenable OT and TXOne.

Whichever tool you choose, the sensor placement decides what it can see. A sensor at the IT/OT boundary sees traffic entering and leaving OT, but not a compromised engineering workstation talking to a controller inside the same zone. Regulation increasingly expects monitoring inside OT, not only at its edge:

Feeding alerts to the SOC

OT monitoring is only useful if someone acts on the alerts. In many organizations that is the security operations center (SOC), which already collects IT events in a SIEM. Sending OT alerts there lets analysts see an attack that moves from the office network toward the control systems as one story instead of two unrelated ones. The data flows out of OT, typically from the monitoring console at site level through the industrial DMZ, never as a new path into the control network.

Three things make this work:

• Context in the alert: the asset name, zone, function and criticality from the inventory, so an analyst knows that "192.0.2.11" pumps cooling oil.
• OT-specific playbooks: the standard IT reflex, isolating the host, can stop a process or blind the operators. OT playbooks say who in operations to call first and which actions are never taken without them (see incident response in OT).
• Shared tuning: OT engineers help the SOC tell planned engineering work from suspicious activity, for example by linking alerts to approved changes.