Why the First IT Discovery Scan Always Finds More Than Expected

First IT discovery scan findings consistently return 30 to 80 percent more assets than a manually maintained CMDB — not because the scan malfunctions, but because manual processes miss every provisioning event that bypasses a formal change ticket. The gap is a measurement of what already exists in the environment. Understanding its composition — cloud resources, ghost assets, unmanaged devices, and orphaned software — determines which team owns each category and what Day 1 remediation looks like.

The IT director at a mid-size financial services enterprise blocked two hours on his calendar for the first formal scan review. His team had maintained a CMDB of 2,400 assets over three years, and the plan was straightforward: run IT Discovery and compare the output against existing records, closing minor gaps before the upcoming audit cycle. The scan returned 3,847 assets. The two-hour review turned into two days.

That 60 percent gap — 1,447 assets above the expected count — is not an edge case. In every environment we bring Virima discovery into for the first time, first IT discovery scan findings exceed the manual inventory. This IT asset discovery gap is not an exception — it is the expected output of an environment that grew faster than manual processes could track. The question is what the gap is built from, because each category behind it has a different owner, a different risk profile, and a different Day 1 response.

Understanding the structure of first IT discovery scan findings matters because treating the delta as a single backlog creates a cleanup project with no end date. Treating it as four distinct categories creates four parallel workstreams, each with a defined owner and a clear completion criterion.

Virima builds Trusted Runtime Truth from a discovery-sourced baseline, establishing an accurate picture of what IT teams actually own — and why the first scan is the most important single data collection event your team will run.

Why the CMDB diverges from the real environment

Most CMDBs are built through reactive, ticket-based processes. A server gets provisioned, a change ticket opens, someone creates the CI record. When any step in that chain is skipped, the CI never gets created. In environments that have grown through cloud migrations, team handoffs, and organic provisioning, those skipped steps accumulate over years without anyone tracking the total.

The team in this scenario had maintained their CMDB manually for three years across two infrastructure teams and one cloud migration. No single decision created the 1,447-asset gap. It accumulated through every provisioning event that bypassed the formal change process, every decommissioned device whose record was closed before the hardware was confirmed removed, and every cloud resource whose engineer assumed someone else would create the CI.

That pattern holds across environments of every size. According to Gartner’s 2025 IT Operations Management research, most enterprises running a formal discovery exercise for the first time find asset counts 30 to 80 percent higher than their existing manual inventory. First IT discovery scan findings do not generate the gap. They measure it.

The four-category gap framework

Cloud resources provisioned outside change management — 847 assets

The largest single category: 847 cloud resources in AWS and Azure, including virtual machines, storage buckets, load balancers, and container instances, that had never entered the formal change management process.

The root cause is speed. An engineer can spin up a virtual machine in minutes. The change ticket that should follow frequently gets deferred and then forgotten. The resources accumulate in the cloud environment with no corresponding CI record in the CMDB. Unrecorded cloud resources cannot be scoped into security reviews, assigned to a cost center, or included in software license reconciliation. They operate outside every governance process that relies on the asset record.

NIST SP 800-128 requires all configuration items — including cloud-hosted resources — to appear in a complete and current inventory. When 847 resources are missing from that inventory, every process that reads from it starts with an incomplete picture.

IT Asset Management processes that depend on the CMDB for cloud cost allocation face the same problem: you cannot optimize spend on resources you do not know exist. Unrecorded cloud resources also represent direct financial exposure — cloud spend tied to assets with no CI record cannot be allocated, optimized, or included in budget forecasting.

Ghost assets still broadcasting — 312 assets

312 assets had CMDB records marked as “decommissioned” or “retired.” Discovery found them still active on the network. Their network interfaces were responding to queries. The physical hardware had not been removed, and the formal decommissioning process had never confirmed network silence before closing the CI record.

Ghost assets appear in first IT discovery scan findings because Agent-based vs. agentless discovery: which is best for your business? reads live network traffic, independent of CMDB lifecycle status fields. If the interface responds, discovery finds the device. Virima’s agentless scan queries live interfaces regardless of CMDB lifecycle status — so a device your CMDB marks as “retired” still appears in discovery output if its network interface responds.

What are ghost assets and why do they appear in discovery scans?

Ghost assets are devices marked as retired or decommissioned in the CMDB that remain active on the network. They surface in first IT discovery scan findings because discovery reads live network interfaces rather than CMDB lifecycle fields. They create three specific risks: unpatched devices on the network with no active owner, incident alerts that route to a team with no responsible party, and change management records that reference retired CIs when calculating blast radius.

Not sure if your CMDB has ghost assets? IT Asset Discovery — we’ll show you which of your marked-decommissioned devices are still live on your network.

The CMDB Best Practices: How companies can get it right correction here is a decommissioning workflow that verifies network silence before the CI record is closed and logs the physical removal step separately from the administrative record closure. Without that step, ghost assets grow with every hardware refresh cycle.

Unmanaged devices on the corporate network — 203 assets

203 devices had no CMDB record at all — not stale or miscategorized entries, but entirely absent records. These devices were connecting through network access points that bypassed IT’s formal onboarding process: corporate WiFi without network access control enforcement, hardware purchased through departmental budgets outside IT procurement, and devices left behind by vendors after engagements that were never formally retrieved.

Why do unmanaged devices appear in first IT discovery scan findings?

Unmanaged devices reach the corporate network through procurement or access channels outside IT’s visibility: BYOD devices on corporate WiFi without NAC enforcement, departmental hardware purchased outside IT procurement, and vendor equipment left on-site post-engagement. They have no CMDB records because no approved process created them. Discovery finds them by scanning network traffic directly, without needing an existing asset record to match against. In practice, shadow IT in enterprise networks accumulates through exactly these three channels: BYOD on corporate WiFi, departmental procurement, and post-engagement vendor equipment.

Shadow IT in enterprise networks accounts for an estimated 30 to 40 percent of total IT spending in many organizations, according to Gartner and Auvik research. The 203 unmanaged devices in this scan represent that exposure in its most concrete form: assets operating without IT visibility, owner assignment, or patch schedules.

Virima’s combined agentless and API-based scanning covers both corporate WiFi-connected devices and cloud-provisioned resources, which is why unmanaged devices surface even when they’ve bypassed IT’s formal onboarding process.

Each of these 203 devices had no assigned owner, no patch schedule, and no change authority. Any incident involving one of them began without a responsible party.

Software installs with no asset record — 84 installs

The smallest category by volume, but the most common source of license audit surprises: 84 software installs found on managed machines with no corresponding software asset record. These were not rogue applications on unmanaged devices. They were local installs on devices with valid CMDB records. The software inventory had never been formally captured through an active scan.

The reason this category exists is the Active vs. passive IT asset discovery: which one works better? method gap. Passive discovery captures what applications communicate over the network. Active discovery returns the full local install manifest from each endpoint. When a team relies primarily on passive methods, locally installed software that does not generate consistent network traffic remains invisible until an active scan runs.

The delta is the baseline — not a failure

When first IT discovery scan findings return a number 60 percent above the expected inventory, the instinct is to find who got the CMDB wrong. That framing misses the actual cause.

The CMDB reflects the processes that built it. If those processes relied on manual ticket creation, the CMDB reflects every step in that process that was skipped. The 1,447-asset gap is not evidence of poor CMDB management. It is the expected output of an environment that grew faster than manual processes could track.

Accepting that reframes the first scan result from a problem to a measurement — the most accurate measurement of the environment the team has ever had. A CMDB accuracy baseline is the verified asset count established by the first full discovery scan: the benchmark against which all subsequent scans measure drift. The work that follows is the CMDB catching up to the environment, not the other way around.

Is a large gap between a CMDB and first IT discovery scan findings normal?

Yes. Environments that have grown through cloud provisioning, acquisitions, or organic infrastructure expansion consistently return first scan counts that exceed manual inventory by 30 to 80 percent. The gap reflects the limits of manual CMDB processes, not IT negligence. A large gap on the first scan means discovery is working correctly — it found the assets that manual processes missed.

What to do with the delta on Day 1

Acting on first IT discovery scan findings starts with categorization, not remediation. Sorting the 1,447-asset delta into its four categories creates four parallel workstreams, each with a natural owner.

Triage by category

Day 1 triage follows category, not severity:

1. Cloud resources outside change management → cloud architecture team
2. Ghost assets → owner of the decommissioning process
3. Unmanaged devices → network security
4. Orphaned software installs → software asset management

Assign interim ownership

Every unrecorded asset needs a named interim owner before remediation begins. Without a named owner, no one has authority to decommission a ghost asset, challenge an unmanaged device’s network access, or reconcile a software install against a license agreement.

Decommission confirmed ghosts first

The 312 ghost assets broadcasting with no active business purpose are the highest-priority remediation target. They inflate the attack surface, create incident routing failures, and add noise to every downstream process that reads the CMDB.

Start a 14-day discovery cadence

The most common mistake after the first scan is delaying the second scan until the CMDB “looks cleaner.” The environment does not pause. Start a 14-day discovery cadence from Day 1 — don’t wait for the backlog to clear. Each cycle closes the gap faster than any manual remediation effort.

Building a CMDB from a discovery-sourced baseline gives every remediation decision a verified foundation. Introducing ViVID Service Maps built from that CMDB show which remaining gap assets carry the most service dependency risk, so remediation priority is set by operational impact rather than asset count alone.

Eight weeks after the first scan, the financial services team’s CMDB contained 3,741 assets, all of them verified through Audit-Ready Asset Management Dashboards With Continuous Discovery cycles. 106 confirmed ghost and vendor assets had been removed from the network. The cloud resource CI gap had been closed. The unmanaged devices had onboarding tickets or had been removed. The software installs had been reconciled against active license agreements.

The audit preparation cycle that followed this team’s first scan took 40 percent less time than the prior year. Every CI in scope had a verified owner, a confirmed network status, and a discovery-sourced record. That is what acting on first IT discovery scan findings actually produces: not a bigger CMDB number, but a verified CMDB accuracy baseline that every downstream process can rely on.

The gap is the truth. Build on it.

Frequently Asked Questions