Device counts across security, inventory, and monitoring tools rarely match due to differing definitions and data sources. Here’s the real reason why and how to finally fix it, from a senior engineer who’s been in the trenches.

My Device Counts Never Match. Is This Just My Life Now?

I remember it like it was yesterday. It was a Tuesday, which meant patching. Our vulnerability scanner was screaming about 47 critical RCEs on a fleet of 250 Linux servers. No problem. We pushed the patches via Ansible, watched the playbooks run green, and went for coffee. An hour later, the scanner report came back: 27 hosts still vulnerable. My heart sank. We checked Ansible Tower; it said all 250 hosts were patched successfully. We checked our inventory CMDB; it listed 250 active servers. So where were these 27 ghost machines coming from? It turns out they were decommissioned VMs that were never properly scrubbed from DNS or the scanner’s asset list. We spent the next four hours manually reconciling CSVs instead of working on the next project. If that sounds familiar, pull up a chair. You’re not crazy; the problem is real, and it’s solvable.

The “Why”: There Is No Single Source of Truth

The core of the problem isn’t that one tool is “wrong.” It’s that every tool has its own definition of what a “device” is, and it builds its own private database based on that definition. They all have a different perspective, a different lifecycle for tracking assets, and different methods of discovery.

Think about it like this:

Without a central authority, you’re left with these conflicting reports. You can’t secure what you can’t see, and you can’t trust your automation if its map of the world is wrong. So, how do we fix it?

The Fixes: From Duct Tape to Bedrock

I’ve seen teams tackle this in a few ways, ranging from “get it done by Friday” to “let’s fix this for good.”

1. The Quick Fix: The Reconciliation Script

This is the classic “export to CSV” and mash them together approach, but with a bit of automation. It’s a band-aid, but it’s a very effective one for quarterly audits or emergency patch validation. You pull reports from your key systems and use a simple script to find the outliers.

For example, you want to find devices that are in your vulnerability scanner but NOT in your endpoint manager. This could indicate rogue devices or machines with broken agents.

# Super simple conceptual Python script
import pandas as pd

# Load your CSVs
scanner_df = pd.read_csv('nessus_export_all_hosts.csv') # Has columns 'IP', 'Hostname'
endpoint_df = pd.read_csv('intune_export_all_devices.csv') # Has columns 'deviceName', 'PrimaryIP'

# Normalize hostnames to be consistent (e.g., all lowercase)
scanner_df['Hostname_lower'] = scanner_df['Hostname'].str.lower()
endpoint_df['deviceName_lower'] = endpoint_df['deviceName'].str.lower()

# Get the list of hostnames from each source
scanner_hosts = set(scanner_df['Hostname_lower'])
endpoint_hosts = set(endpoint_df['deviceName_lower'])

# Find the differences
ghost_devices = scanner_hosts - endpoint_hosts # In scanner but not in Intune
unscanned_devices = endpoint_hosts - scanner_hosts # In Intune but not in scanner

print("--- GHOST DEVICES (Potential rogue/broken agent) ---")
for device in sorted(ghost_devices):
    print(device)

This is fast and answers a specific question right now. Its weakness? It’s a manual process, it’s reactive, and the data is stale the moment you export it.

2. The Permanent Fix: A Real CMDB as Your Source of Truth

This is the grown-up solution. You establish a single, authoritative source for what constitutes an active, managed device in your environment. This could be a tool like ServiceNow, Device42, or even a well-structured NetBox instance. The rule becomes: if it’s not in the CMDB, it doesn’t exist.

The workflow looks like this:

• A new server, prod-db-01, is provisioned via Terraform.
• The last step of the provisioning process is an API call to the CMDB (e.g., NetBox) to create an entry for prod-db-01, tagging it with its IP, owner, and status (‘provisioning’).
• Your other tools no longer use their own discovery. Instead, they query the CMDB’s API for their targets.
• Ansible asks the CMDB for all servers tagged ‘production’ and ‘linux’.
• Your vulnerability scanner gets its scan targets directly from the CMDB.
• When prod-db-01 is decommissioned, the automation updates its status in the CMDB to ‘decommissioned’, which automatically and immediately removes it from all downstream processes.

Pro Tip: A CMDB is not a “set it and forget it” tool. It requires discipline. If people can still spin up servers without registering them, you’ve just created one more system to be out of sync. Your CMDB is only as good as the data and processes feeding it. Garbage in, garbage out.

3. The ‘Nuclear’ Option: Strict, Automated Lifecycle Enforcement

This approach focuses on process and automation above all else. It’s less about a specific tool and more about enforcing a rigid lifecycle for every single asset. It’s “nuclear” because it often involves breaking old habits and forcing everyone to follow a new, stricter process.

Here’s the philosophy: No device gets network access until it’s fully onboarded. No device is considered ‘gone’ until it’s fully offboarded from every system.

How it works in practice:

1. Onboarding: A VM isn’t just “created.” An automation workflow does it all:
   • Creates the VM.
   • Registers it in the CMDB (our source of truth from Fix #2).
   • Installs the endpoint agent.
   • Adds it to the backup schedule.
   • Adds it to the monitoring tool.
   • Only then does it open the necessary firewall ports for it to be considered “online.”
2. Offboarding: You don’t just delete a VM. You trigger a “decommission” workflow:
   • The workflow first removes it from monitoring, backups, and scanning targets.
   • It uninstalls the endpoint agent.
   • It removes the object from Active Directory.
   • It updates its status in the CMDB to ‘decommissioned’.
   • Only then is the VM actually deleted.

This option requires significant upfront investment in scripting and automation (using tools like Ansible, Terraform, and maybe some custom glue code), but it makes discrepancies nearly impossible. It turns your infrastructure into a perfectly synchronized machine where manual reconciliation becomes a forgotten nightmare.

So no, this doesn’t have to be your life now. It’s a common problem born from complexity, but with the right strategy—whether it’s a quick script for today or a full-blown automation overhaul for tomorrow—you can finally make the numbers match.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions