Most organisations that believe they have full discovery are working from instinct rather than evidence. Complete coverage needs several independent methods that corroborate each other — and today "everything" includes SaaS, cloud and AI, which no network scan will ever find.
Everything in asset management rests on discovery. If a device, an application or a subscription is not in the inventory, it is not in the licence position, not in the security posture, not in the renewal calendar and not in the budget. It is simply invisible, and it stays invisible right up until it becomes a finding.
So the question in the title is the one that matters most, and it is worth asking sceptically. Plenty of organisations will tell you they have complete discovery. Ask how they know, and the honest answer is usually that it feels about right — the numbers have been stable for a while, nothing obviously alarming has turned up, and nobody has raised it. That is instinct, not evidence, and instinct has a systematic blind spot: it can only reason about the things it already knows exist.
The usual cause of a gap is a discovery approach that only works one way.
Any single discovery mechanism has a shape, and outside that shape it sees nothing.
An agent-based approach gives you excellent depth on the machines that have the agent. But an agent has to be deployed to a machine somebody already knew about. If the machine is unknown, the agent is not on it, and the agent will never tell you it is missing. This is circular in a way that is easy to miss when you are looking at a healthy-looking agent count.
A common patch is to let Active Directory drive deployment: something joins the domain, a policy notices, an agent is pushed. Sensible enough, until you list what Active Directory does not know about.
That is not a short tail. In most organisations it is where the interesting risk lives.
The way out is to separate the two activities that get conflated. Discovery finds out what exists. Inventory finds out what is on it. You need the first to be independent of the second, or you will only ever inventory what you already knew about.
CerteroX ITAM performs active network discovery across NetBIOS, SNMP and ICMP, sweeping a class-C subnet in under five seconds, and probes to establish where an agent can actually be deployed. It finds the machines before you own them, and it does so without needing anything installed on them first.
That gives you the population. Ten discovery methods then feed the inventory: the native agent, command-line inventory via csinvcli, agentless collection, standalone inventory for air-gapped and offline systems, network scanning, Active Directory import, third-party ITAM import, cloud and SaaS connectors, browser monitoring and file metering. All ten land in one schema. There is no reconciliation project between them, because there is nothing to reconcile.
Six operating system families are covered by the same native agent: Windows, macOS, Linux, IBM AIX, HP-UX and Oracle Solaris. The point is not the count. It is that AIX, HP-UX and Solaris get the same inventory cycle and the same licence engine as Windows rather than being handled as an integration exercise, which is what usually turns them into an exception nobody maintains.
Coverage is not the same as confidence. To be sure you have found everything you need sources that overlap, so each one can be checked against the others and the gaps show up as disagreements.
That is the job of connectors. CerteroX ITAM ships 28 named system connectors, and CerteroX SAM adds publisher-side ones. Between them they cover the systems that already hold a partial answer:
Each of these knows about a slice of your environment. Pull all of them and the arithmetic starts working for you: the hypervisor reports forty guests, the agent reports thirty-seven, and now you have three specific machines to explain rather than a vague suspicion that something is missing. That difference — a named discrepancy instead of a feeling — is what “we have discovered everything” has to be built on.
Two supporting behaviours matter here. Duplicate system detection stops a re-imaged machine appearing twice and quietly inflating both your device count and your licence exposure. Stale device archiving removes machines that have genuinely gone, so the population reflects reality rather than accumulating history. Non-persistent VDI is handled explicitly, because it otherwise generates a new device on every session and destroys the numbers.
Everything above is about the network, which is where the entire question lived when this article was first written. It is now roughly half the question.
A meaningful share of what your organisation depends on today was never installed on anything you own. Somebody signed up with a corporate card and a work email address. There is no agent to deploy, no subnet to sweep, no domain to join. A network scan will not find it, and neither will Active Directory, because from the network’s point of view nothing happened.
CerteroX SaaS Management approaches that surface the same way this article approaches the network: several independent signals that corroborate each other. Three converge.
Identity provider sync from Entra ID or Okta shows what people are signing in to, including MFA enrolment status. It is authoritative for anything behind single sign-on, and silent about everything that is not.
Connector sync pulls the authoritative user and licence list directly from the vendor. Forty-seven connectors ship today, resolving against a catalogue of more than 35,000 applications. This is the only source that knows what you are actually being billed for, as opposed to who has logged in.
A browser extension detects the applications in use that neither of the other two can see — the ones outside SSO, bought outside procurement, used by three people in one team. It records the domain, time-on-app and per-user attribution.
Where those three disagree, you have found something. An application the browser extension sees and the identity provider does not is unsanctioned. Seats the connector reports and the identity provider cannot account for are being billed for people who have left.
The same discovery pass surfaces two things that are security findings rather than licence findings. OAuth grant discovery catalogues every third-party application somebody has consented to, scored from 0 to 100 on data sensitivity, scope, consent and dormancy — a dormant grant with broad read access to a company drive is a live exposure regardless of whether anyone still uses the application. And Shadow AI detection classifies AI tools from application feature tags in the catalogue rather than from a hardcoded list, so the detection set grows as the market does instead of ageing the moment it ships.
Cloud is the third surface. CerteroX Cloud Management inventories resources across twelve cloud and data platforms, which is where you find the instances that were spun up for a project that ended eighteen months ago and have been billing ever since.
Complete discovery is not a state you reach and then stop. It is a property of how you collect: several methods, running continuously, overlapping deliberately so that anything missing shows up as a contradiction between two sources rather than as an absence you would have to already suspect.
The test is simple enough to apply. If someone asks how you know you have found everything, you should be able to answer with the methods you run, the sources you reconcile them against, and the discrepancies that reconciliation is currently reporting. If the answer is a number and a shrug, the number is not evidence.
To see what a multi-method discovery pass turns up that a single agent misses, 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.