NIS2 Asset Inventory Requirements: What You Need to Track and How to Do It On-Premise

The revised EU NIS2 Directive expands and tightens cybersecurity obligations for industrial and critical infrastructures. One of the foundational mandates is comprehensive asset inventory: knowing exactly what you own, where it resides, and what role it plays in your operational ecosystem. For CISOs, IT leaders, and plant engineers, this requirement is both a technical challenge and a business imperative. This deep-dive aims to dissect what NIS2 expects regarding asset inventories, why this is not “just another spreadsheet exercise,” and how to actually implement effective, on-premise tracking in heterogeneous industrial environments.

Section 1: NIS2 and the Core of Asset Management Requirements

What NIS2 Actually Says

Article 21 of the NIS2 Directive explicitly references the need for security measures such as "asset management and the management of security-related risks." Practical interpretation—especially as articulated in ENISA guidelines—focuses on ensuring that organizations maintain a comprehensive, up-to-date inventory of network and information systems, and their dependencies.

For most operators, “inventory” means every system vital to continuity and security, not just workstations and servers, but PLCs, RTUs, SCADA servers, sensors, network switches, and even embedded controllers long ignored in classic IT asset schemes.

• Digital Asset Awareness: Including all hardware, software, and virtual constructs.

• Dependency Mapping: Understanding interconnections and data flows, not just endpoint lists.

• Lifecycle Tracking: Monitoring asset provenance, operational status, patch level, and decommission schedules.

Historical Context: Fractured Asset Inventories

For decades, asset inventories in OT have lagged behind their IT counterparts. Early attempts leveraged hand-maintained CAD diagrams, Excel files, or network diagrams—methods effective only until the next brownfield expansion or vendor intervention. The IT world professionalized inventories with help from SNMP, LDAP directories, CMDBs, and later, automated discovery like nmap, SCCM, and specialized asset software. Yet, these mostly failed in OT, where a PLC rarely supports SNMP, and passive discovery struggles with non-IP fieldbuses or custom hardware.

Industrial operators are thus left with fragmented, often unreliable asset lists—an unacceptable risk by NIS2 standards.

Section 2: What You Need to Track—A Technical Breakdown

Defining “Critical Assets” in Industrial & Critical Environments

NIS2’s language assumes context: the asset list must include all hardware and software actively involved in providing, maintaining, or supporting essential operations. In practice, this includes:

• IT assets: Servers, workstations, VMs, databases, HMIs, network infrastructure (switches, firewalls).

• OT assets: PLCs, RTUs, DCS controllers, field sensors, actuators, protocol gateways, legacy serial devices.

• Software/firmware: OSes, control logic, application binaries, custom scripts deployed to industrial endpoints.

• Communication assets: Wireless access points, interconnects bridging IT/OT, VPN gateways, remote access infrastructure, modems.

• Non-IP and Layer 1/2 assets: Serially connected sensors, fieldbus repeaters, proprietary protocol bridges, etc.

Compare this with an old-school IT asset sheet and the scope expansion is clear. This is not limited to devices with assigned IP addresses or managed by AD/GPO.

Data Fields Required for Each Asset

Using insights from IEC 62443, ENISA, and real-world operations, an effective asset record should, at minimum, contain:

• Physical location (plant, rack, GPS coordinate if remote)

• Type/classification (server, PLC, sensor, etc.)

• Network address(es), serial numbers/MACs

• Firmware/software version, patch/update history

• Ownership, custodian, and vendor/supplier

• Criticality (impact if unavailable or compromised)

• Connected dependencies (e.g., which sensor feeds which PLC)

• Deployed security controls (e.g., hardening, firmware integrity)

The minimum requirement: Where is it? What is it? Why does it matter? How is it exposed or protected?

Section 3: Reality Check – Inventory Collection in On-Premise Industrial Systems

The Limits of Auto-Discovery in OT/ICS

Automated discovery, a staple in enterprise IT, often fails in OT environments. Active scanning can trip safety systems, cause outages, or wake up “silent” vulnerabilities. Passive network monitoring is valuable but incomplete for non-Ethernet or out-of-band devices.

• Active Scans: Risk: Standard tools like nmap or Nessus can disrupt serial networks, legacy devices.

• Passive Monitoring: Limit: Only sees IP traffic—misses isolated fieldbus loops, proprietary links.

• Manual Asset Entry: Reality: Still required, especially for “dark assets” (non-networked PLCs, chart recorders, etc.)

Bridging the IT/OT Divide

OT teams and IT security operate with different risk tolerances. Rolling out aggressive discovery is easy in the office, but fiddling inside a critical process line is another matter. The best technical approach is a mix of:

1. Leveraging Existing Data: Extract asset lists from configuration management, EAM/CMMS systems, Syslog, historian databases, or vendor PLC programming software.

2. Deploying Passive Asset Discovery Where Feasible: Mirror core industrial switch SPAN ports to OT-aware sensors (like those supporting deep protocol parsing for Profinet, EtherNet/IP, etc.).

3. Structured Manual Updates: Where automatic means fall short, train techs and operators to update inventory on change (deploy/decommission/upgrades), with standard change forms feeding a central repository.

Technical Example: Passive Industrial Protocol Parsing

Modern passive asset discovery solutions parse raw traffic for vendor-specific protocols; e.g., decoding Siemens S7 comms to list S7-1200s, firmware, project files loaded, and comm path dependencies. This gives greater visibility than generic port scanning—but is still limited to traffic observable on a given segment, and no help for off-network assets.

Section 4: The On-Premise Asset Inventory: Architecture and Process

Why On-Premises?

Whether for regulatory, latency, or security reasons, most industrial operators avoid cloud-only management—especially for critical asset data. On-site asset management enables auditable control, air gap support, and easier integration with existing plant applications.

Reference Architecture: A Modular, On-Prem Asset Inventory System

• Central Asset Repository: SQL database or industry SCADA/CMMS with structured asset tables. Should support vendor-specific fields and extensibility (ideally via API for later integration).

• Data Ingestion:

  • Automated (where possible): Passive collectors; agents on supported OT/IT endpoints; direct pulls from domain controllers or historian logs.

  • Manual/assisted input: Role-based forms for plant engineers, accessible via secure internal web apps. Barcode and NFC tagging for rapid data entry.

• Change Management: All asset changes flow through controlled processes (change tickets, system events, or both), with audit trails and versioning.

• Security: Role-based access, strong logging, and backups. Machine identities (e.g., signed asset manifests from PLC programming software) increase rigor.

A typical workflow: automated discovery populates the “known” portion of your asset estate; field technicians add or validate “unseen” assets (especially non-IP equipment) during routine maintenance or projects.

Data Quality and Lifecycle Operations

• Regular Reviews: Periodic audits verify accuracy—by walking the floor, cross-referencing config files, and checking against change tickets.

• End-of-Life Tracking: Link inventory to decommission/shutdown plans to prevent “zombie asset” drift.

• Incident Response: Link asset inventory to EDR and SIEM/ICS monitoring, so breach alerts can be mapped to physical and functional systems in seconds.

Section 5: Practical Recommendations and Pitfalls

Lessons Learned From the Field

• Don’t trust “set and forget” – Every real-world inventory is out-of-date the minute a contractor swaps a PLC or updates field code. Processes for ongoing update/import are as important as the tool.

• Human-in-the-loop is necessary – Even with best-in-class passive discovery, someone needs to contextualize (“that’s not a sensor, it’s a backup PLC running in cold standby”).

• Documentation debt is real – If you rely on Excel, it will be wrong within a month. Invest in structured tools, even if home-built.

• Cross-department buy-in – Asset inventory only works when both IT and OT leadership demand and enforce updates. Neither can own it alone.

Section 6: Conclusion: Building Useful, Compliant Asset Inventories is Core Security Hygiene

NIS2 rightly raises the bar for asset awareness, seeing it as necessary groundwork for everything from patch management to incident containment and regulatory reporting. In industrial and critical environments, this means going far beyond what classic IT inventories have delivered. True compliance—and real risk reduction—demands a process-driven, on-premise inventory approach blending automation, manual input, and continuous validation. In short: you can only secure what you can see—and prove to others that you know you have.

References: NIS2 Directive (EU 2022/2555), ENISA Guidance, IEC 62443, SANS ICS Security Field Reports.