There is no silver bullet in asset discovery, but there is a short list of things a tool must do natively. Six attributes to test a discovery product against, and what each one looks like when it actually works.
A software asset management programme starts with one question: what have we got? Every subsequent activity — the licence position, the audit defence, the rationalisation exercise, the migration plan — inherits whatever accuracy you achieve at that first step.
Get discovery wrong and everything downstream is wrong in ways that are hard to see. A licence position calculated from an inventory missing 8% of your devices does not look 8% wrong. It looks finished.
Plenty of discovery tools in the ITAM market claim to be one. None of them are. What you can do is work out which functions you will genuinely need, and test candidates against those rather than against a feature grid.
Here are the ones that matter.
Confidence in your data comes from cross-checking it. If several independent sources agree on a device, you can trust the record. If one source knows about a machine and nothing else does, that is the interesting case — and you can only see it if you are taking multiple feeds in the first place.
Connectors should work out of the box. If integrating with your virtualisation platform is a services engagement, deployment into a large environment will cost more in consultancy than the tool costs in licence. The connectors organisations need vary, but the usual list is Active Directory, VMware, Hyper-V, XenServer, SAP, IBM, AWS and Oracle.
What this looks like when it works. CerteroX ITAM ships 28 named system connectors, covering Active Directory, Microsoft SCCM, Intune and WSUS; VMware, Hyper-V, XenServer, Oracle VM, Red Hat oVirt and Nutanix; IBM HMC; AWS and Azure; and older management platforms such as LANDesk and Altiris that are still in the ground in plenty of organisations. On the SAM side there are dedicated paths into Oracle Database, IBM ILMT, SAP, Salesforce, Adobe Creative Cloud, Microsoft 365 and Google Workspace.
You need to find every network-attached device, not just the ones that can run an agent. Desktops and servers, yes — but also network printers, switches, appliances and whatever else has quietly been plugged in.
That means several protocols, run efficiently enough that scanning is routine rather than a scheduled event people dread, and collecting as much detail as possible without an agent. This is the check and balance against what your connectors told you.
What this looks like when it works. 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 could actually be deployed. Discovery runs ahead of deployment rather than after it, which is the right order and an unusually rare one.
SNMP collection also brings back real operational detail from devices that will never take an agent: printer consumables and page counts, switch port tables and routing tables. Those devices stop being a line in a spreadsheet and become managed assets.
There should be no dependence on third-party software to collect inventory from client devices, whether by agent or agentless method. A tool that requires SCCM to be healthy in order to know what you own has simply moved the problem.
Deployment efficiency is directly linked to the previous two attributes: if the connectors and the network scan have already established what a device is, where it is and whether it is reachable, the tool can pick the right collection method itself. And every platform needs to be a target — Windows, macOS, Unix, Linux, not just the ones that are easy.
What this looks like when it works. One native agent covers Windows, macOS,
Linux, IBM AIX, HP-UX and Oracle Solaris, with the same inventory cycle and the
same licence engine across all six. Where an agent is not possible there is
agentless collection and a command-line collector (csinvcli) for locked-down
machines, and standalone inventory for air-gapped and offline systems that no
scan will ever reach. Non-persistent VDI is handled as its own case rather than
generating a fresh device record every morning.
Altogether that is ten discovery methods — agent, command line, agentless, standalone, Active Directory, network scan, third-party ITAM import, cloud and SaaS connectors, browser monitoring and file metering — all landing in one schema. There is no reconciliation project between them, because there is nothing to reconcile.
Knowing the coverage of your inventory across everything you own is what makes a SAM programme measurable. Reports have to combine every data source into one view, or you are back to comparing lists.
Trend reporting matters more than it first appears. A point-in-time report tells you where you are. A trend tells you whether the programme is working, which is what you will be asked in month six.
What this looks like when it works. Trend charts, KPIs and threshold alerts, with personal and role-shared dashboards. Governance Policies express a condition once — as compliance-as-code with a reusable filter builder — and report against it continuously, so “which devices have not reported in 30 days” is a standing policy rather than a report somebody remembers to run. There is also a read-only API with a documented Power BI data source, for the reporting your organisation was always going to do in its own tooling anyway.
Newly discovered systems should be targeted automatically against criteria you define, so that every active device submits a full hardware and software inventory without anyone deciding to make it happen. Discovery that requires a human to act on each finding decays to nothing within a quarter.
What this looks like when it works. Dynamic, static and custom groups built from a query builder or raw SQL determine what gets targeted, so the rule is yours rather than the vendor’s. Duplicate system detection and stale device archiving keep the record honest in the other direction — which matters a great deal when your licence position is calculated from the device count.
This one was not on the original list, because in 2016 it was not yet the problem. It now is, and it is the single largest gap in most organisations’ inventories.
Network discovery finds what is on your network. An increasing share of what your organisation uses is not: SaaS applications bought on a departmental card, cloud resources spun up in an account nobody has told the ITAM team about, and AI tools adopted by individuals faster than any procurement process can track.
A discovery tool that only sees the network is now describing a shrinking fraction of what you actually run.
What this looks like when it works. CerteroX SaaS Management converges three independent discovery signals: identity provider sync from Entra ID and Okta, authoritative user and licence lists pulled from 47 shipping vendor connectors, and a browser extension that detects SaaS domains with per-user attribution and time-on-app. Where the connectors do not reach, the browser signal does — which is how unsanctioned applications surface at all.
AI tools are classified from application feature tags in a catalogue of more than 35,000 applications rather than from a hardcoded list, so the detection set grows without waiting for a product update. OAuth grant discovery finds the third-party applications your users have consented to give access to company data, and scores each grant on sensitivity, scope, consent and dormancy.
On the cloud side, CerteroX Cloud Management inventories resources across twelve cloud and data platforms and ingests billing natively against the FinOps Open Cost and Usage Specification, so cloud assets arrive in the same picture rather than as a separate finance conversation.
You may already be running a discovery tool. The exercise is not to replace it reflexively — it is to work out honestly what it does and does not give you against the six attributes above.
Three questions will usually settle it:
How does it find a device nobody has told it about? If the answer involves importing a list, it is an inventory tool rather than a discovery tool.
What does it do about machines where an agent cannot be installed, and about the ones that never touch the corporate network? Every environment has both, and both are usually where the expensive licensing lives.
When it collects the same device twice by two different methods, which record wins, and where does that decision happen? If the answer is “in a spreadsheet afterwards”, you have bought half a product.
If something is clearly missing, that is worth acting on — not because the tool is bad, but because everything you build on top of it inherits the gap.
To put any of this to a technical person with the product open, book a demo.
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.
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.
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.
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.