D3-NNI Network Node Inventory Guide

Every detection, patch and segmentation decision assumes you know which hosts, routers, switches and firewalls exist, and the systems that are missing from that list are the ones attackers find first. MITRE D3FEND names this work Network Node Inventory (D3-NNI) and defines it as identifying and recording "all the network nodes (hosts, routers, switches, firewalls, etc.) in the organization's architecture." It is a Model tactic technique, a child of Asset Inventory, with the synonyms System Discovery and System Inventorying. This page covers the collection methods D3FEND names, how to combine active, passive and authoritative sources, how to reconcile them, how to keep the list current, and what to measure. It is written for infrastructure, vulnerability management and SOC teams, and goes deeper on one child of the MITRE D3FEND Asset Inventory Implementation Guide.

Key takeaways

Nodes means all of them. D3FEND's definition covers hosts and network infrastructure alike: routers, switches and firewalls belong in the same inventory as servers and laptops.
Query first, scan where needed. D3FEND describes management tools that query devices, then network enumeration (host discovery and port and service scanning) where queries are not supported or miss detail.
No single source is complete. Device management misses unmanaged devices, scanners miss hosts that are off or roaming, and passive sensors miss quiet hosts. Reconcile at least two.
Cadence is part of the control. CISA BOD 23-01 sets automated asset discovery every 7 days for US federal civilian agencies; that is a useful benchmark for others.
D3FEND's ATT&CK links are inferred. They arrive through the Network Node artefact and point at drift such as new cloud instances and server-side components, labelled inferred and experimental.

D3-NNI at a glance

Attribute	Value
D3FEND ID	D3-NNI (d3f:NetworkNodeInventory)
Tactic	Model
Parent technique	Asset Inventory (D3-AI)
Sibling techniques	Asset Vulnerability Enumeration, Configuration Inventory, Data Inventory, Hardware Component Inventory, Software Inventory
Digital artefact	Network Node (D3FEND relation: inventories Network Node)
Synonyms	System Discovery; System Inventorying
D3FEND references	IEEE 802.1AB (LLDP), RFC 3411 (SNMP architecture), DMTF WBEM, Microsoft WMI and Windows Management Infrastructure, a vendor passive scanning sensor guide
Main limitation	An inventory is a model: it is only as good as its sources and its last refresh

How it works

D3FEND's knowledge base article describes administrators collecting information on network nodes with administrative and management tools that query network devices and nodes, and, where queries are not supported or do not give the information needed, network enumeration "to include host discovery and scanning for active ports and services." Its examples are link-layer discovery (LLDP and Cisco Discovery Protocol) and application-layer discovery (SNMP collecting MIB data, and WBEM collecting CIM data through WMI or Windows Management Infrastructure). Its references add passive sensors that watch traffic and profile devices as they connect.

Collection sources compared

Source	What it finds	What it misses	Risk
Authoritative records: directory, endpoint and mobile device management, cloud provider resource APIs, virtualisation managers	Managed hosts and cloud instances with owner metadata	Unmanaged, rogue and personal devices	Low
Network infrastructure queries: SNMP ARP and neighbour tables (IP-MIB ipNetToPhysicalTable), LLDP neighbours, switch MAC tables, DHCP leases, DNS	Anything that talked on the network recently, with IP and MAC	Quiet hosts; detail about the host itself	Low; needs read access to network devices
Management protocols on the node: SNMP, WMI or CIM, SSH	Operating system, interfaces, hardware for known nodes	Nodes without credentials or agents	Low; needs credentials
Active discovery: host discovery and port and service scanning	Live hosts and listening services, including unmanaged ones	Hosts that are off, roaming or filtered	D3FEND warns of side effects on IT and OT systems
Passive discovery: network sensors on span ports or taps	Devices as they connect, including those hard to scan	Segments without a sensor; silent devices	Very low on the network; sensor placement effort

RFC 4293 moved the old IPv4 ipNetToMediaTable to ipNetToPhysicalTable, which holds IP-to-physical address mappings for both IPv4 (ARP) and IPv6 (neighbour discovery). Collectors that still read only the old table can miss IPv6 neighbours, which matters because BOD 23-01 explicitly covers assets reachable over IPv4 and IPv6.

What to record per node

Identifiers: hostname, IP addresses (v4 and v6), MAC addresses, cloud resource ID or serial number, and a stable internal asset ID.
Type and role: server, workstation, router, switch, firewall, OT controller, printer, cloud instance; business service it supports.
Location: site, network segment or VPC, and switch port where known.
Ownership: technical and business owner, so findings can be routed.
Provenance: which sources reported the node, first seen and last seen per source. This is what makes reconciliation possible.
Management state: managed or unmanaged, agent present, credentialed scan possible.

How to implement

Load authoritative sources first. Import directory, device management, virtualisation and cloud provider inventories with owners. This gives a baseline with context.
Add network-side evidence. Collect DHCP leases, DNS, ARP and neighbour tables and LLDP data from network devices on a schedule. Every IP or MAC seen there but absent from the baseline is a candidate unmanaged node.
Add discovery. Run host discovery across all address space in use, starting with IT segments and a pilot range, and place passive sensors where scanning is unsafe or blocked. In OT, start passive, following the CISA-led Foundations for OT Cybersecurity asset inventory guidance.
Reconcile. Match records on cloud resource ID, serial, MAC and hostname, in that order of trust (an example order, adjust to your data). Keep per-source first and last seen dates rather than overwriting.
Triage unknowns. Each unmatched node gets an owner within a set time or is investigated and blocked. CIS Controls v8.1 Safeguard 1.2 asks for a process to address unauthorised assets.
Automate cadence. Set refresh intervals per source. BOD 23-01 requires federal civilian agencies to "Perform automated asset discovery every 7 days" and to start vulnerability enumeration across discovered assets every 14 days.
Roll back safely. If a scan disturbs a device, exclude the range, switch it to passive collection and record the exclusion so the coverage metric shows the gap.

Decision guidance

Small organisations: device management, the cloud provider's resource inventory, DHCP logs and one scanner usually cover the field. Reconcile monthly.
Large or multi-site estates: add passive sensors at key aggregation points and SNMP or API collection from every network device; reconcile continuously in a CMDB or cyber asset attack surface management (CAASM) tool. See the Asset Inventory and CAASM Buyers Guide.
Cloud-heavy: provider APIs are authoritative for instances, but short-lived nodes appear and vanish between scans; use resource change events rather than periodic polling.
OT and medical: passive first; active queries only with the vendor's guidance and in maintenance windows.

ATT&CK techniques D3FEND relates to D3-NNI

Relationship type: inferred only. D3FEND hand-maps no ATT&CK technique to D3-NNI. The D3FEND page lists the relations below because D3-NNI inventories the Network Node artefact; it labels them inferred and experimental (checked November 2026). Each ID was checked against ATT&CK v20. D3FEND still shows one relation under a revoked ID (Disable or Modify Network Device Firewall); the table gives its v20 successor.

ATT&CK v20 ID	Technique	What the node inventory contributes
T1578.002, T1578.003, T1578.004	Create, Delete and Revert Cloud Instance	Instances that appear, vanish or roll back outside change records show up as drift; see T1578 Modify Cloud Compute Infrastructure
T1505.002, T1505.003	Transport Agent, Web Shell	Knowing which nodes are mail and web servers scopes where to hunt for server-side components
T1114.002	Remote Email Collection	Identifies mail servers and services to watch
T1686.002	Network Device Firewall (successor to the revoked ID D3FEND shows)	Firewalls and network devices in the inventory are the scope for configuration baselining

The adversary does the same discovery: T1018 Remote System Discovery and MITRE ATT&CK T1046 Network Service Discovery are not D3FEND relations for D3-NNI, but your inventory should be more complete than what an attacker can build. D3FEND notes that adversary enumeration can look like normal inventorying, which is why scanners should be registered.

Where identity fits

Two identity points apply. First, discovery tools hold credentials that reach every node: SNMPv3 users, WMI service accounts, SSH keys and cloud read-only roles. Keep them read-only, vaulted and monitored, and register scanner source addresses so their traffic can be told apart from attacker discovery. Second, nodes run workloads with their own identities: service accounts, cloud instance roles and certificates. Recording which machine identities each node uses links the node inventory to the NHI inventory. See the NHI Inventory Reconciliation Guide.

Detection and measurement

Unknown node rate: nodes seen on the network with no owner, as a share of all nodes, and their median time to resolution.
Source agreement: share of nodes reported by at least two independent sources.
Freshness: share of nodes with a last-seen date inside the refresh interval (example: 7 days, following BOD 23-01).
Address space coverage: share of in-use IPv4 and IPv6 ranges covered by discovery or a passive sensor, with exclusions listed.
Infrastructure coverage: share of routers, switches and firewalls with collected configuration and neighbour data.
Alerting: raise alerts for new nodes in server, management and OT segments, and for DHCP leases or ARP entries from unknown MAC prefixes in those segments.

Framework mapping

Framework	Reference	Link to D3-NNI
NIST CSF 2.0	ID.AM-01 hardware inventories; ID.AM-02 inventories of software, services and systems	Nodes are the hardware and systems records
NIST SP 800-53 Rev. 5	CM-8 System Component Inventory; CM-8(2) Automated Maintenance; CM-8(3) Automated Unauthorized Component Detection; PM-5 System Inventory	Inventory, automated upkeep and unauthorised node detection
CIS Controls v8.1	Control 1: Safeguards 1.1 detailed asset inventory, 1.2 address unauthorised assets, 1.3 active discovery, 1.4 DHCP logging, 1.5 passive discovery	Direct
ISO/IEC 27001:2022	Annex A 5.9 Inventory of information and other associated assets	Asset inventory requirement
CISA BOD 23-01	Automated asset discovery every 7 days	Cadence benchmark (binding for US federal civilian agencies)

Common failure patterns

Endpoints only. Laptops and servers are listed but routers, switches, firewalls, printers and management interfaces are not, though they are nodes in D3FEND's definition.
One source treated as truth. The CMDB is overwritten by whichever feed ran last, so evidence from the network never surfaces unmanaged devices.
IPv4 only. Discovery and neighbour collection ignore IPv6, leaving hosts reachable on v6 unlisted.
Ephemeral cloud nodes missed. Weekly scans never see instances that live for hours; cloud events are not used.
Scanning OT like IT. Active scans disturb controllers, collection is then switched off entirely and the gap is never recorded.
Unknowns with no owner. Unmatched nodes are reported but nobody is responsible for resolving them, so the list grows. See If your CMDB and asset inventory is compromised for the opposite risk, when the inventory itself is a target.

Practitioner checklist

Include hosts and network infrastructure in one node inventory.
Import authoritative sources with owners, then add DHCP, DNS, ARP, neighbour and LLDP evidence.
Run host discovery across all in-use IPv4 and IPv6 space, with passive sensors where scanning is unsafe.
Keep per-source first-seen and last-seen dates and reconcile on stable identifiers.
Give every unknown node an owner or a block decision within a set time.
Refresh at least weekly, and use cloud change events for short-lived nodes.
Vault and restrict discovery credentials and register scanner sources.
Feed the node list to vulnerability enumeration, network mapping and detection context.

D3-NNI Network Node Inventory: Finding Every Host and Device and Keeping the List True