A CMDB is a database. ITAM is a business process. Confusing the two leaves you with a configuration record that is neither complete enough to trust nor detailed enough to license from — and five practical ways to fix it.
Understanding the relationship between a CMDB and the discipline of IT Asset Management matters to both. Get it wrong and you end up with a configuration record that is neither complete enough to make decisions from nor detailed enough to license from — and two teams each assuming the other owns the gap.
This post covers four things: what a CMDB is, what it is for, how it differs from ITAM, and how to use ITAM and SAM data to make the CMDB genuinely useful.
The goal of a Configuration Management Database is to create a centralised source of information an organisation can use to run efficient IT Service Management processes.
A CMDB inside a service management platform such as ServiceNow is a database of Configuration Items, or CIs. These are records describing the infrastructure being managed — discovered hardware and software information.
The purpose of a CMDB is to provide information solid enough that the business can make safe decisions on it and support IT Service Management. It should give insight into how assets are configured and how they relate to one another.
That second half — relationships — is the part a CMDB does better than anything else. Which service depends on which database, which database sits on which cluster. That is a genuine capability and nothing here is an argument against it.
Beyond the obvious — a CMDB is a database, ITAM is a business process — the confusion comes from the two appearing to overlap. Purpose is where the difference actually lies.
A CMDB exists to centralise information about infrastructure so that service management processes and decision-making can run on it. It lives inside an ITSM platform.
IT Asset Management is the process of managing and optimising the lifecycle of hardware and software investments, to get value from those assets and protect the business from risk.
So ITAM needs a solid understanding of the infrastructure, because that infrastructure is the set of assets being managed. Does that mean ITAM processes should run off CMDB data?
No. The problem with using a CMDB for IT Asset Management is that CMDBs are not designed to capture the depth and detail required to manage hardware and, particularly, software.
When ITSM tools have network discovery and inventory features, the purpose of those features is to collect high-level data for a CMDB. That is the correct design for what they are for. It means dedicated ITAM and especially Software Asset Management tooling is required alongside the service desk to meet a more demanding need. Without accurate and complete data, organisations carry real financial exposure on software they cannot account for.
The consequence is uncomfortable: the “single source of truth” in the CMDB is neither the only source of information about your infrastructure nor the full truth. It lacks the depth of inventory an enterprise SAM platform collects by default.
ITSM tooling also tends to struggle to discover assets across platforms. Records end up duplicated, and unclear.
ITAM and SAM platforms are built the other way round. They provide visibility of your infrastructure wherever it is, and they automate work like software recognition, which turns raw inventory into something you can make a decision from.
Service desk leaders describe a consistent set of CMDB problems, and they are all downstream of the same cause:
None of those are CMDB design faults. All five are inventory faults, showing up in the CMDB because that is where the inventory lands. Fix them at source and they stop arriving.
The fix is unglamorous: use ITAM and SAM data to populate the Configuration Items in your CMDB.
This works because an enterprise ITAM and SAM platform already maintains a live view of the infrastructure. Multi-platform discovery, inventory and the enrichment of that data are core functions — they have to be, or software licensing cannot be managed at all. The work is already being done. The question is only whether the CMDB benefits from it.
Automated software recognition lets you see precisely what is installed, rather than handling incomplete data that needs manual cleanup before it is worth anything.
In CerteroX the mechanism is a read-only API, with a documented Power BI data source, that the service management platform can pull from on a schedule. The CMDB typically holds a fraction of what CerteroX holds and can be refreshed daily. Service management teams get a CMDB that is current, and the ability to drill into the full detail in CerteroX whenever a question goes deeper than the CI record.
It also means ITAM lifecycle management and Software Asset Management get done properly, in the tool designed for them.
Building and maintaining a CMDB is difficult: data is hard to acquire, results are ambiguous, coverage has gaps, and there is rarely full agreement on what the CMDB is even for.
The tools to solve that already exist in most organisations. Here is what they change.
Unlike service desk tooling, the primary function of ITAM and SAM tools is complete visibility of the infrastructure.
That completeness is not a nicety — it is what controlling software cost and risk depends on, across every platform and environment, whether a device is on the network or out in the field. Exporting from the ITAM and SAM platform to populate CIs is a considerably sturdier arrangement than relying on ITSM inventory alone.
CerteroX ITAM is not built for a single purpose, so it collects far more than a CI record needs. Network discovery sweeps a class-C subnet in under five seconds using NetBIOS, SNMP and ICMP, then probes to work out where an agent can actually be deployed. Ten discovery methods land in one schema — agent, command-line, agentless, standalone, Active Directory, network scan, third-party import, cloud and SaaS connectors, browser monitoring and file metering — and the native agent covers Windows, macOS, Linux, IBM AIX, HP-UX and Oracle Solaris.
When that data is used to populate CIs, only a small subset goes across. The rest is still there, available when you need it.
At a business level that means you do not have to anticipate why you might need a piece of information in order to have it. The answer is already collected.
A core part of Software Asset Management is automating the identification of what discovered software actually is — publisher, product, version, edition, and which commercially licensed product it belongs to. CerteroX resolves installations against the Software Recognition Database, 3.5 million or more normalised titles, so the CI record says “SQL Server 2019 Enterprise” rather than a filename.
That same recognition drives the risk view. The Software Recognition Service attaches release, end-of-support and extended-support dates to recognised titles, so end-of-life and end-of-support tracking becomes a report rather than a research project. Application blacklisting and prohibition rules cover software that should not be present at all, and Governance Policies express the rest as compliance-as-code — BitLocker enabled, Defender running, Azure VM tag hygiene — with a reusable filter builder and JSON export of the policy definitions.
Unsupported software is where most software-driven security exposure starts. Knowing which versions have passed end of support, on which hosts, is the input your security team is usually missing.
Populating the CMDB from an ITAM and SAM platform means the data arriving has already been consolidated and cleansed. That removes the oldest problem in configuration management: reconciling several sources that each report a different version of reality, none of which anyone fully trusts.
ITSM tools are not the best ITAM and SAM platforms, and ITAM and SAM platforms are not ITSM tools. Working out the right direction for information to travel between them solves the CMDB problem without compromising your ability to manage software risk and cost.
Scope matters here too, and it has moved since this argument was first made. A CMDB gap analysis that stops at datacentre and cloud is now incomplete. CerteroX SaaS Management discovers applications through three converging signals — a browser extension, identity provider sync from Entra ID and Okta, and 47 vendor connectors — including the AI tools nobody registered anywhere, classified from catalogue feature tags rather than a static list. CerteroX Cloud Management covers twelve cloud and data platforms. Those assets are real, they cost money, and they are absent from almost every CMDB.
Covering desktop to datacentre, mobile to SaaS, cloud and AI from one platform also reduces the number of disparate toolsets you need in order to know what you own — which was the original point of a CMDB in the first place.
Other posts covering the same ground.
Locking an application down at user level does not make you compliant with a per-device licence. In a Citrix or RDS environment, one user with access can cost you a licence for every device in the organisation.
A third-party summary of a vendor can be wrong, and it stays wrong for as long as people read it. The case for checking a vendor's facts at source — and the current, sourced record for Certero.
An audit is won or lost on the quality of your inventory long before the letter arrives. Six ways data goes wrong, and what it takes to have the answer already in hand.
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.