D3-HCI Hardware Component Inventory: Recording Hardware Components and Keeping the Record Current

Most asset inventories stop at the device: a hostname, a serial number and an owner, with no record of the network cards, storage controllers, management controllers or USB devices inside or attached to it. MITRE D3FEND names the deeper record Hardware Component Inventory (D3-HCI) and defines it as "Hardware component inventorying identifies and records the hardware items in the organization's architecture." It is a Model tactic technique and a child of Asset Inventory, with the synonyms Hardware Component Discovery and Hardware Component Inventorying. This page explains what D3-HCI records, which collection methods deliver it on Windows, Linux, servers and network devices, how to keep it current, and how it feeds detection and hardening. It is written for asset management, endpoint and infrastructure teams who already run a device-level inventory, as described in the MITRE D3FEND Asset Inventory Implementation Guide.

Key takeaways

• Components, not just devices. D3FEND's knowledge base article lists peripherals, network interface cards, processors and memory devices as the items to collect, which is a level below the device record most inventories hold.
• Management protocols do most of the work. D3FEND names SNMP (MIB data), WBEM and CIM through Windows Management Instrumentation, and admin-scripted PCI bus discovery; these are standard, already deployed and cheap to query.
• The value is in change. A component record matters most when it changes: a new USB mass storage device, a swapped network card, a different firmware revision on a module. Baseline it and alert on drift.
• D3FEND's ATT&CK links are inferred. The D3FEND page relates D3-HCI to techniques such as Hardware Additions (T1200) and Compromise Hardware Supply Chain (T1195.003) through the Hardware Device artefact, labelled inferred and experimental.
• Collection needs privilege, so guard the collector. D3FEND notes most of these queries need administrative rights; the service accounts and SNMP credentials behind the inventory are sensitive non-human identities.

D3-HCI at a glance

How it works

D3FEND's knowledge base article describes administrators collecting information on hardware devices "such as peripherals, NICs, processors, and memory devices" using administrative and management tools that query for it. Where those queries are not supported, it says the same information can be collected through remote administration tools and system commands, manually or with scripts. The examples it gives fall into two groups: bus discovery (an admin-scripted PCI bus inventory over SSH with pciutils) and application-layer discovery (SNMP collecting MIB data, and WBEM collecting CIM data through Windows Management Instrumentation or Windows Management Infrastructure).

In practice D3-HCI produces, per asset, a list of components with enough identifying detail to notice change: class, manufacturer, model, serial number where available, hardware revision and firmware revision. The parent device record supplies owner and location.

Collection methods by platform

Two details from the sources matter for data quality. Microsoft's documentation notes that the PNPClass property of Win32_PnPEntity is listed in the MOF file but does not exist in the class, so do not build reports on it; use ClassGuid instead. RFC 6933 says model, firmware and serial values in entPhysicalTable should only be compared among entries with the same manufacturer name, so normalise vendor names before de-duplicating.

What to record

Record what changes a security decision. The list below is an example scope, not a D3FEND requirement.

• Identity fields: component class, manufacturer, model, serial number, vendor and device IDs (PCI or USB), and the parent asset.
• Version fields: hardware revision and firmware revision, so firmware advisories can be matched to components. Firmware verification is covered in D3-PFV Peripheral Firmware Verification.
• Security-relevant capability: removable media ports, wireless and Bluetooth radios, cameras and microphones, management controllers with their own network interface, TPM presence.
• State fields: first seen, last seen, status, and the collector that reported it.
• Lifecycle fields: purchase order or supplier, so a hardware supply chain notice can be traced to installed components.

How to implement

1. Start from the device inventory. D3-HCI hangs off device records from D3-NNI Network Node Inventory; a component without a parent asset cannot be acted on.
2. Use what management tools already collect. Endpoint management and agent-based tools usually gather WMI or Linux hardware data. Check which classes and fields they keep before writing scripts.
3. Add servers and network gear. Query management controllers and ENTITY-MIB with read-only credentials. Use SNMPv3 with authentication and privacy rather than community strings where devices support it.
4. Pilot in a single site. Compare the collected record with a physical check of a sample of devices to find classes the tools miss.
5. Handle OT separately. D3FEND warns that scanning and probing can cause side effects on IT and OT systems. Use passive data, vendor engineering tools and procurement records in OT, following the CISA-led Foundations for OT Cybersecurity asset inventory guidance.
6. Baseline and alert on drift. Store a baseline per asset class and raise a ticket or alert when components appear, disappear or change firmware.
7. Roll back safely. Inventory queries are read-only, so rollback means stopping a collector that overloads devices or disturbs OT; keep a per-site switch to disable each collector.

How D3-HCI feeds other techniques

ATT&CK techniques D3FEND relates to D3-HCI

Relationship type: inferred only. D3FEND hand-maps no ATT&CK technique to D3-HCI. The D3FEND page shows the relations below, which it derives because D3-HCI inventories the Hardware Device artefact and these techniques act on hardware devices or their sub-types; it labels them inferred and experimental (checked November 2026). Each ID was checked against ATT&CK v20. An inventory does not block these techniques; it gives defenders the baseline that makes them visible.

The attacker view of the same data is T1120 Peripheral Device Discovery, which is not a D3FEND relation for D3-HCI. D3FEND itself notes that adversary enumeration may parallel normal hardware inventorying, but would need admin privileges for most of the operations.

Where identity fits

Hardware inventory runs on privileged non-human identities: the WMI account that queries every workstation, the SSH key a script uses to run lspci across Linux servers, the SNMPv3 user on every switch and the management controller account on every server. These credentials reach the whole estate, so give them read-only rights, store them in a secrets manager, rotate them and watch their use from unexpected sources. Record which identities each collector uses in the same inventory. See the How to build a service account inventory from Active Directory guide.

Detection and measurement

• Coverage: share of device records with a component list collected in the last refresh cycle, by platform.
• Freshness: median age of component data; an example target is 7 days for endpoints and 30 days for network gear.
• Drift rate: component changes per 1,000 assets per week, and the share of changes matched to a change ticket.
• Unknown devices: count of USB or PCI device IDs not on the approved list on servers and sensitive hosts.
• Firmware match rate: share of components whose firmware revision is known, which bounds how many advisories you can actually assess.

Framework mapping

Common failure patterns

• Device-only records. Serial and model at chassis level, nothing about the components, so a firmware advisory for a network card cannot be scoped.
• Reports built on missing fields. Queries that depend on Win32_PnPEntity PNPClass return nothing useful; vendor names that are not normalised break de-duplication.
• Servers inventoried only through the OS. Management controllers and their firmware are missed, though they have their own network interface and credentials.
• Active probing in OT. Scripts written for IT run against controllers, which D3FEND warns can cause side effects.
• Collection without baselines. Data is gathered but never compared, so a new device on a payment kiosk or server is never flagged.
• Over-privileged collectors. A domain admin account used for WMI collection becomes the easiest path to every host.

Practitioner checklist

• Link every component record to a parent asset with an owner.
• Collect class, manufacturer, model, serial, hardware and firmware revision per component.
• Use WMI or CIM on Windows, PCI and USB enumeration on Linux, ENTITY-MIB on network devices and management controller interfaces on servers.
• Use SNMPv3 and read-only, vaulted credentials for every collector, and record those identities.
• Use passive and procurement data in OT and test any active query first.
• Baseline approved components per asset class and alert on additions and firmware changes.
• Feed firmware and component versions to vulnerability enumeration and firmware verification.
• Report coverage, freshness, drift and unknown devices monthly.

Standards and references

• MITRE D3FEND: Hardware Component Inventory
• IETF: RFC 6933 Entity MIB (Version 4)
• IETF: RFC 2790 Host Resources MIB
• DMTF: System Management BIOS (SMBIOS)
• DMTF: Redfish
• Microsoft Learn: WMI Tasks, Computer Hardware
• Microsoft Learn: Win32_PnPEntity class
• Linux man-pages: lspci(8)

Related NHI Mgmt Group resources: MITRE D3FEND Asset Inventory Implementation Guide · Asset Inventory and CMDB Security Guide · Firmware and Boot Security Guide · CIS Control 1 Inventory and Control of Enterprise Assets Guide