Ask most plant managers where the asset inventory lives and you’ll get a pause, then a version of “the spreadsheet from the commissioning project” or “whatever the 62443 assessment gave us two years ago.” That answer used to be fine. It won’t be much longer. The Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) is moving through CISA’s rulemaking process with a final rule expected to land in the 2025–2026 window, and once it’s in force, covered entities in critical infrastructure sectors — manufacturing included, depending on sector and size thresholds — will have to report substantial cyber incidents within a tight window, commonly cited as 72 hours, and ransomware payments even faster.
That reporting clock is the headline. The part that should actually keep MES and plant IT leads up at night is what it takes to meet that clock. You cannot report accurately on an incident involving assets you can’t identify. If your first move during an intrusion is “let’s figure out what’s even on this network,” you have already lost most of your 72 hours to discovery instead of response and disclosure. CIRCIA doesn’t just create a reporting obligation — it retroactively exposes whether your asset inventory was ever real in the first place.
Why the spreadsheet approach was always going to break
Most OT asset inventories in manufacturing were built once, for a purpose that wasn’t ongoing compliance. Commissioning teams document what they install. Integrators hand over a network diagram. An IEC 62443 zone-and-conduit assessment produces a snapshot, usually a spreadsheet or a PDF appendix, that’s accurate on the day it’s delivered and starts decaying immediately after.
Then reality happens: a controls engineer swaps a failed HMI panel for whatever was on the shelf, a vendor remotes in during a service call and leaves a jump box configured differently than before, a line gets a firmware update during a shutdown that nobody logs back to the master list. None of that is negligence — it’s just how plants actually operate. But it means the “inventory” is really a historical document that gets less true every month, and nobody owns the job of keeping it current because it was never treated as a living system.
What actually counts as a covered asset
Before you can build a defensible inventory, you need a working definition of scope, because “everything with an IP address” is both too narrow and too vague to be useful. A reasonable practitioner definition includes:
- Control-layer devices: PLCs, RTUs, safety instrumented systems, drives, and any device executing control logic — whether or not it’s networked.
- Supervisory and HMI layer: SCADA servers, HMI panels, historian servers, engineering workstations.
- MES and MOM systems: the servers, edge gateways, and integration middleware that bridge ISA-95 Level 2/3, since these are increasingly the pivot point attackers use to move from IT into OT.
- Network infrastructure: industrial switches, firewalls, wireless access points, remote access appliances — especially any vendor-installed remote support gateway, which is consistently one of the least-documented asset classes on a plant floor.
- Firmware and software versions for each of the above, not just the hardware make and model.
- Ownership — who is accountable for patching, configuration changes, and decommissioning of each asset class. An asset without an owner is an asset nobody will report correctly under pressure.
Notice that “what firmware is it running” and “who owns it” are baked into that list. That’s deliberate. A CIRCIA-grade inventory has to answer both, because incident reports increasingly ask for exactly that level of specificity, and CISA’s ongoing ICS advisory cadence — the steady stream of vendor-specific vulnerability disclosures — is only useful to you if you can immediately map an advisory to the affected firmware version sitting on your floor.
Passive discovery tools and engineering records aren’t the same thing — you need both
A common mistake is assuming a passive network monitoring platform solves the inventory problem outright. It doesn’t, and understanding why matters. Passive OT discovery tools — the category that includes network traffic analysis platforms built for industrial protocols — are excellent at finding what’s actually talking on the wire: device fingerprints, protocol behavior, communication patterns, and often firmware version strings pulled from packet inspection. They’ll surface the rogue engineering laptop and the forgotten remote access box that no one remembers installing.
What they can’t tell you is context: which line that PLC controls, who’s accountable for it, what the change management history looks like, or what’s sitting air-gapped and never transmits. That’s the domain of the engineering record — the CAD drawings, the network topology diagrams, the control narrative documents, the vendor commissioning packages.
A defensible inventory reconciles both sources continuously, not once. Passive discovery tells you what’s real on the network right now. The engineering record tells you what’s supposed to be there and who’s responsible for it. The gap between those two lists — the assets discovery finds that engineering records don’t explain, and the assets on paper that discovery never sees traffic from — is exactly where your risk concentrates, and exactly what an auditor or incident responder will ask about first.
Don’t forget the SBOMs you’ve already been collecting
Plenty of OT vendors have been sending software bills of materials for a while now, often without much fanfare, as part of broader supply-chain transparency expectations tied to federal procurement and vulnerability disclosure practices. Most plants file them and move on. Under a CIRCIA reporting posture, that’s a wasted asset. An SBOM tells you the software components and libraries embedded in a given device or application — which matters enormously when a CISA advisory drops referencing a vulnerable open-source library buried three layers deep in a vendor’s firmware stack. If your asset inventory doesn’t cross-reference SBOM component data against the advisory’s affected-version list, you’re stuck doing that mapping by hand, under deadline, during an actual incident. Reconciling SBOMs against your asset inventory should be a standing quarterly task, not a one-time filing exercise.
A maturity checklist you can run this quarter
Score your plant honestly against these before a regulator or an incident does it for you:
- Do you have a single system of record for OT assets, or does the truth live across spreadsheets, integrator handoffs, and someone’s memory?
- Is passive network discovery data reconciled against engineering records on a recurring schedule — not just run once during an assessment?
- Can you produce firmware/version data for every control-layer asset without contacting the OEM first?
- Does every asset have a named owner responsible for its patch and change history?
- Are vendor remote-access gateways and jump boxes explicitly inventoried, not assumed to be covered under “network infrastructure”?
- Are SBOMs from vendors actually cross-checked against active CISA ICS advisories, rather than filed and forgotten?
- Could your team assemble an accurate, scoped list of affected assets within a few hours of a suspected incident — not a few days?
If you answered no to more than two or three of those, the honest read is that your inventory is a historical artifact, not an operational one. CIRCIA’s final rule will set the legal floor, but the practical floor — being able to answer “what’s on this network, what’s it running, who owns it” fast enough to matter — is worth meeting regardless of when the rule takes effect. The plants that treat asset inventory as a living, owned, continuously reconciled system will find compliance nearly incidental. The plants still relying on the commissioning-era spreadsheet are going to find out how expensive that gap is at the worst possible moment: mid-incident, with a clock running.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
