Official intent
Maintain a validated inventory of operational technology assets as the foundation for OT risk decisions. The official source remains authoritative.
Read the official campaign ↗You cannot protect equipment you have not counted. A validated OT inventory is built passively, confirmed by physical walk-downs, and maintained through change control — not by scanning fragile devices.
Who this applies to: Every environment with controllers, HMIs, drives, historians, or instrumentation — including single-line shops where the inventory is currently one engineer's memory.
Why it matters
Unknown OT assets are unmonitored, unpatched, and often vendor-connected. Every later OT practice — segmentation, vulnerability management, and recovery — depends on this list being real.
Risks this reduces
- Unknown networked devices with no owner, no monitoring, and no patch path
- Serial-connected and safety-instrumented devices omitted from every later control
- Vendor-installed equipment nobody in the plant knows about
- Decisions about segmentation and recovery made against an inventory that is a guess
Active network scanning can interrupt fragile OT devices. Use passive discovery and physical walk-downs first; schedule any active technique inside an approved maintenance window with the process owner present.
Who owns it
Plant / OT leader
OT engineer, Maintenance, Vendors
Medium
Low
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: nothing else on the list. You can start this today.
- Plant leadership backing for walk-down time on the production floor
- Vendor documentation, purchase records, and project files as a starting point
- Agreement that active scanning will not be used as a shortcut
Action timeline
- Name an inventory owner
- Collect existing vendor and project asset lists
- Walk down one production line and record make, model, firmware, connectivity, and criticality with the operators
- Reconcile that line against the vendor and project documentation and investigate anything that appears in only one
- Walk down one production line
- Record make, model, firmware, and connectivity
- Cover remaining lines and remote sites
- Reconcile against passive observations
- Tie updates to every change window
- Set an annual re-walk cadence
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Assign an accountable inventory owner with plant authority.
- Start from vendor documentation, purchase records, and project files.
- Physically walk down each line and verify networked and serial-connected devices.
- Record criticality and process impact with the operators who run it.
- Feed the inventory into change review so it stays current.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
No list, or a vendor spreadsheet nobody has verified against the floor.
Is there anything at all — a tool, a document, a person who owns it? - Documented
An inventory owner is named and the update method — including walk-downs — is written down.
Is the intent written down, with a named owner and a scope? - Configured
Passive discovery is in place on at least one segment and an inventory record exists to reconcile against.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
Every line and remote site is walked down and recorded, including serial-connected and safety-instrumented devices.
Does it cover everything in scope, with the exceptions written down? - Measured
Passive observations are reconciled against the record on a cadence, and unknown assets are investigated and counted.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
An owner runs a scheduled re-walk, signs off the reconciliation, and the inventory drives segmentation, patching, and recovery decisions.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- Pick five random devices on the floor; all five must appear in the inventory.
- Compare passive network observations to the list and investigate unknowns.
- Confirm the inventory changed when the last plant change happened.
Evidence to retain
Inventory ownership and update policy
Inventory export with firmware and connectivity fields
Walk-down worksheets with dates and signatures
Reconciliation report: observed versus recorded assets
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| Walk-down coverage | Production lines and remote sites physically verified within the agreed interval ÷ all lines and sites. | 100% within the plant's chosen cycle. |
| Unknown observed assets | Devices seen by passive monitoring that are not in the inventory. | Zero unresolved; each investigated and either added or removed. |
| Spot-check accuracy | Randomly selected floor devices found in the inventory with correct detail ÷ devices checked. | Five of five on each spot check. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
Treating a vendor spreadsheet as validated, scanning the OT network to save time, and omitting serial-connected or safety-instrumented devices.
Two sized paths
This is a clipboard exercise before it is a tooling exercise. Walk the line with the person who runs it, write down what is there, and note what talks to what. A spreadsheet that reflects the floor beats a discovery platform that was pointed at the wrong subnet.
Run continuous passive discovery that reconciles against the record automatically, treat drift as an investigable event, extend the inventory to firmware versions and communication paths, and let segmentation, vulnerability management, and recovery planning consume it directly.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
The inventory is only maintainable if every plant change updates it. Attach an inventory update to the change record itself; otherwise the list ages out between walk-downs and every dependent control degrades quietly. Walk-downs are themselves plant activity: agree floor access with the process owner, and record safety-instrumented and serial-connected devices deliberately rather than counting only what appears on the network.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The publication treats a validated asset inventory as the foundation for all OT risk decisions and warns against intrusive discovery techniques.
What this does not claim: 800-82 is guidance, not a compliance standard.
Why: The guidance describes building and maintaining a defensible OT asset inventory for owners and operators, which is this practice.
What this does not claim: CISA guidance is advisory. It creates no obligation absent a contract term that adopts it.
Why: The asset-management outcomes cover hardware and software inventories, which the OT inventory instantiates.
What this does not claim: The CSF describes outcomes, not testable controls.
Why: The 2024 edition's security program elements assume an identified asset base before zoning and risk analysis.
What this does not claim: IEC 62443 is a voluntary industrial standard; conformance is a separate, scoped exercise. The 2024 edition restructured the 2010 requirements into Security Program Elements; The specific requirement identifiers are pending verification against the licensed normative text and should be treated as directional until that check completes.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.4.1Baseline configurations and inventoriesPartial implementation supportModerate
Why: A walked-down, verified OT inventory — including serial-connected and safety-instrumented devices no scanner sees — advances the inventory half of this requirement for the operational estate, where paper records and vendor spreadsheets otherwise stand in for knowledge.
What this does not claim: May partially address the requirement, and only where OT assets fall within the assessed CUI boundary — much OT does not. Baseline configurations for controllers, HMIs, and historians are separate work the walk-down does not create, and the IT estate's inventory is outside this practice entirely.
Review status: Pending OT SME review.
Open the 3.4.1 page →NIST SP 800-171 Rev. 3
03.04.10System Component InventoryPartial implementation supportModerate
Why: A walked-down, physically verified OT asset list is component inventory work done to a higher evidentiary standard than network discovery reaches — for the OT portion of a CUI boundary, it is exactly the documented inventory this requirement asks for.
What this does not claim: May partially address the requirement, and only where OT assets sit inside the CUI system boundary — many defense manufacturers' boundaries center on enterprise IT, where this practice contributes nothing. The defined update frequency and the update-on-change integration are process commitments the walkdown itself does not establish.
Review status: Pending NIST SME review.
Open the 03.04.10 page →Review status
| Technical review | Reviewed — pending SME sign-off |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.1 |
This guide has been reviewed by practitioners but is awaiting sign-off from a subject-matter expert in this specific domain. Treat the safety and change-control guidance as a floor, not a ceiling, and validate it against your own process and vendor requirements.