Official intent
Maintain a comprehensive, current inventory of the devices, identities, and applications you defend. The official source remains authoritative.
Read the official campaign ↗You defend what you can see. A comprehensive inventory covers hardware, cloud and on-prem software, and — increasingly — identities and service accounts. Build it from authoritative sources, reconcile the sources against each other, and keep it current through change control rather than an annual scramble.
Who this applies to: Universal. This is the practice every other practice silently assumes, and the one most often declared complete when it is a stale spreadsheet.
Why it matters
Unknown assets are unmanaged assets: unpatched, unmonitored, and often still trusted on the network. Almost every other basic — patching, MFA coverage, segmentation, backup — silently assumes a complete list. When the inventory is wrong, those controls have blind spots you never chose.
Risks this reduces
- Unmanaged devices that never receive patches, policy, or monitoring
- Orphaned accounts belonging to people who left
- Shadow SaaS holding company data outside any agreement
- Silent coverage gaps in every control that assumes a complete list
Who owns it
IT leader
Identity administrator, Procurement, MSP
Medium
Low to medium
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: nothing else on the list. You can start this today.
- Administrative read access to the endpoint manager, identity provider, and cloud consoles
- A named owner with authority across IT and cloud, not just one team
- Agreement on what counts as an asset — devices only, or identities and applications too
Action timeline
- Name an inventory owner
- Pull existing lists from MDM, identity provider, and procurement
- Merge the endpoint, identity, and procurement exports into one record and mark the rows that appear in only one source
- Flag every device with no owner and every account with no matching employee
- Merge the sources into one record
- Flag devices with no owner or no management agent
- Add cloud/SaaS applications and privileged service accounts
- Reconcile the identity provider against HR joiners and leavers
- Tie every add/change/retire to onboarding and offboarding
- Set a monthly reconciliation and quarterly review
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Assign an accountable inventory owner with authority across IT and cloud.
- Seed the inventory from authoritative sources: MDM/endpoint manager, identity provider, DNS/DHCP, cloud consoles, and procurement.
- Reconcile the sources against each other and investigate anything that appears in one but not the others.
- Extend beyond hardware to SaaS applications, service accounts, and privileged identities.
- Connect the inventory to onboarding, offboarding, and change control so it stays current by default.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
No list, or several partial lists nobody reconciles.
Is there anything at all — a tool, a document, a person who owns it? - Documented
An inventory policy names the owner, the authoritative sources, and the update cadence.
Is the intent written down, with a named owner and a scope? - Configured
Discovery is switched on in the endpoint manager and identity provider, and exports can be produced on demand.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
One reconciled record covers hardware, cloud and SaaS applications, and identities across the whole estate.
Does it cover everything in scope, with the exceptions written down? - Measured
Unmanaged-asset counts and source-reconciliation discrepancies are reported monthly and trend down.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
A named owner signs off a periodic review, and the inventory drives patching, licensing, and access decisions.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- Pick ten devices from the network at random; all ten must appear in the inventory with an owner.
- Compare the identity provider's active accounts against the HR leaver list — there should be no orphaned accounts.
- Confirm the last device added to the network appears in the inventory.
Evidence to retain
Inventory policy naming the owner, sources, and cadence
Inventory export covering hardware, software, cloud apps, and identities
Monthly reconciliation report with investigated discrepancies
Quarterly review sign-off and joiner/leaver reconciliation
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| Managed coverage | Devices carrying a management agent ÷ devices observed on the network or in the identity provider. | Above 95%, with the remainder explained. |
| Ownerless assets | Inventory rows with no named owner. | Zero. |
| Orphaned accounts | Active accounts with no matching current employee or approved service purpose. | Zero at each monthly reconciliation. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
A spreadsheet updated once a year, hardware counted but SaaS and identities ignored, and orphaned accounts from departed staff left active. A list nobody reconciles is a guess, not an inventory.
Two sized paths
You almost certainly already own the sources: the endpoint manager, the identity provider, and the accounting system that shows what you bought. Export all three into one spreadsheet, add an owner column, and reconcile monthly. A dedicated inventory product is not the first purchase — a named owner and a recurring calendar entry are.
Make the inventory a system of record with automated ingestion from endpoint, identity, cloud, network, and procurement sources, and treat unmatched observations as investigable events. Extend to software bills of materials and service accounts, and let downstream systems (patching, access review, licensing) consume the inventory rather than keeping private lists.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
The inventory only stays true if adds, changes, and retirements flow through a process that updates it. Tie it to onboarding and offboarding first — that is where most drift originates — before investing in discovery tooling.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The CMMC practice inherits the 800-171 requirement text directly.
What this does not claim: Supports the requirement; it does not satisfy it on its own and does not establish an assessment outcome. Scope, implementation quality, and evidence decide that.
Why: The CSF asset-management outcomes cover hardware and software inventories explicitly.
What this does not claim: The CSF describes outcomes, not testable controls. It is a planning aid here, not a measure of completion.
Why: Enterprise and software asset inventories are the first two CIS controls and describe the same activity.
What this does not claim: CIS is a voluntary benchmark. Alignment with it carries no contractual weight.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.1.1Authorized access controlDependencyModerate
Why: You cannot limit access to authorized users, processes, and devices without an authoritative list of which users, processes, and devices exist. The reconciled inventory this practice maintains is the reference the requirement's enforcement and evidence are both measured against.
What this does not claim: The inventory authorizes nothing and blocks nothing at connection time — it is the precondition, not the enforcement. Account lifecycle discipline, device gating, and the authorization decisions themselves are separate work the requirement still demands.
Review status: Pending NIST SME review.
Open the 3.1.1 page →3.3.2Individual accountabilityDependencyModerate
Why: Tracing actions to individuals presumes the account list is clean, and the practice's monthly reconciliation is what finds the orphaned accounts and unowned logins that break attribution — an account with no matching employee can never be traced to anyone.
What this does not claim: The inventory attributes nothing at logging time: unique accounts, shared-account elimination, and identity captured in the records are separate work implemented in the systems doing the logging. Absent those, a perfectly reconciled account list still leaves this requirement unimplemented.
Review status: Pending NIST SME review.
Open the 3.3.2 page →3.4.1Baseline configurations and inventoriesDirect implementation supportHigh
Why: One reconciled record of hardware, identities, and applications, kept current through onboarding, offboarding, and change control, is the inventory half of this requirement implemented as an operating routine rather than a document.
What this does not claim: The requirement has two halves and the practice carries one: baseline configurations — the documented, maintained known-good state of each system type — are separate work the inventory does not produce. An assessor evaluates both halves across the organization's defined system boundary, including systems the discovery sources never see.
Review status: Technical review complete.
Open the 3.4.1 page →3.5.1User and device identificationDependencyModerate
Why: A reconciled inventory of devices, accounts, and applications is what makes 'identify every user, process, and device' checkable at all — the practice produces the reference list this requirement's coverage is measured against.
What this does not claim: The inventory itself identifies nothing at authentication time. It provides the evidence base for the requirement; the identification mechanisms are separate work, and coverage must be evaluated within the organization's defined system boundary.
Review status: Pending NIST SME review.
Open the 3.5.1 page →3.5.6Inactive identifier handlingOperational supportModerate
Why: The practice's account-inventory reconciliation is the operational routine that surfaces dormant identifiers — the same accounts this requirement wants disabled after defined inactivity.
What this does not claim: Surfacing dormant accounts is not disabling them: the requirement needs a defined threshold and an enforcement mechanism, which the inventory practice does not itself configure. Provides evidence relevant to the requirement rather than implementing it.
Review status: Pending NIST SME review.
Open the 3.5.6 page →3.12.3Continuous control monitoringOperational supportModerate
Why: The practice's reconciliation cadence — comparing directory, endpoints, and applications against the inventory on a schedule — is a standing effectiveness check of the kind a continuous-monitoring program is assembled from: unknown devices and unmanaged accounts surfacing in reconciliation are drift caught in operation.
What this does not claim: One recurring check is not a monitoring program. The requirement expects ongoing monitoring across the breadth of implemented safeguards, with a defined view of what is checked, how often, and where findings go; the practice contributes a strong instance of that pattern, while the strategy, the breadth, and the response path are separate work.
Review status: Pending NIST SME review.
Open the 3.12.3 page →3.12.4System security planEvidence supportModerate
Why: An SSP's boundary description and component story stand on the inventory: a reconciled register of devices, identities, applications, and connections is the factual substrate the plan's system description must match. Where the inventory is current, the SSP can be checked against reality instead of memory.
What this does not claim: An SSP is authored governance work that no practice produces: the boundary judgment, environment description, implementation statements, and interconnection details are written, owned, and updated deliberately. The inventory keeps the descriptive sections truthful — it writes none of them, and a plan without an owner and an update cadence goes stale regardless of inventory quality.
Review status: Pending NIST SME review.
Open the 3.12.4 page →3.14.6Attack monitoringContextual relationshipModerate
Why: Monitoring coverage is measured against the asset inventory: 'monitor organizational systems' presumes a list of the systems, and the reconciled inventory this practice maintains is what makes monitoring gaps visible at all.
What this does not claim: The inventory monitors nothing. It informs where sensors, agents, and log sources must exist without detecting a single attack indicator; the monitoring capability itself — tooling, alerting, triage, ownership — is entirely separate work evaluated on its own evidence.
Review status: Pending NIST SME review.
Open the 3.14.6 page →NIST SP 800-171 Rev. 3
03.01.01Account ManagementDependencyModerate
Why: Account management presumes a trustworthy answer to 'what accounts exist, and for whom?' The practice's reconciled inventory of identities, devices, and applications is the reference list against which account creation, disablement clocks, and periodic reviews are checked.
What this does not claim: An inventory neither authorizes nor disables anything. The lifecycle mechanics this requirement asks for — defined account types, disablement within defined periods, notification flows, periodic reviews — are separate work that the inventory only makes checkable. It contributes the evidence base, not the account management itself.
Review status: Pending NIST SME review.
Open the 03.01.01 page →03.04.01Baseline ConfigurationDirect implementation supportHigh
Why: A current baseline configuration can only be developed and kept current for components the organization knows it has, and the practice's reconciled inventory of hardware, software, and applications is that substrate. The relationship was seeded against Rev. 2's 3.4.1, where baselines and inventories were one requirement.
What this does not claim: Rev. 3 narrows this requirement to the baseline configuration itself — the inventory half of Rev. 2's 3.4.1 now lives in 03.04.10, where this practice maps on its own terms. Inventory work identifies what exists; it does not author, version, or review the baseline documents this requirement is about, and it does not satisfy the requirement on its own.
Review status: Technical review complete.
Open the 03.04.01 page →03.04.10System Component InventoryDirect implementation supportHigh
Why: Developing, documenting, and updating a component inventory is this practice's core activity — discovery-driven, reconciled on a cadence, corrected when things are installed and removed. Rev. 3 giving the inventory its own requirement makes this the practice's most direct configuration-management relationship.
What this does not claim: The requirement is scoped to the CUI system's components and wants updates at a defined frequency and as part of installations, removals, and updates — an organizational inventory carries it only when filtered to the system boundary and wired into change control. Supports implementation of the requirement; scope, the defined frequency, and evidence still decide the assessment outcome.
Review status: Pending NIST SME review.
Open the 03.04.10 page →03.05.05Identifier ManagementOperational supportModerate
Why: The practice's account-inventory reconciliation is the routine that keeps identifier management honest — surfacing dormant identifiers, unowned service accounts, and departures that slipped past process, which is the population every lifecycle decision in this requirement acts on.
What this does not claim: Surfacing identifiers is not authorizing, assigning, or quarantining them: the requirement's authorization step, reuse-prevention period, and individual-status characteristic are procedure and directory work the inventory does not perform. Provides the checkable population and operating evidence rather than implementing the requirement.
Review status: Pending NIST SME review.
Open the 03.05.05 page →03.15.02System Security PlanEvidence supportModerate
Why: An SSP describes the system boundary, its components, and its connections — and the reconciled asset inventory is where those descriptions come from and how they stay true. The practice's normal operation keeps the plan's factual backbone current.
What this does not claim: An SSP is authored governance work — implementation statements, boundary decisions, and update discipline that no inventory produces. The practice provides evidence relevant to the plan's accuracy, while the plan itself, its defined update frequency, and its protection from disclosure are separate obligations this practice does not touch.
Review status: Pending NIST SME review.
Open the 03.15.02 page →Review status
| Technical review | Reviewed |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.0 |