Most SAM programmes are built on Active Directory and an agent deployment, which means they are built on a list that is already wrong. Discovery is not a preliminary step to software asset management — it is the foundation the rest of it stands on.
Knowing accurately what hardware and software you have installed is the precondition for managing any of it. That is why good IT asset discovery is essential for software asset management.
It sounds like a statement of the obvious. It is worth saying anyway, because a surprising number of organisations are running on an inventory that is both inaccurate and incomplete — and they do not know which parts.
When a SAM programme is then built on top of that inventory, and the inventory is treated as the single source of truth, the outcome is not in doubt. Every downstream number inherits the error.
The standard pattern is to take Microsoft Active Directory as the starting list and deploy an inventory agent to the devices it names.
For a smaller organisation that keeps AD tidy, this can work well enough. For a larger one it rarely does. AD drifts. New devices do not always get added promptly. Dead and decommissioned ones almost never get removed. Both directions cause problems: the machines you miss are unlicensed exposure, and the machines that no longer exist inflate every count you report.
The bigger issue is what AD was never going to tell you. It does not find Linux and Unix systems, anything in the DMZ, Macs, or anything sitting in a workgroup or a different domain. So the picture is not only imprecise — it is structurally incomplete, and incomplete in exactly the places where licensing gets expensive.
The obvious response is to verify the asset data independently rather than inherit it. Most organisations do not, and the reason is practical: without the right tooling it is slow, manual work, and very few teams have the people spare.
That is the problem CerteroX ITAM’s discovery layer is built to remove. And by assets we do not only mean PCs and servers. Network Discovery finds what is attached to the network — including printers and switches — and SNMP interrogation returns genuinely useful detail rather than a bare presence record: printer consumable levels and page counts, switch port and routing tables. Machines that are rarely or never connected are covered too, through standalone inventory built for air-gapped and offline systems.
There is no single discovery technique that finds everything, which is why the platform ships ten and lands all of them in the same data model:
csinvcli)Network Discovery sweeps a class-C subnet in under five seconds, then probes port 22 to work out where an agent can actually be deployed. That ordering matters: you find the machines before you own them, rather than deploying to a list and hoping the list was right.
Twenty-eight named system connectors bring in what other systems already know — SCCM, Intune, the hypervisors, the cloud accounts — so the fleet that only exists inside somebody else’s console stops being a blind spot.
Critically, all of it is stored in one database. A single place to interrogate every asset record is what makes lifecycle management, reporting and business decisions fast instead of a data-gathering exercise each time.
Once you have a comprehensive inventory of everything with a presence on the network, you can cross-check it automatically against what AD claimed.
That comparison produces two useful outputs. Duplicates are removed, so one physical machine stops appearing as three records. And devices that exist in AD but were not found by any other method are flagged — which is usually the fastest way to identify kit that was decommissioned without anyone updating the directory.
Only after that normalisation do you reach the point where most SAM tools begin: deploy the agent and collect detailed hardware and software detail. The difference is that you are now deploying against everything you actually have, rather than a best guess. Software recognition then resolves what comes back against the Software Recognition Database and its 3.5 million-plus normalised titles, so “Adobe Acrobat” and “Acrobat Pro DC 2023” stop being two different products in your licence position.
This article was written in 2017, when discovery meant finding devices and the software installed on them. That is still necessary. It is no longer sufficient.
A large and growing share of the software your organisation uses is never installed anywhere. It is SaaS, reached through a browser, frequently bought outside IT, and structurally invisible to a device inventory however thorough that inventory is. CerteroX SaaS Management addresses that with three converging discovery signals — identity provider sync from Entra ID and Okta, connector sync pulling authoritative user and licence lists from the vendor across 47 connectors shipping today, and a browser extension that detects SaaS domains with per-user attribution and time-on-app. OAuth grant discovery finds the third-party applications people have consented into your tenancy, which is a discovery problem nobody had in 2017 and everybody has now.
The same logic applies to infrastructure. Cloud resources appear and disappear faster than any inventory cycle designed around physical hardware, so CerteroX Cloud Management maintains its own resource inventory across twelve cloud and data platforms.
The principle has not changed at all. What has changed is the surface area. If you want to know what you are running, you have to look everywhere it can run.
Everything a SAM programme produces — the compliance position, the optimisation case, the audit response — is a calculation performed on the inventory. If the inventory is wrong, the calculation is wrong, and it will be wrong confidently and in detail.
Verify the input yourself. Everything after that gets easier.
To see independent discovery running next to the tools it is meant to check, book a demo.
Other posts covering the same ground.
More than forty seasoned software asset management professionals were asked for one piece of advice for someone starting out in a SAM role. Their answers fell into four categories, and none of them was "buy a tool".
SCCM is good at what it was built for and was never built for software asset management. You do not have to throw it away to close the gap — but you do have to know precisely where the gap is.
SCCM can tell you a file exists on a disk. It cannot tell you whether the application was installed, whether it belongs to a suite, or which edition you are running — and every one of those decides what you owe.
Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.
No gated download at the end of it.