Discovery and inventory are not the same thing, and most tools that claim the first are only good at the second. Six criteria for choosing between them, and why "good enough" coverage stops being good enough the moment anyone outside SAM uses your data.
Although the terms are used interchangeably, discovery and inventory are distinct stages of any working ITAM or SAM programme.
Discovery is, as the name suggests, the process of finding all the devices connected to the network — making sure there are no blind spots. Only once a device has been discovered can you inventory it: collect its configuration (class, make, model, memory, disk, processor), who is using it, where it is, and what software is installed on it.
Plenty of tools position themselves as discovery when in truth they are only competent at inventorying devices their agent has already reached. They will do very little to help you find the ones you did not know about.
That makes tool selection matter more than it looks. Get it wrong and your SAM, ITAM, ITSM and governance programmes all suffer downstream from the same missing rows.
If you are completely certain you know every device connected to your network, and how to deploy an agent or point agentless scanning at each of them, you do not need a discovery tool.
More likely, you accept you do not have complete coverage — and you will need to decide how much the non-computer devices matter, the switches, routers and printers. If so, you need discovery capability, and the rest of this is for you.
A good discovery tool minimises your blind spots. It finds every device connected to the network, whether or not you already knew it existed. It finds Windows PCs, laptops and servers. It also finds the other platforms — the Linux and Unix servers in the data centre. It finds network-attached devices, and it helps you find the mobiles and tablets connected to the corporate network.
Why is a complete picture so hard to obtain? Legacy tools such as SCCM were designed for a Microsoft-centric world. They are adequate for inventorying known Windows devices and extremely limited at proactively finding new or non-Windows ones. Other traditional sources of asset data, Active Directory chief among them, are notoriously difficult to keep clean, which makes them unreliable at best.
Even if SCCM and AD together gave you 80% coverage — which is generous — then without a dedicated discovery capability actively seeking out every type of device, blind spots are effectively guaranteed. Blind spots are risk. Quantifying that risk is hard, because these are unknown unknowns. But the arithmetic is simple enough: 5,000 devices at 80% coverage is 1,000 devices unaccounted for. Very few organisations would call that acceptable.
Having made the case for investing in discovery rather than relying on legacy sources or inventory tools that only cover previously known devices, what separates a good one?
Auto-discovery technologies. Examine how each shortlisted tool actually performs discovery, and scrutinise the methods it uses to go out and find devices. Single-method discovery rarely produces complete coverage, because each method has a category of device it cannot see.
Discovery frequency. Some discovery tools generate enough network traffic and overhead that organisations become reluctant to run them often — at which point the coverage claim is theoretical. Ask what a sweep costs you, and how often you would genuinely be willing to run it.
Platform scope. Where do you need to find assets? Only the desktop? What about virtual environments, the data centre, the cloud? What about mobile?
Location scope. How many locations are you managing? Many tools are fine on a single-domain network and struggle badly across multinational operations.
If you are evaluating a combined discovery and inventory tool, add two more:
Agent and agentless. Your tool should support both, because some assets will only ever be reachable by one of them.
Usage monitoring. Essential the moment you want to move past finding things and start optimising licences and asset utilisation. Without usage evidence you can identify what is installed but not what is redundant.
For reference, the shipping capability in CerteroX ITAM against those criteria: network discovery sweeps a class-C subnet in under five seconds using NetBIOS, SNMP and ICMP, then probes port 22 to establish where an agent can actually be deployed. Ten discovery and inventory methods — agent, command-line, agentless, standalone for air-gapped systems, Active Directory import, network scan, third-party ITAM import, cloud and SaaS connectors, browser monitoring and file metering — all land in one schema, so there is no reconciliation exercise between sources. The native agent covers six operating system families: Windows, macOS, Linux, IBM AIX, HP-UX and Oracle Solaris. SNMP collection returns printer consumables and page counts, switch port tables and routing tables. Non-persistent VDI is supported, and duplicate systems and stale devices are detected rather than left to inflate your counts.
Some SAM consultants will tell you 90–95% coverage is good enough to do SAM work such as producing an effective licence position. It is not best practice, but there is a logic to it: for a publisher like Microsoft, from 95% coverage you can reasonably extrapolate the remaining 5%.
That methodology does not transfer. It does not hold for other major publishers, particularly in the data centre where a single unlicensed host can carry a very large finding. And it does not hold at all for uses outside SAM.
Imagine asking your service desk to work with 90% accurate data, and a request arrives for a device in the missing 10% — one they did not know existed and hold no information about. Or explaining to finance that a tenth of the spend is unaccounted for. Or planning a Windows 11 or Microsoft 365 migration without knowing that a tenth of your machines will still be running legacy, possibly unlicensed, software long after you believe the project has finished.
Viewed through the narrow lens of software licensing, you can argue that good enough is good enough. Viewed as the foundation for IT asset management, change programmes and technology governance, it is not.
Cloud is a growing share of IT spend and it presents genuinely different discovery problems, which need separate approaches for SaaS on one side and IaaS or PaaS on the other.
On SaaS specifically, the 2019 version of this article argued that browser-based and finance-system approaches were not really discovery at all — that they depend on an existing fingerprint, and therefore cannot find unknowns — and concluded that the better approach was to concentrate on the handful of strategic vendors you spend most with and manage those through API integration. The criticism of any single-signal approach still holds. The conclusion does not, and it no longer describes what we build.
The problem with each individual signal is real. Finance and expense data tells you something was bought, not whether anyone uses it. A vendor API gives you an authoritative user and licence list, but only for a vendor you already know about and already have credentials for. A browser extension sees real usage including applications nobody declared, but only where the extension is deployed. Each of the three has a category of application it structurally cannot see.
The answer is to converge them rather than pick one. CerteroX SaaS Management runs all three: identity provider sync from Entra ID and Okta including MFA enrolment, authoritative user and licence lists pulled through 47 vendor connectors, and a browser extension detecting SaaS domains with time-on-app and per-user attribution. What one signal misses, the other two generally catch.
The false-positive objection is answered by the catalogue. Findings resolve against more than 35,000 applications, so the output is a named application with an owner, a category and feature tags — not a raw domain for somebody to research. That is the same problem the Software Recognition Database solves for installed software, where more than 3.5 million titles turn inconsistent publisher and version strings into a normalised record.
Discovery of the genuinely unknown is also no longer aspirational. OAuth grants consented to third-party applications are discovered and risk-scored from 0 to 100 on data sensitivity, scope breadth, consent age and dormancy. AI tools are classified from catalogue feature tags rather than a hardcoded list, so the Shadow AI detection set grows without anyone maintaining it, and adoption risk is ranked by the share of the organisation using each tool — because ten people on an assistant is a different problem to a thousand.
On the IaaS and PaaS side, discovery is account-level rather than network-level. CerteroX Cloud Management inventories resources across twelve cloud and data platforms and ingests cost data natively in FOCUS, the FinOps open cost and usage specification, so what comes back is a resource inventory joined to a cost model rather than two exports somebody reconciles by hand.
If you have had enough of seeing only part of what you own reflected in your inventory reports, it is time to look at a discovery and inventory capability that gives you real coverage.
CerteroX ITAM includes multi-platform, multi-location discovery of every type of IT asset, and it is the foundation the ITAM and SAM capability of the CerteroX platform is built on. Because it is part of that platform rather than bolted to it, there is no separate interface to administer or report through.
Discovery and inventory is also available as a managed service, where experienced ITAM professionals take you through building a complete view of what is deployed. That can be a one-off baseline for you to run yourself afterwards, or an ongoing service.
Whichever route suits you, do not run your ITAM, ITSM and SAM programmes on part of the picture. Talk to us.
Other posts covering the same ground.
Before optimisation, rationalisation or audit defence, most organisations need something less glamorous: a trustworthy answer to what they actually own. Why the foundational phase deserves its own name — and what counts as "stuff" now that most of it never touches your network.
Providers compete on the size of their normalisation database. Size is the wrong measure. What decides whether recognition is any good is how each entry got there.
Reclaiming hardware and licences that nobody is using is the cheapest saving available to an IT team. What it takes is metering you can trust, a policy people will accept, and an inventory that actually finds everything.
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.