What do you do when the CMDB and the security tools disagree?

Why does the CMDB drift?

A CMDB records what its feeds tell it. ServiceNow describes its CMDB as a single, trusted system of record for configuration item data, curated from multiple sources through Service Graph Connectors. That works when every feed is complete and current. In practice some networks are not discovered, some teams create cloud resources outside the normal process, and devices that leave the organisation never get retired. The CMDB keeps the old records without saying so.

Security tools drift differently. The EDR console knows every device with its agent and nothing else. The vulnerability scanner knows what it scanned. Neither knows which business service a server supports, which is exactly what the CMDB is good at.

How do you find the differences?

Line the sources up against each other, asset by asset. The patterns are usually the same:

1. In the CMDB, missing from security tools. Often a device without its EDR agent, or a record for something that no longer exists.
2. In security tools, missing from the CMDB. Often a device or cloud workload created outside the normal process.
3. In both, with different values. A different owner, location or operating system, usually because one source is stale.

A CAASM platform does this comparison continuously. Axonius documents a ServiceNow adapter that fetches CMDB tables for reconciliation, and in July 2026 described a CMDB Reconciliation Workspace that flags assets missing from the CMDB and mismatched field values.

Who decides which record wins?

Not the tool. Decide per field, with the people who own each kind of fact. The EDR console is probably right about whether its agent is installed. The CMDB is probably right about which service a server supports. The identity provider is probably right about who a user is. Write those rules down, because every reconciliation tool will ask you for them.

How do corrections get back into the CMDB?

Through the CMDB's own process, so that IT workflows keep trusting it. Some inventory tools write back directly: Axonius documents enforcement actions that create, update and remove ServiceNow assets, and runZero describes a ServiceNow integration for CMDB enrichment. Whichever route you use, keep a human approval step for deletions and for changes to fields that drive workflows.

What are the common traps?

Three come up again and again. Deleting CMDB records automatically because a security tool cannot see them, which removes devices that were simply offline. Letting the newest source always win, which overwrites good data with bad. And running reconciliation once as a project, which produces a clean CMDB that drifts again within months. Reconciliation works as a routine, with the same rules applied every cycle.

What does good look like after a quarter?

Fewer records in each of the three patterns, a written rule for which source wins each field, and a CMDB that the security team uses instead of routing around.

What next?

Read CMDB-centred inventory and, if your CMDB is the problem, answer question 03 in the finder with "We have one, but people do not trust it".