Most vulnerability management programs start from an inventory that was accurate on the day someone built it and has been decaying ever since. The gap between what a CMDB claims exists and what actually answers on the network or in a cloud account is rarely a rounding error. It is the space where incidents start, because nobody patches, monitors, or scopes compliance controls for a host they do not know they own. This is a working framework for that gap: how to categorize it, why it opens up in the first place, where the untracked assets actually come from, and what to do in the first two days after you find one.
The known and unknown asset matrix, and why each cell needs a different method
Borrowing the old known/unknown framing gives asset management a useful four-quadrant map. Each quadrant answers to a different owner and a different discovery technique, which is exactly why a single scan profile never closes the gap on its own.
| Quadrant | What it looks like | How you find it |
|---|---|---|
| Known known | In the CMDB, tagged, reachable, scanned on schedule | Routine authenticated or agent-based scan |
| Known unknown | Flagged as decommissioned or “probably retired” but status unverified | Targeted liveness check: ping, TCP SYN, certificate check against the recorded hostname |
| Unknown known | A business unit or vendor knows it exists; security does not | Procurement records, ticket mining, stakeholder interviews |
| Unknown unknown | Nobody in the organization can name it when asked | Passive DNS, certificate transparency logs, cloud provider APIs, ASN sweeps |
Treating all four the same way is the most common design error in a discovery program. A daily authenticated agent sweep will never surface an EC2 instance a developer launched under a personal AWS account, and a certificate-transparency crawl will never confirm whether a host still has an open management port. Platforms that run discovery as a dedicated pipeline phase, such as SITEY, separate these into distinct jobs: an authenticated sweep for the known estate and an external ASN and certificate-transparency sweep for the unknown one, rather than one scan configuration expected to cover both.
Typical numbers from a first discovery sweep, and why the gap runs so wide
Run an external, unauthenticated discovery pass against an organization for the first time and it is common, not exceptional, for the count of live, reachable hosts to exceed what the CMDB lists by a wide margin. The gap is not evenly distributed either: most of it concentrates in a handful of sources rather than spreading uniformly across the estate.
The structural reasons this happens are consistent across organizations of very different sizes:
- Source-of-truth fragmentation. The CMDB, the cloud provider’s tag inventory, the DNS zone file, and the network access control list are each maintained by different teams on different cadences, and nobody reconciles them.
- Self-service infrastructure. A developer with a cloud console login can stand up a public-facing instance in minutes without touching a change process that would register it anywhere.
- Mergers and subsidiaries. Acquired companies bring their own DNS zones, cloud accounts, and VPN endpoints, and full network integration often lags the legal close by months or years.
- Decommission that does not propagate. A server gets powered off in the data center but its DNS record, load balancer rule, or firewall exception is never removed, so a replacement or a re-provisioned IP silently inherits old exposure.
None of these require malicious intent. They are the ordinary byproduct of how fast infrastructure moves relative to how slowly documentation processes move.
Where unknown assets are born: procurement, agencies, testing, vendors
If you trace an unknown asset back to its origin, it almost always falls into one of four birthplaces, and each one leaves a different kind of trail.
Procurement outside IT
A business unit buys a SaaS tool or spins up a virtual machine on a corporate card, without a ticket, a change request, or an entry in the asset register. The trail here is financial: expense reports and vendor invoices often name the resource before any technical system does.
External agencies
A marketing or design agency stands up a campaign landing page, a WordPress instance, or a microsite on a domain variant of the brand. The campaign ends, the agency’s contract ends, and the DNS record and the server both keep running. The trail here is the domain registrar and the certificate transparency log: campaign subdomains tend to follow naming patterns like promo-, launch-, or a product codename.
Test and staging environments
An engineer clones production for a proof of concept, sometimes with production data still attached, and the environment is never torn down once the proof of concept ships or dies. The trail here is internal: build logs, CI/CD pipeline history, and internal chat mentions of “temp” or “poc” hostnames.
Third-party and vendor access
An integrator or managed service provider opens a jump box, a VPN concentrator, or an API gateway to deliver a project, and the access outlives the project because closing it was never assigned to anyone. The trail here is the vendor’s own project documentation and the firewall rule that granted the access in the first place, which usually still carries the vendor’s name or the project code in its description field.
Knowing the birthplace changes where you look first. A finance record search is far faster than a network sweep for the procurement case, while the certificate transparency log is the fastest path for the agency case.
The first 48 hours after discovery: containment, verification, ownership
Finding an unknown asset is the easy part. What a team does in the next two days determines whether it becomes a managed part of the estate or turns into a second incident on top of the first.
- Hours 0 to 2, containment triage. Check whether the asset is internet-facing with an open administrative port (RDP, SSH with password auth, an exposed database port, an unauthenticated management console). If so, restrict access at the firewall or security group level immediately. Do not delete or power off the asset yet: you may need it for evidence, and it may be quietly load-bearing for something you have not identified.
- Hours 2 to 8, fingerprinting. Banner-grab open services, pull the TLS certificate subject and issuer, run a WHOIS lookup on the associated domain, and check the cloud provider’s tags and account ownership if it is cloud-hosted. If you can safely capture a short window of traffic, note which internal systems or users are actually calling it.
- Hours 8 to 24, ownership hunt. Search procurement and billing records for the hostname or IP, check git commit history and CI/CD logs if it looks like a deployed application, and search tickets and chat history for the hostname string. Check the domain registrant contact if it was born from an external agency engagement.
- Hours 24 to 48, formal disposition. Either onboard the asset into the inventory with a named owner and a defined scan and patch cadence, or decommission it through a documented change ticket. If no owner surfaces and there is no traffic evidence of a legitimate business function, the default should be to extend the containment and schedule decommission, not to leave it in an undocumented limbo indefinitely.
The ownership hunt is usually the slowest step, and it is also the one most amenable to automation. Systems that pair discovery with triage, such as SITEY, attach a suggested owner to a newly found host by cross-referencing DNS registrant data, cloud account tags, and the pattern of open ports against a rule set, which turns hours eight through twenty-four into a review step instead of a research project.
The metric that makes “unknown” measurable: new-asset discovery rate
You cannot manage what you do not track over time, and “unknown assets” is not a one-time count, it is a rate. The useful metric is the new-asset discovery rate: the number of previously unseen, live assets surfaced in a given scan cycle, expressed as a percentage of the total known active inventory for that cycle.
Compute it as: (assets found this cycle that were never seen in any prior cycle) divided by (total active inventory at the end of this cycle). Track it cycle over cycle, not as a single snapshot.
What the trend should look like: a program in its first two or three cycles typically shows a high rate, because the backlog of long-lived unknown assets is still being drained. A mature program should see that rate decay toward a low, stable baseline. If the rate stays flat or climbs after several cycles, the root cause is not a scanning gap, it is an unmanaged source still producing new assets, most often an unrestricted cloud subscription, an unmonitored acquisition, or a business unit still provisioning outside the change process. Treating a persistently high rate as a tuning problem for the scanner wastes a cycle; treating it as a source-control problem gets you to the actual fix.
This metric also does double duty for audits. Frameworks that require a documented, current asset inventory, including ISO 27001 Annex A.8.1 and PCI DSS scope validation, are easier to demonstrate with a declining discovery-rate trend line than with a single point-in-time inventory count, because it shows the control is operating rather than having been performed once.
A phased order for teams building inventory from scratch
Teams that skip straight to full authenticated scanning across an entire IP range before confirming what is even alive generate noise, trigger unnecessary alerts on other teams’ monitoring, and waste time scanning dead address space. A staged order avoids that.
- Passive collection. Build a candidate list with no active probing: passive DNS records, certificate transparency logs, cloud provider resource APIs, and IP ranges pulled from RIR (regional internet registry) records for your ASNs.
- Light active verification. Run a liveness sweep against the candidate list only, ICMP and TCP SYN checks plus a light banner grab on common ports, to confirm which candidates are actually live without generating the load or noise of a full scan.
- Authenticated deep scan. On confirmed-live, in-scope hosts, run a full authenticated or agent-based scan to pull software inventory, patch levels, and configuration state.
- Ownership reconciliation. Match every confirmed asset against the CMDB, procurement records, and directory data, and flag every mismatch for the 48-hour triage process above.
- Continuous delta scanning. Schedule a recurring sweep, for example a daily cloud API poll and a weekly external passive-plus-light-active pass, and route every new find automatically into the containment and ownership workflow rather than into a manual review queue.
The discipline that separates a working inventory program from a perpetual one-time project is step five. Continuous platforms treat the delta sweep as a standing pipeline phase rather than a periodic special project, feeding new-asset hits directly into deduplication and triage instead of restarting the discovery exercise from zero every quarter, which is the pattern SITEY’s discovery phase is built around.
None of this requires exotic tooling. It requires sequencing the cheap, passive methods before the expensive, active ones, assigning a clock to the ownership hunt so it does not stall indefinitely, and tracking the discovery rate as a trend rather than treating each sweep as a self-contained project. The assets your inventory never listed do not stay unknown because they are hard to find. They stay unknown because nobody assigned finding them a process.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.