Endpoint inventory · ITAM · CMDB · 11 minute read

Make endpoint inventory trustworthy before a CMDB project starts

A CMDB does not repair uncertain endpoint records. It gives them a more formal home. Use this readiness checklist to establish durable identity, provenance, ownership, lifecycle, freshness, and exception handling before synchronizing the data.

By Kip Ecklund, founder of NizloLast reviewed October 31, 2026

Start with the decisions the inventory must support

Inventory becomes useful when it helps someone decide what to do. Before defining a schema, list the recurring questions the data must answer: Which device is this? Who is responsible for it? Is it still managed? What changed? Which source supports the answer? What action is due when the evidence conflicts?

NIST SP 800-53 control CM-8 describes a component inventory that accurately reflects the system, includes the necessary components, avoids duplicate accounting, uses the needed level of granularity, and is reviewed and updated. Those properties are a useful operating test even when an organization is not adopting the control as a compliance requirement.

Eight fields for a minimum trustworthy endpoint record

Keep the first model compact. Add a field only when it supports a real decision, relationship, or accountability requirement.

Field groupWhat it must establish

Stable record IDAn internal identifier that survives a rename, IP change, reassignment, or reimage.

Matching signalsSerial number, hardware UUID, management-agent ID, directory device ID, or another controlled combination used to detect duplicates.

Observed platformOperating system, version, hardware model, and other facts reported by a named source.

Source and observed timeThe collector or system that supplied the value and when it last observed or validated it.

Assigned owner and service contextThe accountable person, team, customer, location, or business service associated with the endpoint.

Lifecycle stateA controlled state such as staged, active, temporarily offline, repair, pending retirement, retired, or disposed.

Management stateWhether the endpoint is enrolled, checking in, covered by expected policy, and still within the authorized management boundary.

Exception statusAny identity conflict, stale value, missing owner, unsupported platform, or unresolved source disagreement.

Reusable template

Download the endpoint inventory CSV template

The template includes the minimum record, provenance, lifecycle, and exception fields above plus one clearly marked example row. Delete the example before importing real data, and never place credentials, recovery keys, or secrets in an inventory export.

Download the free CSV template

Separate observed facts from assigned context

Hardware, operating-system version, installed software, last check-in, disk capacity, and agent version are observed facts. Owner, department, business service, support group, criticality, and replacement target are assigned context. Treating them as the same kind of data hides different reliability and review needs.

Microsoft documents this distinction in practice: Intune device details expose collected, read-only inventory, while properties such as ownership, primary user, notes, and scope tags are edited separately. Its current Windows app inventory also requires a collection policy and reports richer application properties multiple times per day. The collection method and cadence matter whenever a CMDB consumes the result.

Write a source contract before building the integration

For each field group, name the authoritative source, expected cadence, matching rule, conflict behavior, and person accountable for exceptions. A sync schedule alone is not a source contract.

SourceTypical authorityExample cadence

Endpoint agent or RMMObserved hardware, operating system, installed software, health, agent identity, and last check-inNear real time to daily, depending on the field

Directory or identity systemPrimary user, directory device ID, join state, and organizational assignmentDaily or after identity changes

Procurement or ITAM systemPurchase, warranty, lease, vendor, cost center, and disposal evidenceOn transaction or scheduled review

Service desk or CMDBService relationships, support group, criticality, incidents, changes, and approved lifecycle decisionsOn workflow events

Use lifecycle states that describe reality

One active-or-inactive flag rarely supports endpoint operations. A small lifecycle can distinguish ordered, staged, active, temporarily offline, repair, pending retirement, retired, and disposed. Each state needs an entry condition, accountable role, required evidence, and defined next step.

Last check-in should inform the decision without making it automatically. A device may be offline because an employee is on leave, a field site has limited connectivity, or an agent is broken. Retirement should combine technical evidence with ownership and service context.

Five readiness gates before CMDB synchronization

Identity is durable

Rename and reassign a test endpoint. Its history should remain on one record rather than splitting or merging silently.

Every important value has provenance

Select an owner, operating-system version, and installed application. A technician should be able to say where each value came from and when it was observed.

Freshness matches operational need

Define separate expectations for health, software, ownership, warranty, and lifecycle data instead of one universal stale-record threshold.

Exceptions are visible

Create a duplicate candidate or conflicting owner. The system should queue the uncertainty for review rather than guessing a winner.

Lifecycle states trigger action

Move a test endpoint toward retirement. The record should identify the accountable role, required evidence, and next state.

Prove the inventory with a small operating test

Before connecting a full fleet, select five representative endpoints: one newly deployed device, one reimaged device, one shared or kiosk device, one remote-worker device, and one device approaching retirement. Ask service-desk and endpoint staff to complete real tasks from the inventory.

Identify the owner and support group for an alerting endpoint.
Find every managed endpoint affected by a selected software version.
Explain why a device has not checked in and who decides its next lifecycle state.
Trace a changed owner or hostname without losing device history.
Produce the evidence needed to retire a device without leaving an active management record.

Record where the team hesitates, searches another system, or cannot explain a value. Those gaps are more useful than a large completeness percentage because they show whether the inventory supports work under normal time pressure.

Nizlo scope

Operational inventory is not a complete CMDB or ITAM system

Nizlo provides endpoint, hardware, operating-system, installed-software, health, patch, customer, site, and technician context for authorized monitoring and management work. It does not claim a universal CMDB, procurement ledger, software-license entitlement system, depreciation register, contract repository, or certified-disposal workflow. Keep those records in the system designed to govern them.

RMM vs IT asset management

Separate live endpoint operations from procurement, ownership, financial, and lifecycle records.

Read the guide

RMM vs ITSM

Define the handoff between device evidence and incidents, requests, change, problem, knowledge, and CMDB workflows.

Read the guide

Endpoint exception management

Turn stale, conflicting, or failed endpoint states into owned service-desk work with closure evidence.

Read the guide

Primary references

Test the inventory with one authorized endpoint

Start a 14-day Nizlo trial without a credit card.

Use one authorized lab or noncritical endpoint to verify identity, inventory, freshness, customer and site context, technician history, exception handling, and clean removal before expanding. Applying or starting a trial does not reserve a Founding Tester discount position.

Start the 14-day trial