A configuration item is any asset or service that the organisation chooses to track for operational control, such as a server, application, network device, or cloud resource. In CMDB practice, the value comes from tying each item to ownership, dependencies, and change history so teams can govern impact and accountability.
Expanded Definition
A configuration item, or CI, is any asset, service, or logical component that an organisation intentionally tracks for control, accountability, and change management. In practice, CIs are usually more than inventory entries because they are linked to ownership, dependency relationships, baselines, and approved change records.
In NHI and IAM operations, the concept matters because service accounts, API gateways, workload identities, certificates, and related automation components can behave like infrastructure with security impact, even when they are not treated as “assets” in the traditional sense. That is why CI discipline often overlaps with NIST Cybersecurity Framework 2.0 practices for asset management and change control, and with the broader governance themes covered in Ultimate Guide to NHIs. Definitions vary across vendors when CMDB tooling is involved, but the operational meaning stays consistent: a CI is something whose state, ownership, and dependency profile matter to risk decisions.
The most common misapplication is treating “anything in a cloud account” as a CI without validating ownership, lifecycle, or change authority, which occurs when discovery data is imported without governance rules.
Examples and Use Cases
Implementing CI management rigorously often introduces catalogue and maintenance overhead, requiring organisations to weigh visibility and impact analysis against the cost of keeping records current.
- A production API service is tracked as a CI because its certificate renewal, upstream dependencies, and rollback path affect application availability.
- A service account used by a CI/CD pipeline is recorded as a CI so access changes, secret rotation, and offboarding can be tied to an owner and approval trail.
- A cloud database cluster is managed as a CI because patching, backup policy, and network exposure must be assessed before any change is deployed.
- A federation endpoint or workload identity provider becomes a CI when it is the control point for authentication across multiple services and environments.
- An infrastructure-as-code module is treated as a CI when its version, deployment target, and related runtime components must be reconciled for change impact analysis.
These use cases align with the governance logic in Ultimate Guide to NHIs and with NIST-style asset control expectations. The point is not to catalogue everything, but to identify the items whose drift, dependency changes, or ownership gaps would materially change operational risk.
Why It Matters in NHI Security
Configuration items become security-relevant when they reveal where NHIs live, who controls them, and how a change in one system can cascade into credential exposure or service outage. That visibility matters because NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
Without CI discipline, teams lose the ability to answer basic questions: which workload owns a key, which deployment introduced a new secret path, or which third-party integration depends on a deprecated certificate. That makes incident response slower, change approvals weaker, and privilege reviews incomplete. It also undermines zero trust and continuous verification goals reflected in NIST Cybersecurity Framework 2.0, because trust decisions cannot be grounded in unknown or untracked components.
Organisations typically encounter the consequences only after an outage, credential leak, or failed rollback, at which point configuration item tracking becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM | CI management maps to identifying and tracking assets, software, and dependencies. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Configuration items often include NHIs and their dependent systems that must be inventoried. |
| NIST Zero Trust (SP 800-207) | Zero trust depends on knowing managed components and their change state. |
Track CIs with owners and dependencies so asset inventories stay accurate for risk decisions.
Related resources from NHI Mgmt Group
- Why do configuration checks miss identity risk in SaaS environments?
- What is the difference between SaaS configuration and SaaS governance?
- What is the difference between sensitive environment variables and ordinary configuration values?
- What breaks when hardcoded credentials are left in code or configuration files?
