CAASM and Asset Inventory Buyer's Guide

Most organisations already hold asset data in a dozen tools, yet none of them can answer a simple question such as "which internet-facing servers have no EDR agent and no owner?" Cyber asset attack surface management (CAASM) products, and the asset inventory features in wider security platforms, promise one correlated, queryable view built from the tools you already run. They differ greatly in how many sources they connect, how well they merge duplicates, whether they cover identities, cloud and SaaS, and what they let you do with the gaps they find. This vendor-neutral buyer's guide helps security, IT operations and procurement teams define requirements, evaluate products and run a proof of concept against their own data. For inventory design, discovery cadences and CMDB data quality, see the Asset Inventory and CMDB Security Guide; for external discovery tools, see the Attack Surface Management Buyer's Guide.

Key takeaways

CAASM aggregates, it rarely discovers. Most CAASM products pull data through APIs from tools you already own (EDR, MDM, cloud, identity, scanners, CMDB) and correlate it; check what they find on their own.
Correlation quality is the product. Merging the same laptop seen by six tools into one record, without merging two different machines, decides whether the inventory is trusted.
Coverage gaps are the main payoff. The value is in queries such as "managed devices without EDR" or "cloud instances not in the CMDB", turned into owned tickets.
Include identities and SaaS. Human accounts, service accounts, API keys and SaaS applications are assets too; a product that only sees devices misses much of the attack surface.
The connectors are privileged non-human identities. Every API connection needs read-only, least privilege credentials, rotation and monitoring.

What the category does

The NCSC's asset management guidance sets out what a good inventory needs: data from active sources (host agents, network scanning), passive sources (DNS and DHCP logs, traffic captures, authentication logs) and other records (procurement, device management, logging platforms, vulnerability scanners, certificate audits); automatic updates as changes happen; a "last seen" timestamp or confidence score; and regular validation, such as reconciling procurement and cloud billing against the register. CAASM products automate much of this by connecting to many sources and building one correlated record per asset.

Tool type	Primary question it answers	How it gets data	Overlap with CAASM
CAASM	What do we have, across all tools, and where are the control gaps?	API connectors to existing tools, correlation and deduplication	The category itself
CMDB and IT asset management	What is the authorised configuration and who owns it?	Discovery tools, procurement, manual records	CAASM often reads from and writes back to the CMDB
External attack surface management (EASM)	What can the internet see that we own?	Internet scanning, DNS, certificate transparency	Feeds internet-facing assets into CAASM
Vulnerability management	What is vulnerable on the assets we scan?	Credentialed scans and agents	CAASM shows which assets the scanner never reaches
Exposure management and CTEM platforms	Which exposures matter most and are reachable?	Aggregated findings, attack paths, validation	Often include CAASM as their inventory layer
Identity security posture tools	Which accounts and credentials are risky?	Identity provider, directory and cloud IAM APIs	Identity assets may sit in either product

Typical CAASM capabilities include an asset graph across devices, users, software, cloud resources and SaaS; a query language; saved queries that run as policies; dashboards for coverage; and actions such as opening tickets, tagging assets or triggering a SOAR playbook.

When you need it

Inventory requirements you cannot meet: CIS Safeguard 1.1 expects a detailed enterprise asset inventory reviewed at least twice a year, 1.3 an active discovery tool run daily, and 1.5 passive discovery updated at least weekly. See the CIS Control 1 Inventory and Control of Enterprise Assets Guide.
Regulatory cadence: US federal civilian agencies under CISA BOD 23-01 must run automated asset discovery every 7 days across at least their entire IPv4 space and start vulnerability enumeration every 14 days, including roaming devices. Other organisations use these cadences as a benchmark.
Security tool coverage is unknown: you cannot say what share of servers have EDR, logging or backup, or which laptops are missing from MDM.
Mergers, cloud growth or shadow IT: the NCSC warns that unmanaged IT used for business creates unknown risk and needs to be brought into asset processes.
Incident response delays: responders spend hours finding an asset's owner, location and installed controls.

Decision guidance: if you have fewer than a few hundred devices, one cloud and a single endpoint platform, a well-run MDM or endpoint console plus cloud inventory may meet the need. CAASM pays off when you run many overlapping tools, several clouds and SaaS-heavy operations, or when audit and regulators want evidence of coverage. If you are already buying an exposure management platform, check whether its inventory layer is good enough before buying CAASM separately. See the Exposure Management Buyer's Guide.

Define requirements

Source list: list every system that knows about assets: directory and identity provider, EDR, MDM, cloud accounts, virtualisation, network (DHCP, IPAM, NAC, firewalls), vulnerability scanners, CMDB, SaaS management, HR (for owners), certificate managers and secrets managers.
Asset types in scope: devices, servers and virtual machines, cloud resources, containers, SaaS applications, human accounts, non-human identities (service accounts, API keys, OAuth applications, certificates), software and OT or IoT devices.
Questions to answer on day one: write the ten queries you most need, such as "servers without EDR", "accounts with admin rights and no MFA", "cloud instances with public IP addresses and no owner tag".
Ownership: how owners are assigned (from CMDB, cloud tags, HR data) and who fixes gaps.
Write-back: whether the product should update the CMDB, tag assets or open tickets, and with what approval.
Compliance mapping: NIST SP 800-53 CM-8 System Component Inventory and CM-8(3) Automated Unauthorized Component Detection; NIST CSF 2.0 ID.AM-01, ID.AM-02 and ID.AM-08; CIS Controls 1 and 2; ISO/IEC 27001:2022 Annex A 5.9 Inventory of information and other associated assets.
Data handling: where asset data is stored, retention, and who can run bulk queries. The NCSC advises restricting bulk queries and monitoring access, because an inventory is a reconnaissance gift to an attacker.

Where identity fits

Identities are often the largest and least inventoried asset class. Ask whether the product correlates a person's accounts across directory, cloud and SaaS; whether it lists non-human identities such as service accounts, service principals, API keys and OAuth grants with owners and last use; and whether it can flag orphaned identities after leavers. Separately, each connector the product uses is itself a non-human identity with broad read access to your environment. See the Non-Human Identity (NHI) Guide and the NHI Ownership Guide.

Evaluation criteria

Criterion	What good looks like	How to test it
Connector coverage and depth	Native connectors for your actual tools, pulling the fields you need, with documented refresh rates	Map your source list to the connector catalogue and check field depth for your top five sources
Correlation and deduplication	Transparent matching rules (serial number, hardware ID, MAC, hostname, cloud instance ID), adjustable by you, with conflict reporting	Compare the product's device count with a manual reconciliation of a sample
Freshness	Per-source "last seen" and per-asset confidence, with stale assets flagged	Retire a test asset and see how long it takes to drop out or be flagged
Native discovery	Optional network or cloud discovery to find assets no tool knows about	Connect an unknown device in the pilot network
Query and policy engine	Expressive queries across relationships (device, user, software, vulnerability), saved as continuous policies with alerts	Write your ten day-one queries during the trial
Identity and SaaS coverage	Human and non-human identities, SaaS applications and OAuth grants, with owners and last use	Find a service account with no owner and a dormant admin
Actions and integrations	Ticketing with owner assignment, CMDB write-back, SOAR triggers, SIEM enrichment	Create a ticket from a gap query and close it after remediation
Connector security	Read-only scopes by default, support for secrets managers or workload identity, credential rotation and connector audit logs	Review the permissions each connector requests
Access control and privacy	Role-based access, scoped views by business unit, export controls, audit log of queries	Log in as a limited analyst and try a bulk export
Scale and pricing model	Clear pricing basis (assets, identities, connectors) and predictable growth costs	Model cost at your expected asset count in three years

Questions to ask vendors

Which of our listed sources do you connect to natively, which fields do you pull, and how often does each refresh?
Explain exactly how you decide two records are the same asset. Can we see and change the matching rules?
Do you discover anything on your own, or only report what our tools already know?
How do you handle ephemeral assets such as containers and autoscaling instances without inflating counts?
Which identities do you inventory: directory users, cloud IAM roles, service principals, API keys, OAuth applications?
What permissions does each connector need? Can they be read-only, and can credentials come from our secrets manager?
Can policies run continuously and open tickets with the right owner, and can you write back to our CMDB?
How do you show an auditor coverage evidence for CIS Control 1 or CM-8?
Who on your side can see our asset data, where is it stored, and how is bulk export controlled?
What is counted for licensing, and what happens to cost when duplicates are counted before correlation?

Red flags

Asset counts that do not reconcile with any of your sources, with no explanation of the correlation logic.
Connectors that require administrative or write permissions to read inventory.
Long-lived API keys stored in the product with no rotation or secrets manager support.
No identity coverage beyond a directory user list.
Dashboards without saved policies, alerts or ticketing, so gaps are seen but never fixed.
Licensing based on raw records before deduplication.
No per-source freshness data, so you cannot tell whether an asset still exists.

Proof of concept

Prepare a ground truth: pick one business unit or site and reconcile its assets manually from procurement, MDM and cloud billing, as the NCSC suggests for validating an asset register.
Connect sources: connect at least your directory or identity provider, EDR, MDM, one cloud account, the vulnerability scanner and the CMDB, using read-only credentials created for the trial.
Measure correlation: compare the product's asset list with your ground truth; count duplicates, false merges and missing assets.
Run your ten queries: time how long each takes to write and check results by hand for a sample.
Test gap handling: plant known gaps (a device with EDR removed, a cloud instance with no owner tag, a dormant service account) and confirm each is detected and ticketed to the right owner.
Test freshness: decommission a test asset and record when it disappears or is flagged as stale.
Review security: list every connector's permissions, check audit logs of queries and exports, and revoke the trial credentials at the end.
Score: rate each product on correlation accuracy, coverage, query effort, actionability, connector security and cost.

Deployment and integration

Start with the sources that define truth: identity provider, EDR and MDM, cloud accounts and CMDB first; add network, scanner and SaaS sources next.
Agree an authoritative source per attribute: for example owner from the CMDB, operating system from EDR, location from cloud tags, so conflicts resolve the same way every time.
Turn queries into owned policies: every saved query should have an owner, a threshold and a ticket route; otherwise dashboards decay.
Feed downstream tools: enrich SIEM alerts with owner and criticality, scope vulnerability scans from the inventory, and give incident responders read access.
Protect the connectors: store credentials in a secrets manager or use workload identity where supported, rotate them, and alert on unusual connector activity. See the Secrets Management Guide.

Common deployment pitfalls:

Treating the first count as truth: early numbers include duplicates and stale records; tune correlation before reporting coverage to leadership.
Connecting everything at once: twenty connectors on day one produce conflicts nobody can resolve; add sources in waves.
No owner for the platform: without a named product owner, queries go stale and connectors break silently when source APIs change.
Ignoring what is missing: assets no tool knows about stay invisible unless you add native discovery or passive sources.

Measure success with: percentage of assets seen by at least two independent sources, percentage of managed devices with EDR, percentage of assets with a named owner, number of unknown assets found per month and their time to resolution, percentage of non-human identities with an owner, and median age of "last seen" per source. Map the programme to D3FEND D3-AI Asset Inventory and NIST CSF 2.0 ID.AM-08.

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.

Asset Inventory and CAASM Buyers Guide: Requirements, Evaluation Criteria and a Proof of Concept