Security Requirements for Selecting a CMDB and IT Asset Management Tool: A Buyer’s Guide to Criteria and Testing

A CMDB or IT asset management tool is chosen to answer "what do we have", but to do that it collects privileged credentials for every network, a live map of every crown jewel and a feed that patching, incident response and audit all trust. A tool that discovers well but stores domain-wide credentials badly, or lets anyone edit the records that scope your vulnerability scans, adds risk rather than removing it. This vendor-neutral buyer's guide sets out the security requirements for selecting a CMDB, ITAM or software asset management tool: what to put in the RFP, how to weight it, what to ask vendors and how to test the answers. It is for security architects, asset and configuration managers and procurement leads. For inventory cadence, data quality and programme design, see the Asset Inventory and CMDB Security Guide; this page covers only the choice of tool.

Key takeaways

• Discovery credentials decide the risk. Ask first how the tool authenticates to hosts, network devices and clouds, and whether it can work with scoped, vaulted, rotated accounts instead of domain or root credentials.
• The record must be trustworthy, not just complete. Require attribute-level source tracking, reconciliation rules and an audit history of every change, because security decisions are made from the CMDB.
• Treat the CMDB as sensitive data. A full export is an attacker's reconnaissance report; require record-level access control and audited exports.
• Identities and software are assets too. A tool that cannot hold service accounts, certificates, cloud resources and software components will leave security working from spreadsheets.
• Test in a hostile PoC. Run discovery with least-privilege accounts, tamper with a record, revoke a connector and export the audit trail before committing.

Define requirements

Agree the security use cases with IT operations and finance before vendor demonstrations, so the tool is not chosen on licence reporting alone.

• Security consumers: which processes will read the inventory? Typical answers are vulnerability scan scoping, patch compliance, incident response asset lookup, attack surface reconciliation and audit evidence for CIS Controls 1 and 2 or NIST SP 800-53 CM-8.
• Asset scope: endpoints, servers, network and OT devices, cloud accounts and resources, containers, SaaS applications, software and licences, certificates, and non-human identities such as service accounts and API keys.
• Discovery model: agent-based, agentless (credentialed scans), passive network sensors, cloud API connectors, or imports from endpoint management and EDR. Most estates need several; each brings its own credential requirement.
• Network reach: segmented networks and OT zones need collectors placed inside them; define which zones may initiate connections to the collector and which may not.
• Write-back: will the tool only read, or also act (deploy software, run scripts, change configuration)? Write-back turns it into a software deployment tool with a much higher privilege profile.
• Hosting: SaaS, self-hosted or hybrid, residency needs, and whether discovery data may leave segmented networks.

Small organisations can usually rely on endpoint management and cloud APIs for discovery and should prioritise SSO, access control and a clean export. Large or regulated organisations should add collector hardening, credential vault integration, attribute-level provenance and customer-managed keys.

Capability areas

Discovery credentials and collectors

• Vault integration: discovery credentials retrieved at run time from your secrets manager or PAM vault, not stored in the tool, or at minimum encrypted with keys you control and never displayed back to administrators.
• Least privilege per protocol: documented minimum rights for Windows (WinRM over HTTPS or WMI without domain administrator), Linux and Unix (SSH key-based accounts with constrained sudo), network devices (SNMPv3 with authentication and privacy rather than v1 or v2c community strings) and databases.
• Credential scoping: separate credentials per network zone or business unit, so one stolen credential does not unlock the whole estate.
• Cloud connectors: read-only roles assumed through federation rather than long-lived access keys. For AWS cross-account access, the vendor should supply a unique external ID per customer for the role trust policy, the control AWS documents against the confused deputy problem.
• Collectors: a hardened, supported appliance or image, outbound-only connections to SaaS where possible, signed updates and a documented list of ports and protocols.

Agents and write-back

• Signed agents with tamper protection, least-privilege service accounts where the platform allows, and an update channel that verifies signatures.
• If the tool can run scripts or deploy software, separate roles for inventory and for execution, approval for execution jobs and full logs. ATT&CK T1072 (Software Deployment Tools) describes adversaries using exactly this kind of central tool to execute across an estate.

Data integrity and provenance

• Identification and reconciliation rules that merge records from several sources without duplicates, with a defined source precedence per attribute.
• Attribute-level history: which source or person changed a value, when, and the previous value.
• Controls that stop manual edits from overriding discovered values for security-relevant attributes (owner, criticality, internet exposure) without approval.
• Staleness flags for records not seen by any source within a set period.

Access control and data protection

• SSO with MFA and SCIM provisioning, roles separating administration, discovery configuration, record editing and read-only consumers, and record-level restrictions for sensitive segments such as security tooling or OT.
• Audited, rate-limited API access and exports, so a bulk download of the estate is visible.
• Encryption at rest and in transit, with customer-managed keys where needed.

Coverage beyond hardware

• Software inventory with versions, end-of-life dates and the ability to ingest SBOMs in CycloneDX or SPDX format. See the Software Asset Management for Security guide and the SBOM Guide.
• Cloud resources and SaaS applications, including unmanaged accounts discovered from finance or identity provider data.
• Configuration item classes for service accounts, API keys, certificates and AI agents, with owner and relationship to the systems they access.

Integrations

• Bidirectional links to vulnerability scanners, EDR, SIEM, attack surface management and the ITSM platform, each using its own scoped, expiring credential with an inventory of active tokens.

Vendor assurance and resilience

• Independent assurance (SOC 2 Type II, ISO/IEC 27001 with the service in scope, CSA STAR entry), a vulnerability disclosure policy, security advisories for collectors and agents, and an SBOM for on-premises components.
• Backup, point-in-time restore of the CMDB and a full export of records and history on exit.

Evaluation criteria

Weights are illustrative; raise discovery credentials and write-back controls if the tool will reach production servers and network devices.

Discovery methods differ in what they see and what they cost in privilege:

Where identity fits

The asset tool is itself a heavy user of non-human identities: discovery accounts, cloud roles, agent service accounts and integration tokens. It should also be where those identities are recorded, with owner and relationship to the systems they reach. Ask whether service accounts and keys can be modelled as configuration items and reconciled against your identity sources. See the NHI Inventory Reconciliation guide and the NHI Discovery Guide.

Questions to ask vendors

• What are the minimum rights for discovery on Windows, Linux, network devices, databases and each cloud, and which features stop working at those rights?
• Can discovery credentials be fetched at run time from our secrets manager or PAM vault, and are they ever shown back to administrators or written to logs?
• Can we use separate credentials per network zone, and can a collector in one zone be prevented from using another zone's credentials?
• Do cloud connectors use federated read-only roles, and do you issue a unique external ID per customer for AWS cross-account roles?
• Which ports and directions does each collector need, and can it work outbound-only?
• How are agents and collector updates signed and verified, and where do you publish security advisories for them?
• If the tool can run scripts or deploy software, how is that right separated, approved and logged?
• How do you record which source set each attribute, and can we lock security-relevant attributes against manual override?
• Are exports and bulk API reads logged and alertable, and can access to sensitive segments be restricted?
• Can the data model hold service accounts, API keys, certificates and AI agents with ownership and relationships?

Red flags

• Documentation that recommends domain administrator or root for discovery "for best results" with no reduced-privilege option.
• Discovery credentials stored in the tool with no vault option and visible to any administrator.
• Cloud connectors that require long-lived access keys with write permissions.
• No attribute history, so nobody can tell whether a record was discovered or typed in.
• Script execution available to every administrator, with no approval or separate log.
• Collectors that require inbound connections from the internet or from user networks.

Proof of concept

1. Create least-privilege discovery accounts per protocol in a test segment, store them in your vault and run discovery; record what data is missing compared with the vendor's full-rights demonstration.
2. Deploy a collector in a segmented zone, confirm its traffic matches the documented ports and directions, and that it cannot use credentials assigned to another zone.
3. Connect one cloud account with a read-only federated role and external ID; attempt the connection without the external ID and confirm it fails.
4. Edit a security-relevant attribute manually, then confirm reconciliation, approval and history behave as specified.
5. Run a bulk export and a large API query as a read-only user, and confirm both appear in your SIEM.
6. Revoke one integration token and confirm only that integration stops and the event is logged.
7. Import a sample SBOM and a list of service accounts, and check they link to the right configuration items.

Use a test segment and test cloud account so the PoC can be removed cleanly: delete collectors, revoke discovery accounts and roles, and rotate any credential the tool held.

After selection: measures and common failure patterns

Track: the share of discovery credentials held in a vault and rotated to your standard; the number of discovery accounts with domain-wide or root rights (target zero); the proportion of records with a discovered source rather than manual entry; records stale beyond your threshold; and unreviewed bulk exports. The CMDB and asset inventory rollout playbook and CMDB and asset inventory health check cover rollout and periodic review.

• Full rights to make the demo work: the PoC runs with domain administrator and the production deployment never reduces it.
• One credential for every zone: a single discovery account spans production, OT and user networks.
• Collector forgotten: the on-premises collector is not patched or monitored like the privileged system it is.
• Manual overrides win: an owner edits criticality or exposure and scan scope quietly shrinks.
• Read-only that is not: the tool's script or deployment feature is enabled by default and nobody owns it. See If your CMDB and asset inventory is compromised.

Framework mapping

Standards and references

• CIS: Control 1, Inventory and Control of Enterprise Assets
• CIS: Control 2, Inventory and Control of Software Assets
• NIST: SP 1800-5, IT Asset Management
• NIST: SP 800-53 Rev. 5
• CISA: Secure by Demand Guide
• AWS: The Confused Deputy Problem
• NCSC: The Cloud Security Principles
• MITRE ATT&CK: Software Deployment Tools

How NHI Mgmt Group can help

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

Related NHI Mgmt Group resources: Asset Inventory and CMDB Security Guide · Securing the CMDB and asset inventory itself · CMDB and asset inventory integration security guide · Attack Surface Management Buyer's Guide · Security Requirements for Selecting an ITSM and Service Desk Platform