ID.AM-01 Hardware inventory: requirements and evidence

What ID.AM-01 hardware inventory requires in NIST CSF 2.0

If a CSF assessment, a customer questionnaire or audit preparation asks how you know what hardware you run, the answer points to ID.AM-01, the Subcategory that calls for inventories of the hardware the organization manages to be kept current. It sits in the Asset Management (ID.AM) Category under the Identify Function of CSF 2.0, and it continues the same identifier from CSF 1.1 (ID.AM-1), so an existing inventory control can usually be carried forward rather than rebuilt. In plain terms, you need a list of physical and virtual hardware you are responsible for, and a process that keeps that list accurate as devices arrive, change and leave.

The risk behind the outcome is simple: a device you do not know about cannot be patched, configured, monitored or recovered. Unknown laptops, forgotten servers, rogue access points and unmanaged printers all become entry points or blind spots during an incident. Operational technology (OT) and Internet of Things (IoT) devices are missed most often because they were installed by facilities, engineering or vendors outside the IT asset process, they often lack agents, and they may never appear in an endpoint tool. Mobile devices used for corporate email are a similar gap when enrollment is handled by a different team. Before any assessment, confirm which business units own equipment on your networks and whether their assets reach the central inventory at all.

A practical starting point is to decide what the inventory must record (owner, location, network address, function, classification and support status) and which sources feed it, such as directory services, DHCP and switch records, endpoint management, and network discovery scans. Ask your team and any managed service provider to show, for a sample of recent network segments, how each discovered device is matched to an inventory record and how the gap is handled. Discovery tooling can be self-hosted, and GLPI's Assets module is one open-source option for recording hardware entered manually or pushed by an agent. Whatever you choose, confirm with the vendor which hardware types and network segments the product can actually see, including OT segments that may need passive discovery.

Which devices and teams fall inside the ID.AM-01 scope

ID.AM-01 asks for a current inventory of the hardware the organization manages, so scope starts with what counts as managed and who is accountable for each device class. The cards below separate the device classes from the teams that own them, and flag the scoping decisions that change how much inventory work is needed.

IT endpoints and servers

Laptops, desktops, virtual host hardware and physical servers are the classes most organizations inventory first, usually through the IT service desk and procurement. Confirm whether bare-metal hypervisors, backup appliances and out-of-band management cards are recorded as separate line items, since they are often missed. Ask who updates the record when a machine is reimaged, reassigned or retired, because stale ownership is the most common gap in endpoint inventories.

Network infrastructure and storage

Switches, routers, firewalls, wireless access points and storage arrays carry the organization's traffic and data, and they are frequently managed by a network or storage team rather than the desktop group. Record firmware version, management address and physical location for each item, not only the model. Check whether storage shelves and tape libraries attached to servers appear in the inventory, because they are easy to overlook when the server record is the only entry.

IoT, printers and peripherals

Printers, cameras, badge readers, smart displays and environmental sensors often join the network through building or facilities projects with no entry in the IT asset register. These devices frequently run embedded firmware that IT cannot patch through standard endpoint tools. Make an explicit decision on whether they fall in scope, and if they do, assign each class an owner and a discovery method, such as network scanning, so new arrivals are detected.

OT and plant control systems

Programmable logic controllers, human-machine interfaces, engineering workstations and industrial gateways belong to plant engineering or operations teams and may be managed under safety or uptime rules. NIST's Implementation Examples for ID.AM-01 name OT explicitly, so these devices count even when IT has no administrative access. Agree in writing who performs discovery on OT networks, since active scanning can disrupt fragile controllers, and record which site each device serves.

Mobile devices

Company-owned phones and tablets are in scope for ID.AM-01 because they hold organizational data and connect to internal services. Bring-your-own-device enrollment is a separate decision: confirm whether personal devices enrolled for email or messaging appear in the inventory, and which fields are captured for them. The mobile device management platform or the HR onboarding process is usually the source of truth, so verify that the two records match.

Contractor-owned and third-party managed devices

Devices owned by contractors, managed service providers or sites run by a third party can connect to the organization's network, which is the scoping decision that changes the most work. Decide whether a device that is on your network but not on your books counts as managed, and document the rule. For third-party managed sites, confirm in the contract who maintains the inventory and how the organization receives it, since the organization remains accountable for the outcome.

How an assessor tests the hardware inventory

The assessor starts with the written inventory and the process that keeps it current. They look for a defined scope covering every hardware type the organization manages, including IT, IoT, OT and mobile devices, and for fields that identify each device well enough to find it again, such as asset ID, owner, location, serial number and status. They also want to see how the inventory changes: who adds a device when it is bought, who removes it when it is retired, and how often the record is reconciled against procurement, imaging and disposal records.

Scope statement: a written definition of which hardware is in the inventory and which is excluded, with the reason for any exclusion.
Required fields: identifiers, owner, location and lifecycle status for each record, so a device can be traced and challenged.
Update procedure: named steps for onboarding, transfer and retirement, tied to purchasing and the service desk.
Reconciliation records: dated evidence that the inventory was compared with an independent source, such as a network scan or a licensing report, and that differences were resolved.
Version history: change logs or export snapshots that show the inventory is maintained over time, not rebuilt just before the audit.

Before the assessment, confirm that the procedure describes what staff actually do, because an assessor will compare the document with the records it produced.

How to build a hardware inventory that stays current

This sequence moves from defining what counts as hardware and who owns it, through discovery and reconciliation, to continuous detection and a standing review cycle, so the inventory stays accurate after the first clean-up.

Define hardware categories and owners
Start by agreeing which hardware the organization manages and where its boundaries sit. List the categories in scope, including IT endpoints, servers, network equipment, IoT, OT and mobile devices, and name an accountable owner for each category, such as the desktop team for endpoints or the operations team for plant equipment. Record the category list and owners in a short scope document approved by the people responsible for IT and OT. The step is complete when every category has one owner and the scope document has been signed off.
Pull discovery data from existing tools
Collect what the organization already knows from endpoint management, directory services, hypervisors, firewalls, switches and vulnerability scanners. Export device records from each source into one working dataset, keeping the source name and collection date on every row so later reconciliation can trace each entry. Where open-source tools are in place, such as GLPI for asset records or Wazuh for endpoint inventory, use their exports as inputs. The output is a single raw dataset with a source field on each record and a count per source.
Reconcile against procurement and CMDB records
Compare the discovery dataset with purchase orders, asset registers and the configuration management database. Flag devices seen in discovery but absent from procurement records, records with no device behind them, and mismatches in serial numbers, locations or owners. Assign each flagged item to its category owner for a decision: confirm, correct, retire or investigate. The step closes when every discrepancy has a recorded disposition and a named person who made it, which becomes the baseline inventory.
Turn on continuous network discovery
A baseline goes stale as soon as a new device connects, so enable ongoing detection of hardware on the network. Configure scheduled or passive discovery across the address ranges and segments in scope, including OT networks where the operations team approves active scanning, and send new-device findings to the inventory platform so records update automatically. Confirm the coverage by testing with a device that is known to be absent from the baseline and checking that it appears. The output is a documented list of discovery sources, their scope and a test result showing a new device was detected.
Set a review and removal cadence
Decide how often each category owner reviews their part of the inventory and how long a device can be missing from discovery before it is flagged for removal or investigation. Write these rules into the inventory procedure and make them part of the change process so decommissioned and lost devices are removed deliberately. Record each review with its date, reviewer and changes made. The step is done when the cadence is approved, scheduled in the owners' calendars and the first review has been logged. Ask your auditor which review frequency they expect to see as evidence.
Assign an owner for inventory exceptions
Some devices will not fit the standard records, such as equipment that cannot run a discovery agent, vendor-managed devices or devices in transit. Name one exception owner who approves each exception, records the reason, the compensating method used to track the device and a review date. Keep the exception register separate from the main inventory so unexplained gaps are easy to see. The output is an exception register with a named owner for every entry and no unowned items.

Which evidence shows ID.AM-01 is met

An assessor testing ID.AM-01 wants to see that the hardware inventory is complete, current and actively maintained, not just present. The cards below cover the artifacts that prove this: dated exports, discovery results, resolved exceptions, the written procedure and change records. Each one needs a refresh cadence between audits so the evidence still describes the environment on the day it is examined.

Dated inventory exports

A hardware inventory export is the primary artifact, and it only counts as evidence when it carries a generation timestamp, the scope it covers and the tool that produced it. Record which device classes are included, including IT, IoT, OT and mobile devices, so an assessor can see that the population matches the organization's stated scope. Regenerate and archive the export on a fixed schedule, and keep prior versions so changes can be traced over time. Confirm with the asset management owner which systems are the system of record, because an export from a secondary tool may not match the authoritative list.

Discovery scan reports

Discovery reports show what is actually on the network, which is the test of whether the inventory is complete. Passive and active scans, endpoint agent check-ins and switch or DHCP records each reveal different devices, so keep reports from more than one method. Wazuh's Syscollector can gather hardware and system details from endpoints it manages, while network discovery covers unmanaged devices that agents never reach. Archive each scan with its date, address range and result count, and compare consecutive scans to spot new or missing hardware.

Reconciliation records for unknown devices

Reconciliation records close the gap between what discovery found and what the inventory lists. Each unrecognized device needs a row showing who investigated it, the outcome (added to inventory, authorized and tagged, isolated, or removed) and the date it was resolved. An assessor will often sample these rows to test whether the process works in practice. Set a review interval for open items and track how long unresolved devices remain, so that a backlog does not quietly become the normal state.

Written inventory procedure

The written procedure states who maintains the inventory, which device classes and network segments it covers, how discovery is run, how exceptions are handled and how often the inventory is reviewed. Assessors compare what staff do with what the document says, so the procedure should match the tools and cadences actually in use. Name the tools by role, such as the CMDB or the GLPI Assets module, and record the version of the procedure and its approval date. Review it at least when the tooling or network architecture changes.

Change records for added and retired devices

Change records link each device addition or retirement to an authorized request, a named approver and a completion date. They show that the inventory moves through a controlled process instead of changing silently, and they support the claim that the inventory is current. Check that retired devices are removed from the inventory and that disposal is recorded elsewhere under asset life cycle controls. Sample records against recent discovery reports to confirm that every new device on the network has a matching change, or a reconciliation entry explaining why it does not.

What meeting ID.AM-01 costs in money and effort

This table lists the cost components of an ID.AM-01 hardware inventory, who is typically paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to scope a quote and to see where self-hosted open-source tooling can reduce license spend, while labor and review costs remain.

Cost component	One-time or recurring	Who is paid	What drives the cost
Discovery tooling or licenses	Recurring when licensed per device or per seat	Software vendor, or internal team if self-hosted	Device count and whether discovery is commercial or open source; self-hosted GLPI and Wazuh remove most license spend but not hosting or staff time
Agent deployment to endpoints	One-time rollout, then recurring upkeep	Internal IT or an implementation partner	Number of endpoints, operating system mix, and how many machines are reachable through existing management tooling
Engineering time to integrate sources	One-time	Implementation partner or internal platform engineers	Number of sources such as directories, hypervisors, MDM, network controllers and cloud accounts, plus how cleanly each exposes device data
OT-safe discovery design	One-time design, recurring review	Internal OT engineers, controls specialists or a partner with industrial experience	Number of OT sites, whether passive monitoring is required, and the change windows and vendor restrictions that govern active scanning of control devices
Network monitoring for new devices	Recurring	Internal network or security operations staff	Number of network segments, sensor placement, and alert volume from rogue device detection, including tuning effort
Ongoing reconciliation	Recurring	Internal asset owners and IT operations	Rate of hardware change, mobile device churn, and the number of authoritative sources that disagree about the same device
Evidence preparation for assessors	Recurring at each assessment cycle	Internal compliance lead, optionally supported by a partner	Sampling scope the assessor selects, the number of sites, and whether exports and change records are already retained
External review and auditor sampling	Recurring at each assessment cycle	Independent auditor or assessor, and any outside reviewer you engage	Assessment scope and sample sizes set by the assessor; ask the auditor to confirm the sample method before fieldwork

Who owns the inventory, who builds it and who assesses it

The organization owns ID.AM-01. That means it decides what counts as a managed device, who is accountable for each asset record, how often the inventory is reconciled, and what happens when an unknown device appears on the network. A partner or tool can collect data, but it cannot accept the risk of an inaccurate inventory on the organization's behalf. Internal ownership usually sits with IT operations or security, with named owners for OT and mobile device records where those are managed separately.

Accountability: Name one owner for the hardware inventory process and separate owners for any OT or IoT segments managed by plant or facilities teams.
Definitions: Write down which device classes are in scope, including IT, IoT, OT and mobile devices, and which are excluded with a reason.
Reconciliation cadence: Set how often discovery data is compared with procurement, asset and configuration records.
Exception handling: Decide who approves an unmanaged device and who removes it when it is not authorized.
Records: Keep the inventory and its change history in a system the organization controls.

Before engaging anyone, confirm that the internal owner can produce the inventory on request and explain every gap between discovery results and the asset register.

Where hardware inventories usually fail assessment

Assessors rarely fail a hardware inventory for being small. They fail it for being incomplete in predictable places: operational technology, mobile devices, stale lists and unowned devices. The cards below cover the gaps we see most often and the check that closes each one.

OT and IoT left out

Inventories built from IT directories often omit programmable logic controllers, building systems, cameras, sensors and vendor-managed appliances. ID.AM-01 covers all hardware types, including OT and IoT, so an inventory that stops at the corporate network leaves a visible hole. Check whether the inventory was built from network discovery or from a list of IT-owned assets, and whether plant or facilities teams were asked to confirm their equipment. Close the gap by agreeing with OT owners which device classes are in scope and recording who maintains each one.

Mobile devices not tracked

Phones and tablets often enter the environment through bring-your-own-device programs or are issued outside the standard procurement path. ID.AM-01 names mobile devices explicitly, so an inventory without them fails the outcome. Check whether enrollment in a mobile device management tool, or a documented exception, exists for every device that accesses organizational data. Close the gap by linking mobile enrollment to the hardware record so that a device cannot reach corporate systems without an inventory entry.

Inventories never reconciled

A spreadsheet that was accurate at purchase drifts quickly as devices are replaced, repurposed or retired. Assessors ask when the inventory was last compared against what the network actually shows, and who signed off on the differences. Check for dated reconciliation records and open variance items. Close the gap by scheduling a recurring comparison between the inventory and discovery data, with a named owner for each discrepancy and a closing date.

Discovery limited to managed endpoints

Agents and domain-joined machines are easy to count, but they miss printers, switches, firewalls, unmanaged laptops and devices that never installed an agent. A discovery method that only sees what already reports in gives a false sense of completeness. Check which network segments are scanned passively or actively, and whether discovery results are compared with DHCP leases, switch port tables or firewall logs. Close the gap by treating network-level discovery as the source of truth for new devices and agent data as an enrichment layer.

No owner for unknown devices

When discovery finds a device nobody recognizes, the common failure is that the alert goes to a shared mailbox and nothing happens. Assessors look for a defined process that routes an unknown device to a responsible owner, decides whether to authorize, isolate or remove it, and records the decision. Check whether the alert queue has an accountable role and whether closed alerts link to a decision. Close the gap by naming an owner for each network segment and writing a short triage procedure with a time expectation agreed by leadership.

Questions about ID.AM-01 cost, effort and scope

How much effort does a first hardware inventory take?

No researched figure exists for the effort of a first hardware inventory, so the honest answer depends on your environment. The main drivers are the number of sites, the mix of device types (IT, IoT, OT and mobile), how many devices are unmanaged or undocumented, and whether asset records already exist in a CMDB, spreadsheet or procurement system. Expect most of the work to be reconciling conflicting sources, not scanning. Ask any partner for a written estimate that lists the device classes in scope, the discovery methods used and the number of sites visited or reached remotely, and confirm the effort with your own asset data before you commit.

Can our own team build a hardware inventory without outside help?

Yes, many organizations do this in-house, especially when the environment is small and well documented. ID.AM-01 asks for an inventory that is kept current and that detects new hardware, so the harder part is the ongoing process, not the first list. An internal team needs time from network, endpoint and OT owners, a named owner for the inventory, and a rule for who approves a new device. Outside help is usually more useful for the initial discovery across mixed IT and OT networks, where scanning can disrupt fragile equipment and where the team lacks an owner for each segment.

How long does a hardware inventory project take?

No supplied fact gives a duration, so treat any timeline as provisional until scope is written down. Duration depends on the number of sites and network segments, how quickly stakeholders provide access and approvals, and how many devices need manual verification. Separate the first inventory from the ongoing monitoring phase, since the first is a finite project and the second is a recurring operation. Ask for milestones tied to deliverables, such as a reconciled inventory for each segment, rather than a single end date.

What does the client need to provide before a hardware inventory starts?

The client provides access and accountability, and the partner cannot supply either. Expect to provide network diagrams or segment lists, read access to existing asset, CMDB, endpoint management and procurement records, credentials or agent deployment rights where required, and written approval for any scanning in production and OT environments. You also need named owners for IT, OT, mobile and facilities equipment, plus a change window for anything that touches live systems. Confirm these prerequisites in the written scope so that delays are visible early.

Does NIST certify a hardware inventory or the organizations that run one?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. NIST CSF 2.0 is voluntary for most organizations, so you show alignment through your own evidence, and an independent assessor can review that evidence if a customer or regulator asks for it. DeployOpen prepares systems, inventories and evidence, but does not issue audit reports, attestations or certifications.

When should we bring in an implementation partner for hardware inventory?

Bring in a partner when the inventory has to cover a mixed or hard-to-reach estate, when internal teams lack time or skills for discovery, or when a customer or assessor needs evidence on a fixed schedule. A partner is also useful when you need the inventory wired into existing tools, such as an open-source asset management platform or a network monitoring tool. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. Ask for the written scope before deciding.

What recurring costs follow a one-time hardware inventory?

The first inventory is a one-time project, but keeping it current recurs. Plan for ongoing time from asset owners who approve new devices, for the platform that collects and stores records, and for periodic reconciliation when devices are retired, replaced or moved. Open-source options such as GLPI and Wazuh carry their own licensing terms, so review the GPL licence obligations with counsel before deployment. Ask any partner to separate one-time setup from recurring support and to state what the retainer covers.

How DeployOpen scopes the hardware inventory work

DeployOpen prepares the hardware inventory and its evidence inside your environment, under a fixed written scope agreed before work starts. The scope should name the networks, cloud accounts, data centers, OT segments and mobile device management tenants that are in play, the device classes to be covered (IT, IoT, OT and mobile), the systems of record that will hold the inventory, and the people who will confirm the final list. DeployOpen does not issue assessment results, attestations or certifications. Those come from your independent auditor or assessor, and your organization owns the controls and the decisions about what counts as an approved asset.

In practice, the scope turns on a few decisions you should make before any discovery runs. Decide which platform is the authoritative inventory, for example GLPI's Assets module, and which tools feed it, such as the GLPI Agent or the Wazuh Syscollector module for endpoints. Decide how unmanaged or newly detected devices are handled, including who approves onboarding and how a device is quarantined or removed. For OT and IoT segments, agree in writing how passive discovery will be run so that it does not disrupt operational systems. Each of these choices becomes a line item in the statement of work, so the quote can be checked against them.

Ask any implementation partner, DeployOpen included, to state in the written scope which deliverables are inventory exports, configuration records, runbooks and a reconciliation report, and which are your responsibility, such as approving the final inventory and retaining it for your auditor. Confirm with your assessor, before the work starts, which evidence they expect for ID.AM-01 and in what form. Doing this early keeps the engagement limited to preparing evidence, and it makes clear that the conclusion on whether ID.AM-01 is met belongs to your independent assessor.

How DeployOpen prepares ID.AM-01 evidence

DeployOpen works on ID.AM-01 by preparing the hardware inventory and its evidence inside your own infrastructure, using self-hosted open-source platforms. We build and document the inventory, but your organization owns the control and an independent assessor decides whether the evidence meets your target.

How we scope

The written scope names which hardware classes are covered, including IT, IoT, OT and mobile devices.
Scope defines the networks and segments the discovery tooling must monitor for new hardware.
Scope lists the inventory fields, owners and update triggers agreed before any work starts.

How we build

We deploy an inventory platform such as GLPI in your environment and configure its Assets module.
We set up automated collection from endpoints, including Wazuh Syscollector for hardware data where it fits.
We configure network monitoring to flag unrecognized devices so the inventory is updated when new hardware appears.

How we hand over

You receive configuration documentation, the inventory data model and a runbook for daily operation.
Deliverables include a record showing how new hardware is detected, reviewed and added to the inventory.
Sample inventory reports and mapping notes to ID.AM-01 are provided so your assessor can trace the evidence.

How we support

Ongoing support, upgrades and continuous testing of the inventory tooling are available as a retainer.
A retainer can cover periodic reviews of inventory completeness against your network and asset records.
Confirm with us in writing which support tasks, response expectations and review cadence the retainer includes.

ID.AM-01 Hardware inventory