How-to guide

How to build a device inventory that stays current

Learn how to build a device inventory that stays current with automated feeds, clear ownership, reconciliation checks and a simple change process.

By the Cloudverg engineering team · · 5 min read

Why this matters

A device inventory that stays current is an operating habit, not a spreadsheet. This guide, How to build a device inventory that stays current, treats the inventory as a record you trust for patching, access reviews, warranty claims and budget planning. If the owner, last seen time or lifecycle state is stale, every decision built on that record starts from bad facts.

Most companies already have fragments. MDM holds laptops and phones, an RMM tool holds servers, switch tables show network gear, and finance holds purchase records. Each source is partial. The hard part is not collecting another export. It is deciding which system wins when sources disagree and who fixes the gap.

A current inventory also covers the boring stock: loaners, spares, devices in repair and gear waiting for disposal. Those items disappear from endpoint tools but still carry licenses, warranty obligations and security risk. Track them or they become unknown devices on your network.

Before you start

Define scope and purpose first. List the device classes you will track: laptops, desktops, phones, tablets, servers, switches, routers, firewalls, printers and spare stock. Decide whether virtual machines and cloud instances belong in the same inventory. Name one owner for the inventory and one backup owner.

Choose a unique key. Serial number is best for physical hardware. Use asset tag when serial is missing, and record both. A MAC address is a fallback, but it changes with docks and adapters, so never make it the only key. Set lifecycle states such as in stock, in use, repair, loaner, retired and disposed.

Agree on required fields and source precedence. Keep the list short: unique key, device class, make, model, serial, asset tag, hostname, assigned user, location, operating system, lifecycle state, purchase date, warranty end, last seen and support status. Set rules. MDM wins for enrollment and last seen, procurement wins for purchase and warranty, the identity provider wins for assigned user, and the network tool wins for presence. Flag conflicts instead of silently overwriting them.

How to do it

Start with a baseline, not a perfect dataset. Export what you have, merge on the unique key, and mark duplicates and blanks. You are looking for a map of the gaps, not a clean file on day one.

Then connect the feeds that change most often. Daily imports from MDM and RMM, weekly network discovery, and monthly finance or procurement extracts cover most drift. Every import should write the source name and import time to each record it touches.

Finally, attach the inventory to process. Procurement, onboarding, repair, loaner checkout, offboarding and disposal must create or update a record in the same ticket. A record that changes only during an annual cleanup will be wrong within a month.

  1. Name a system of record. Pick the tool that holds the master record, such as an asset management system or a structured database. Do not let three teams keep three spreadsheets.
  2. Define the minimum fields. Include serial number, asset tag, device class, assigned user, location, lifecycle state, last seen and warranty end. Add fields only when a named process uses them.
  3. Load a baseline from existing exports. Pull MDM, RMM, identity, network and purchase data into one table. Match on serial number first, then asset tag, and mark unmatched rows for review.
  4. Schedule automated imports. Use APIs or scheduled CSV imports from MDM, RMM, DHCP and procurement. Record the source and timestamp on every update so you can trace bad data.
  5. Set conflict rules and review exceptions. Decide which source wins for each field and flag disagreements. A human should resolve ownership, location and lifecycle conflicts, not a silent overwrite.
  6. Hook updates to tickets. Require a device record or asset tag on onboarding, repair, loaner and offboarding tickets. Close the ticket only when the inventory state matches the physical state.
  7. Discover unknown devices on the network. Use DHCP leases, DNS registrations, SNMP polling and network access control logs to find devices not in the inventory. Investigate each unknown before adding it.
  8. Publish an exception report each week. List records with no owner, no last seen time, duplicate serials, expired warranty, unsupported OS or missing lifecycle state. Assign each line to a person.
  9. Audit a sample every month. Pick devices from different locations and roles, find them physically, and compare the record. Fix the process that caused each mismatch, not only the record.

How to check it worked

Test the inventory with events, not with a report. Add a new hire and confirm the laptop appears with the right owner before the start date. Move a device to repair and check that the lifecycle state changes. Retire a device and confirm it leaves active counts but remains in history.

Trace ten records from purchase to current state. Each should have a source and timestamp for last seen, a named owner and a clear lifecycle path. If a record cannot be traced, the feed or the process is missing.

Check the gaps. Count records with blank required fields, duplicate serials, unknown owners or no last seen time. Review the weekly exception list and confirm items are closing. A current inventory has fewer unknowns each month and a short list of known exceptions with owners.

Mistakes to avoid

Treating the inventory as a one-time cleanup is the first mistake. A perfect export is stale as soon as someone buys a laptop or leaves. Build the update into procurement, onboarding and offboarding instead of scheduling another cleanup.

Tracking too many fields is the second mistake. Long forms get skipped. Keep the required set small and add fields only when a team uses them in a decision, such as warranty renewal, patching or access review. Also avoid letting MDM be the only source. It will not see switches, spare stock or devices that fell out of enrollment.

Skipping disposal and loaners is the third mistake. Retired devices must keep a disposal date and method, and loaners need a checkout owner. Otherwise they reappear as unknowns. If you need help, options include an internal project, a managed service provider, or the Cloudverg Hardware and endpoint review at a fixed price of $4,500.

Frequently asked questions

How often should a device inventory be updated?

Update on every change, such as purchase, assignment, repair, loaner checkout, return or disposal. Run automated imports at least weekly and review exceptions on the same cadence. Do a full sample audit monthly and a deeper reconciliation quarterly.

What fields should a device inventory include?

Start with a unique key, device class, make, model, serial number, asset tag, hostname, assigned user, location, operating system, lifecycle state, purchase date, warranty end, last seen and support status. Add fields only when a process uses them. Keep the required set short so people fill it in.

Can MDM replace a device inventory?

No. MDM is a strong feed for enrolled laptops, phones and tablets, but it misses servers, switches, spare stock, loaners and devices that lose enrollment. Use MDM for endpoint state and combine it with procurement, network and finance sources. The inventory needs a system of record outside any single tool.

Fixed price

Want help with this? Hardware and endpoint review

$4,500 fixed price

2 weeks · Starts within 10 business days

Two weeks to inventory your laptops, servers, network gear and licenses, then agree what to keep, what to replace and what it should cost.

What is included

Related guides

More hardware and it guides   Hardware and devices

Smallest way to start

Get a senior architect on your problem this week

Ninety minutes on the cloud, AI or security question that is blocking you, a pre-read of your material and a written summary within two business days.

$450 one-time