What this is. Opinion + Experience + Fact (35% opinion · 35% experience · 30% fact). Written in collaboration with AI — I discuss, I do not outsource.

You can name your best-selling product. Naming every unit of it in the field — which firmware each runs, which config, where it sits — is a different question, and for most teams the honest answer is "roughly." This is the case for treating device inventory and identity as fleet infrastructure, not paperwork: why you can't manage what you can't enumerate, why identity has to be born at the factory, and why the only inventory worth trusting is one that keeps itself current.

Ask a hardware team how many units they've shipped and you'll get a confident number. Ask which firmware each of those units is running right now, which config, and which ones are still in service, and the confidence drains out of the room. That gap — between the product you can name and the population you can't — is where fleet security, recalls, and updates quietly fail. Let me walk through why enumeration comes first, why identity has to start at manufacture, and why a static inventory is fiction the moment it's written.

1. You can't manage a fleet you can't enumerate

Every job you'll ever do to a fleet begins the same way: name the exact units affected. Patch this vulnerability — on which devices? Recall this batch — which serial numbers? Retire this hardware revision — where are they? Audit for compliance — prove it. Each of these is impossible without an enumerable list of what's actually out there.

"About ten thousand units, mostly on v3" feels like an answer, but it isn't an inventory — it's a hope with a number attached. The gap stays invisible right up until the worst possible moment: an actively exploited vulnerability lands, the clock starts, and the question "which of our devices are exposed?" has no precise answer. What you cannot enumerate, you cannot secure, update, or retire.

▸ First principle. A fleet you can't list is a fleet you can't manage — enumeration comes before every other fleet job.

2. Identity is born at the factory, not bolted on

Enumeration needs something to enumerate by. A device needs a unique, verifiable identity before it ever leaves the line — not a network address it happens to pick up later, and not a serial number printed on a label that software can't check. The strong version is an identity minted at manufacture: a private key generated inside secure hardware, a certificate that binds that key to the device, and a way for the device to prove it really is the thing it claims to be.

Do that, and the fleet can recognize each unit for its entire life — through reboots, network changes, and ownership transfers. Skip it, and you bolt identity on afterward: shared credentials, duplicates, spoofable units, and a population you fundamentally can't tell apart. Identity created after the fact is identity you can't fully trust, which means an inventory built on it is one you can't fully trust either.

The fleet you can name versus the fleet you actually have A grid of devices. Some are identified — showing an ID and firmware version in cyan. Most are grey with a question mark: shipped, but unaccounted for. The caption reads: you can only manage the ones you can name. The fleet you can name vs. the fleet you shipped Each tile is a device in the field. Cyan = known identity + version. Grey = shipped, unaccounted for. #A1F3fw v3.2seen 2h ago #C7B2fw v3.1seen 1d ago ?????????? You can only manage the ones you can name. Patch, recall, audit, retire — every one of them starts by naming the exact units affected. The grey tiles aren't gone. They're in the field, running something — you just can't say what.

▸ First principle. A device without a factory-born identity is invisible to your fleet forever.

3. Inventory is a living record, not a spreadsheet

Even a perfect list is wrong within a month, because what you shipped starts drifting the instant it ships. Devices take over-the-air updates and change version. Units come back as RMAs and get re-deployed. Boards get swapped in the field. Some go dark; some come back. A static asset spreadsheet captures a single moment and then rots quietly while everyone keeps trusting it.

The only inventory worth having is one that maintains itself: the truth of "what's out there" comes from the devices reporting in — their identity, their current firmware, their last-seen time — not from a document someone remembers to edit. When the record is fed by the fleet, "what did we ship, and what's it running now?" stops being an archaeology project and becomes a query.

▸ First principle. An inventory that doesn't update itself from the fleet is a guess with a timestamp.

4. Make it part of the platform

Inventory and identity aren't a spreadsheet chore bolted on at the end; they're fleet infrastructure, and they're cheapest to get right at the device layer, from the start. That layer is what I've been building in the open: EmbedIQ, an Apache-2.0 framework for embedded and edge — so knowing and trusting what you shipped becomes a foundation you build on rather than reconstruct after the fact.

▸ First principle. Get identity and inventory right at the device layer, and "what did we ship?" becomes a question with an answer.

Sources

Device identity born in manufacturing — a private key in a secure element, an X.509 certificate, and proof-of-possession — is established practice for connected fleets (see general guidance from Microsoft Azure IoT, AWS IoT, and secure-element vendors such as Microchip on provisioning device identity). Asset inventory and knowing your deployed population is also a prerequisite for incident and vulnerability reporting under the EU Cyber Resilience Act, whose reporting obligations begin 11 September 2026. This piece describes method and experience; it carries no measured statistics.

FAQ

Why isn't a shipment count a device inventory?
A shipment count tells you roughly how many units left the building; it doesn't tell you which specific units are in service, what firmware each runs, or where they are. Fleet jobs — patching, recalls, audits, retirement — all require naming the exact units affected, which a count can't do.

Why does device identity need to start at the factory?
Because identity created after deployment can be duplicated, shared, or spoofed, leaving you with units you can't reliably tell apart. An identity minted at manufacture — a key inside secure hardware, bound to a certificate, with a way to prove the device is genuine — lets the fleet recognize each unit for its whole life.

What makes a device inventory go stale?
Over-the-air updates change firmware versions, RMAs get re-deployed, boards are swapped in the field, and units go offline and return. A static spreadsheet captures one moment and drifts out of date; only an inventory fed by the devices themselves stays accurate.

How does inventory relate to security and compliance?
You cannot report or remediate what you cannot enumerate. When a vulnerability is disclosed — or when a regulation like the EU Cyber Resilience Act starts a reporting clock — you need to name precisely which fielded units are affected and what they're running. A current inventory turns that from an impossible question into a query.

This is an embedded / IoT field note. The short version lives on my LinkedIn; the longer story, and the open-source layer that makes device identity and inventory a default, live on my profile. — Ritesh | ritzylab.com