Offboarding in one page
Everything a custodian has not returned, including kit in repair and anything recorded lost, plus the control to end every session they hold. A team identifier works as a custodian, for machines no one person owns.
Hardware bill of materials
Every device, who holds it, what condition it is in, and what the whole estate looked like on any past date. Built for the questions offboarding, incident response and an ISO 27001 assessor actually ask.
An asset is registered into stock and then moves: assigned to a custodian, moved between sites, sent for repair, recorded lost or stolen, wiped, retired, disposed. Each of those is an event appended to a log, and the state you see is a projection of that log, not a field somebody overwrote.
That distinction is what makes the register evidence. A spreadsheet tells you what somebody last typed. An event log tells you what happened, in order, with who recorded it and when — and it lets the register be rebuilt for any date you are asked about.
Everything a custodian has not returned, including kit in repair and anything recorded lost, plus the control to end every session they hold. A team identifier works as a custodian, for machines no one person owns.
Pick a date and the register is reconstructed from the event log: what was held, by whom, at which site. Retired and disposed kit is included, because it was part of the estate then.
Confirmed, confirmed absent, or never recorded — three states, counted separately, with the endpoint population reported on its own because that is the one Cyber Essentials and A.8.1 ask about.
A certificate reference, a method, the financial position posted to a ledger, and a human approval. Nothing leaves the books on a machine's say-so.
What this page calls a hardware bill of materials is, in the words most people search for, an IT asset inventory: every device the organisation owns, who holds it, what state it is in and what happened to it. The reason for the other name is the join — the same register holds the software you ship, so an asset is not a row in a separate system from the components running on it.
A configuration management database is a close relative and a different shape. A CMDB models configuration items and the relationships between them, usually to support change and incident processes, and it is typically populated by discovery agents reconciling what they find. This is a register of record instead. Nothing is discovered; everything is asserted by a person or an API, every change is an event with a timestamp and an actor, and the whole history is hash-chained so the record can be checked rather than trusted. If you need a dependency graph of services for change management, that is a CMDB and this is not it. If you need to state what you owned on a date and prove the statement, that is this.
The register reconstructs the estate as it stood on any past date, which is the question an asset inventory is usually bought to answer and the one a live-only view cannot.
A deployment can name the machine a release runs on. That is the join most estates do not have, and it is what turns "this dependency has a critical vulnerability" into a list of physical boxes with custodians attached. The asset page shows what is running on it; the deployment map shows which machine each release is on.
It is the same register, so there is no reconciliation step and no export to join two systems that disagree about how many servers you have.
Facts about a machine get typed wrongly, and encryption goes from unrecorded to verified. Those are corrected through an amendment that requires a reason and keeps the previous value in the audit trail. Events are never edited, because an event is history. The line between "this was recorded wrongly" and "this then happened" is exactly the line an auditor is checking.
A list of the physical estate an organisation holds, precise enough to account for each item: what it is, its serial, who holds it, where it is, what state it is in, and what has happened to it. In compliance terms it is the asset register that ISO 27001 Annex A.5.9 asks for, kept as a lifecycle, not as a spreadsheet snapshot.
Most of the register will feel familiar. The differences are that it is bitemporal, so you can reconstruct the estate as it stood on any past date from the event log; that disposal is a controlled process requiring a certificate and a human approval; and that assets can be named by deployments, so a vulnerable release resolves to physical machines.
Yes, and it deliberately includes kit that is out for repair or recorded lost or stolen while in their care. Excluding those would report a leaver as clear while a laptop of theirs sits on a bench, which is the exact failure the view exists to prevent. Ending their sessions is on the same page.
Encryption is three states, not two: confirmed, confirmed absent, and never recorded. "Never recorded" means nobody has checked, and it is reported as a gap in the register, not as an unencrypted device. Conflating the two either understates your exposure or defames your estate, and an assessor will ask which one you meant.
Disposal is terminal and controlled. It requires a disposal certificate reference, a method, the financial position, and a human approval — it is one of a handful of actions no API key can ever perform. The asset leaves the working set but is never deleted, because "what did we hold in March" remains answerable.
Not in bulk today. Assets are created one request at a time through the API, which is genuine friction for a fleet onboarding, and CSV import is on the roadmap. Tell us the size of the estate when you get in touch and we will be straight about what onboarding looks like.
Free for personal use. For a fleet, tell us its size and we will be honest about onboarding.