Asset Inventory Maturity Model: Five Levels

Almost every organisation has an asset list, yet few can say how much of their estate it covers, how current each record is or who owns the assets it lists, so vulnerability, patching and incident teams work from data they do not trust. This model uses NHI Mgmt Group's five levels (Ad hoc, Developing, Defined, Managed and Optimised) to score an asset inventory programme on three outcomes, coverage, accuracy and ownership, across seven capability areas. Each level has evidence tests, so a score can be defended to an auditor or a board. It is for asset and configuration managers, vulnerability management leads, security architects, CISOs and auditors. For how to build and secure the inventory itself, read the Asset Inventory and CMDB Security Guide; for the safeguard detail, the CIS Control 1 Inventory and Control of Enterprise Assets Guide. This page tells you how far along you are and what to do next.

Key takeaways

Measure three things, not one: coverage (what share of real assets are in the record), accuracy (how many records are current and correct) and ownership (how many have a live, accountable owner). A large inventory can score badly on all three.
A scan is not an inventory: discovery tools feed the record; the record is the reconciled, approved list with owners and status. CIS Safeguard 1.1 is a record, 1.3 to 1.5 are the feeds.
Freshness is a hard line: the CIS Controls Assessment Specification scores Safeguard 1.1 as failing if the inventory has not been updated for more than six months, and the NCSC advises recording a confidence score or last-seen time on every record.
Level 3 is where the record becomes authoritative: one named system of record, reconciled from several sources, with defined fields and an unknown-asset process that runs every week.
Identities are assets too: service accounts, API keys, certificates and AI agents attach to assets and need the same owner and lifecycle; higher levels link the two records.

The five levels

Level	Name	What it looks like
1	Ad hoc	Assets tracked in spreadsheets, procurement records and tool consoles that disagree. No owner for the inventory as a whole. Cloud and SaaS largely absent. Nobody can state coverage. Unknown devices are found during incidents or audits.
2	Developing	A CMDB or asset tool exists and endpoint management feeds it. Some cloud accounts imported. Discovery scans run but results are not reconciled. Owner field present but often blank or stale. Inventory updated for audits rather than continuously.
3	Defined	Written asset management standard naming one system of record, mandatory fields and asset classes (endpoints, servers, network, IoT and OT, cloud, SaaS, software). Records reconciled from at least three independent sources. Every record has an owner taken from the identity provider or HR. Unknown assets triaged weekly: register, remove, block or quarantine. Criticality assigned.
4	Managed	Coverage, accuracy, ownership and staleness measured monthly by asset class. Daily active discovery, DHCP and cloud API feeds update records automatically. Assets are registered at provisioning, not found afterwards. Vulnerability, patching, monitoring and access control consume the record and report gaps back. Non-human identities linked to the assets they run on.
5	Optimised	Inventory changes are event driven: build pipelines, cloud APIs and procurement create and retire records as changes happen. Confidence scores per record. Decisions such as network access, certificate issue and incident scoping rely on the record and fail safe when an asset is missing. Coverage gaps are found by comparing the record with external attack surface and network traffic, and closed within a target time.

Capability areas

Score each area separately. A level is reached only when every statement for that level is true across all asset classes in scope, not just for a pilot site or the endpoint fleet.

Area	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
Scope and asset classes	Laptops and servers only, defined by whoever keeps the list	Written scope covering endpoints, servers, network, IoT and OT, cloud resources, SaaS, software and regularly connected devices not under enterprise control	Scope reviewed when the business changes (acquisitions, new clouds, AI platforms); out-of-scope decisions recorded with a reason
Discovery sources	One tool, usually endpoint management	At least three independent feeds, for example endpoint agent, active network discovery, DHCP or IPAM logs and cloud provider APIs	Active, passive and API sources across all networks and clouds; passive collection where active scanning is unsafe, such as OT
Reconciliation and accuracy	Duplicates and conflicts left in place	Matching rules documented; conflicts resolved by a source precedence order; last-seen date on every record	Confidence score per record; accuracy sampled and verified; stale records retired automatically after a set period
Ownership and criticality	Owner blank or set to a team mailbox	Named owner from the identity provider or HR on every record; criticality and data sensitivity assigned for servers, cloud and SaaS	Owner changes follow leavers and reorganisations automatically; assets with a departed owner flagged within days
Lifecycle	Assets added when someone remembers; disposal untracked	Registration required before first network use; end-of-support dates recorded; retirement updates the record	Provisioning and decommissioning pipelines write to the record; certificates and network access issued only to registered assets
Unknown and unauthorised assets	Found during incidents	Weekly triage of discovered but unregistered assets, with each outcome recorded	Unregistered assets automatically limited (quarantine network, no certificate) until triaged
Consumers and integration	Security tools keep their own lists	Vulnerability and patch management scope taken from the record; gaps reported both ways	Monitoring, access control, incident response and risk reporting all use the record as their source

Evidence for each level

Level	Acceptable evidence	Not sufficient on its own
2 Developing	Exported inventory with record counts by class; list of feeds; date of last update	A CMDB licence or a one-off discovery scan
3 Defined	Asset management standard; field definitions; reconciliation rules; weekly unknown-asset log with outcomes; owner completeness figure	An inventory updated only before audits
4 Managed	Monthly metrics pack by asset class; automated feed logs; evidence that vulnerability scope and patch reports come from the record	Tool dashboards with no trend or reconciliation
5 Optimised	Pipeline integration showing records created and retired automatically; examples where a missing record blocked access or a certificate; gap-closure times	Claims of "real-time" without measured confidence

Why the Level 3 line sits at reconciliation

CIS Controls v8.1 Control 1 asks organisations to "actively manage (inventory, track, and correct) all enterprise assets". Safeguard 1.1 requires an accurate, detailed and up-to-date inventory of every asset that can store or process data, with network address (if static), hardware address, machine name, data asset owner, department and whether the asset is approved to connect, reviewed at least every six months. The other safeguards add the feeds and the clock: 1.2 handles unauthorised assets weekly, 1.3 runs active discovery daily, 1.4 uses DHCP logs and 1.5 passive discovery. The assessment specification measures accuracy as the share of everything discovered that is accounted for in the detailed inventory. That is a reconciliation measure, which is why a single feed, however good, cannot reach Level 3. The NCSC's asset management guidance makes the same point from the other side: combine active sources such as agents and scanning with passive ones such as DNS, DHCP and authentication logs, add procurement, device management and PKI records, and maintain an authoritative record that everyone agrees reflects the environment, using several sources to expose inconsistencies.

Measuring coverage, accuracy and ownership

Most programmes stall because they cannot show progress. These metrics give a defensible score at each level. Targets are NHI Mgmt Group recommendations; set your own in the asset management standard.

Metric	How to calculate	Level 3 target (ours)	Level 5 target (ours)
Coverage	Assets seen by any discovery feed in the last 30 days that are in the record, divided by all assets seen	90% for endpoints and servers	98% across all classes
Accuracy	Sampled records whose key fields (owner, location, OS, status) are verified correct, divided by records sampled	85%	95%
Ownership	Records with an owner who is an active person in the identity provider, divided by all records	95% for servers, cloud and SaaS	99% across all classes
Staleness	Records with no feed seeing the asset in 30 days (14 for servers), divided by all records	Below 10%	Below 2%
Unknown asset dwell time	Median days from first discovery of an unregistered asset to a recorded decision	7 days, the CIS Safeguard 1.2 cadence	1 day
Downstream gaps	Assets in vulnerability, EDR or log tools but not in the record, plus the reverse	Measured and falling	Near zero, with exceptions logged

Collect data at a cadence that suits the asset. The NCSC suggests weekly for servers and possibly daily for desktops, and recording a last-seen timestamp or confidence score so that consumers know how far to trust each record. For US federal agencies, CISA Binding Operational Directive 23-01 set a concrete benchmark: automated asset discovery every 7 days covering at least the whole IPv4 space, and vulnerability enumeration across all discovered assets, including roaming laptops, every 14 days. These cadences are useful reference points for any organisation.

Where identity fits

Ownership is an identity attribute. An owner field that points to a disabled account means the asset is unowned, so Level 3 requires owners drawn from the identity provider or HR system, and Level 4 flags assets whose owner has left. The link also runs the other way: service accounts, API keys, SSH keys, certificates and AI agents live on assets and act on their behalf. When a server is retired, the identities it used should be retired too; when an unknown host appears, the credentials it presents tell you who built it. The NCSC recommends issuing certificate identities only to registered assets. At Level 4 and above, link the asset record and the non-human identity inventory so each can find gaps in the other. See the NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments and NHI Inventory Reconciliation.

Self-assessment questions

Can you state, with a figure and a date, what share of your real assets are in the record, by asset class?
Is there one named system of record, and do security tools take their scope from it?
How many independent feeds update the record, and do they cover cloud, SaaS and OT as well as endpoints?
Does every record carry a last-seen date, and how many have not been seen for 30 days?
What share of records have an owner who is an active person today?
When discovery finds an unregistered asset, who decides what happens, and within how many days?
Are assets registered at provisioning, or found after they are already in use?
When an asset is retired, are its certificates, service accounts and keys retired too?
Can incident responders scope an affected population from the record in under an hour?
Do you compare the record with external attack surface data and network traffic to find what it misses?

Score each question 0 (no), 1 (partly) or 2 (yes, with evidence). A total under 8 suggests Level 1 or 2, 8 to 14 Level 3, and above 14 Level 4 or 5. This scoring is our heuristic; the capability table is the authoritative test.

Moving up: roadmap

Level 1 to Level 2

Appoint a single owner for the inventory as a whole and secure senior sponsorship.
Choose the system of record. For a small organisation a controlled spreadsheet with an owner and a review date is acceptable at this stage.
Connect endpoint management and the main cloud accounts as the first feeds.
Agree the mandatory fields, starting with the CIS Safeguard 1.1 set.

Level 2 to Level 3

Write the asset management standard: scope, asset classes, fields, source precedence and the unknown-asset process. Use the Asset Management Policy Template.
Add independent feeds: active network discovery, DHCP or IPAM logs, cloud provider APIs and the SaaS admin consoles or identity provider application list.
Run reconciliation in report-only mode for a month to measure duplicates and conflicts before cleaning up; keep the pre-clean export so changes can be rolled back.
Populate owners from the identity provider; route records with no owner to the business unit head for assignment.
Start the weekly unknown-asset triage and log every outcome.

Level 3 to Level 4

Publish the monthly metrics pack (coverage, accuracy, ownership, staleness, dwell time) by asset class.
Require registration at provisioning: build templates, cloud landing zones and procurement write the record first.
Make vulnerability, patch and EDR scope come from the record and report gaps back.
Link non-human identities to the assets they run on.

Level 4 to Level 5

Move feeds to event-driven updates from pipelines and cloud APIs.
Add a confidence score per record and use it in decisions.
Gate network access and certificate issue on registration, with an emergency exception path that is logged and reviewed.
Compare the record with external attack surface and traffic data on a schedule. See the Attack Surface Management Maturity Model.

For tooling choices at Level 3 and above, see the Asset Inventory and CAASM Buyers Guide and the Asset Inventory and CAASM RFP Template.

Operational technology and IoT

OT changes the method, not the goal. In August 2025 CISA, with the NSA, FBI, EPA and partner agencies in Australia, Canada, Germany, the Netherlands and New Zealand, published "Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators". It sets out five steps (define scope and objectives, identify assets and collect attributes, create a taxonomy by criticality or function, manage and collect data, and implement lifecycle management) and lists high-priority attributes including communication protocols, criticality, asset role, IP and MAC address, manufacturer, model, operating system, physical location, ports and services, logging and user accounts. Combine physical walkdowns with passive network monitoring, because active scanning can disrupt fragile devices. Score OT as its own asset class in this model. See the OT Asset Visibility Guide.

Framework mapping

Framework	Reference	Relevant levels
NIST CSF 2.0	ID.AM-01 hardware inventories; ID.AM-02 software, services and systems inventories	Level 2 onwards
NIST CSF 2.0	ID.AM-05 assets prioritised by classification and criticality; ID.AM-08 lifecycle management	Level 3 onwards
NIST SP 800-53 Rev 5	CM-8 System Component Inventory; CM-8(1) updates during installation and removal; CM-8(3) automated unauthorised component detection; PM-5 System Inventory	CM-8 at Level 3; enhancements at Levels 4 and 5
CIS Controls v8.1	Control 1 Safeguards 1.1 to 1.5; Control 2 for software	1.1 and 1.2 at Level 3; 1.3 to 1.5 at Level 4
MITRE ATT&CK v20	T1200 Hardware Additions	Unknown-asset detection at Levels 4 and 5

Common failure patterns

Treating the scanner output as the inventory: discovery finds what is reachable today; without reconciliation there is no owner, approval status or history.
Tool-by-tool truth: the vulnerability scanner, EDR console and CMDB each hold a different count, and nobody reconciles them, so gaps sit exactly where tools disagree.
Owner fields that point at leavers or team mailboxes: the record looks complete, but nobody is accountable when a vulnerability or incident needs a decision.
Cloud and SaaS left out: the inventory was designed for data centres and laptops, so short-lived cloud resources and business-bought SaaS never appear.
Audit-driven updates: the inventory is refreshed before each audit and drifts in between, which is exactly when attackers find what has drifted.
Exposed services nobody recorded: hosts stood up for testing or a project and left running with management interfaces open.

Lessons from incidents

In the Carbonato Botnet 2026, attackers infected Docker hosts whose daemons were exposed on port 2375 without authentication, then used an AI agent to hunt AI API keys, SSH keys and tokens on them. The customer-side lesson for inventory maturity is that ports, services and exposure are asset attributes: an inventory at Level 4 that records listening services and compares them with an approved baseline would flag an unauthenticated container API long before it was found by someone else.

Practitioner checklist

Name one owner and one system of record for the asset inventory.
Write a scope that covers endpoints, servers, network, IoT and OT, cloud, SaaS and software.
Connect at least three independent discovery feeds and reconcile them with documented rules.
Put a last-seen date on every record and retire records not seen within your set period.
Populate owners from the identity provider and flag assets whose owner has left.
Run weekly triage of unregistered assets and log every decision.
Require registration at provisioning for new servers, cloud resources and devices.
Make vulnerability, patch and EDR scope come from the record, and report gaps both ways.
Link service accounts, keys, certificates and agents to the assets they run on.
Report coverage, accuracy, ownership and staleness monthly by asset class.

Asset Inventory Maturity Model: From Spreadsheets to a Trusted Security Asset Record