Your device management console knows about machines that are switched on and checking in. Your asset register knows what you bought. Those are two different populations, and the devices that go missing are almost always in the gap between them.
TL;DR
- Device management sees what is online. An asset register records what you own. Neither is a substitute for the other.
- Four populations exist, and two of them are invisible to the console by design.
- A device in a drawer, one bought and never deployed, and one with somebody who has left are exactly where registers go wrong.
- The register should be the system of record and the console should be a reconciliation source, not the reverse.
- A management check-in proves a device with that identifier was online. It does not prove who holds it or where it is.
- Reconcile against three sources quarterly and count the discrepancies each one produces separately.
What each one actually knows
A management console knows a great deal about the devices it can reach, and almost nothing about the ones it cannot. It knows the operating system version, the encryption state, when the machine last checked in and which account signed into it. That is genuinely more than most registers hold.
A register knows what you purchased, what it cost, who it was issued to and when. More to the point, it knows about devices that no longer talk to anything, which is the entire category that causes problems.
So the two are complementary rather than competing, and the mistake is not choosing between them. It is assuming the console’s list is the fleet.
The four populations
| In both | Deployed, in use, recorded | Nothing to do. Usually the large majority |
| Console only | Bought and never recorded | Your procurement handoff is leaking. The most common gap |
| Register only | In a drawer, with a leaver, or never deployed | Where devices disappear, and invisible to the console |
| Neither | Exists, unrecorded, not enrolled | Found only through purchase records. Never an empty set |
The third and fourth rows are the point of this article. A company that treats the console as its inventory is reporting on the first two rows and describing it as the fleet, which means the devices carrying the most risk are the ones it cannot see.
What the console cannot see
Four cases, each ordinary rather than exotic.
A device in a cupboard. Switched off since it came back, so it has not checked in for months. It still holds company data if nobody wiped it on arrival, and it is a usable machine somebody could issue rather than buying a new one.
A device bought and never deployed. Ordered for a starter who did not join, sitting in a box. No enrolment, no check-in, no record anywhere except an invoice.
A device with somebody who has left. The case that matters most. If they stopped using it, it stopped checking in, and the console’s view is identical to a device that was returned and shelved.
A device whose enrolment was removed. Released for resale and then not sold, or unenrolled during troubleshooting and never put back. The console has forgotten it entirely.
Which one should be the system of record
The register, with the console feeding it. Not because the register is better data, since it usually is not, but because it is the only one of the two that can hold a row for something that is not currently talking to you.
That gives the console a specific and useful job: it becomes the reconciliation source that maintains itself. A management check-in is the only verification method that costs nothing and happens continuously, which makes it the best available input to a last-verified date, as long as you record what it proves rather than what you would like it to prove.
What it proves is that a device with that identifier was online on that date. Not who has it, not where it physically is, and not that the serial on the row is the serial in that person’s hands. Those still need a human, which is why the method matters as much as the date.
A worked example
A company with 240 staff reported its fleet from the management console: 219 devices, all patched, all encrypted. The security questionnaire answer was strong and the number was accurate.
Then somebody reconciled against purchase records. The company had bought 266 machines in the relevant period and disposed of 14, which left 252 unaccounted against 219. Thirty-three devices existed somewhere and had not checked in recently enough to appear.
Nineteen were in a storeroom, unwiped. Eight were with former employees. Six were never found and were written off. The console had been right about every device it knew about, which is a different claim from the one the company had been making.
Running the reconciliation
What to do:
- Export the console list, the register and your purchase records for the same period, and match on serial.
- Count the four populations separately, because each one points at a different broken process.
- Cross-reference the register against your leaver list to produce the devices that should have come back.
- Write the last-verified date into the register from the console check-in, with the method recorded as automatic.
- Wipe anything found in storage on the day you find it, and record the date, method and person.
- Repeat quarterly and keep the four counts, because the trend tells you whether the fix worked.
Count the discrepancies by source rather than fixing rows. Correcting thirty rows feels productive and changes nothing, since the remaining rows carry the same error rate. Which source produced the most discrepancies is the finding, and it tells you whether to fix procurement handoff, offboarding or storage intake.
Lansweeper is the best-known discovery tool for finding devices on a network that nothing else knows about, and it has a free tier while publishing no pricing figures for its paid ones. Freshservice is the usual answer where you want asset data sitting next to the service desk, and it does publish: tiers at $19, $49 and $99 per agent per month. Both approaches are compared in our IT asset management comparison.
Final thoughts
Treating the management console as the inventory is the most common inventory mistake there is, and it is attractive because the console’s data is cleaner. It is cleaner because it only describes devices that are cooperating.
Keep the register as the system of record, use the console as a free continuous verification source, record what a check-in actually proves, and reconcile against purchase records and your leaver list every quarter. The devices you are worried about are the ones not in the console, which is precisely why the console cannot be the answer.
Frequently asked questions
Can an MDM replace asset management software?
No, because the two describe different populations. A management console knows a great deal about devices that are switched on and checking in, including operating system version and encryption state, and nothing at all about devices that are not. An asset register is the only one of the two that can hold a row for something that has stopped talking to you, which is the entire category where devices go missing. Use the register as the system of record and the console as a reconciliation source.
What devices does device management miss?
Four ordinary cases. A machine in a cupboard that has been switched off since it came back, which still holds company data if nobody wiped it. One bought for a starter who never joined, sitting in a box with no enrolment. One with a former employee who simply stopped using it, which looks identical in the console to a returned machine. And one whose enrolment was removed during troubleshooting or for resale and never restored, which the console has forgotten entirely.
What does a management check-in actually prove?
That a device with that identifier was online on that date, and nothing more. It does not prove who holds the machine, where it physically is, or that the serial recorded against a person is the serial in their hands. That is still worth a lot, because it is the only verification method that costs nothing and happens continuously, which makes it the best available input to a last-verified date. Record the method alongside the date so nobody reads more into it than it supports.
How do you find devices you do not know about?
Purchase records, which are the only source that sees a device nothing else knows exists. Export everything bought in the relevant period, subtract documented disposals, and compare the result against your console list and your register. The difference is real and it is never zero. Network discovery tools help with machines that are online but unmanaged, which is a different gap, and they cannot see anything in a box or a drawer.
Which sources should an asset register be reconciled against?
Three, quarterly. The management console, where anything checking in but unregistered is a device you own and never recorded. Purchase records, where anything bought and never registered shows the procurement handoff failing, which is usually the largest category. And the leaver list cross-referenced against assignments, which produces the devices that should have come back. Count the discrepancies each source produced separately, because that identifies which process to fix rather than just correcting rows.
Why is reporting fleet size from the console misleading?
Because it answers a narrower question than the one being asked. The console can truthfully say every device it manages is patched and encrypted while being silent about machines in storage, with former staff, or never deployed. Those are the devices carrying the most risk, so a report built on the console is strongest exactly where it is least relevant. State the population your figure describes, and reconcile against purchase records before giving a fleet number to anybody external.
