Organisations get started with key inventory by identifying where cryptographic keys exist, who owns them, what they protect and how they are stored, used, rotated and retired. Start with a complete list of systems, secrets stores and certificates, then reconcile ownership and lifecycle data so exposed or orphaned keys can be found and removed.
Where key inventory starts
The first step is discovery, not tooling perfection. Teams need to find every place keys can live, including KMS instances, HSMs, code repositories, application configs, CI/CD variables, vaults and certificate stores. The goal is to build a trustworthy register of what exists before attempting rotation or cleanup.
A practical inventory also records ownership and purpose. For each key, capture what it protects, which system or service depends on it, where it is used and whether it is active, dormant or already expired. That context is what turns a raw list into an operational control.
Start by treating cryptographic key management as a lifecycle problem, not a one-time audit. Keys that cannot be tied to an owner or a business purpose should be flagged early, because unclear stewardship is usually where stale or orphaned material hides.
What data belongs in the inventory record
At minimum, each entry should identify the key or certificate, its location, owner, intended use, protection strength, rotation date, retirement date and any applications or services that trust it. If a certificate chain or signing key is involved, include the related issuer or dependency so that revocation and replacement are not handled in isolation.
The inventory should also distinguish between directly managed keys and keys embedded in application or automation paths. That matters because the remediation path differs: a managed KMS key may be rotated centrally, while an application-bundled key may require code, config and deployment changes before it can be removed safely.
Good inventory data depends on lifecycle discipline, which is why the NHI lifecycle management guide is useful here. Its emphasis on provisioning, rotation, offboarding and visibility maps directly to the kind of ownership and state tracking that makes key inventory usable in practice.
How to turn inventory into cleanup and control
Once the baseline exists, reconcile it against actual system usage. Look for keys with no named owner, certificates past their intended life, secrets stores containing duplicate material and keys that appear in more than one environment without a clear reason. Those are the entries most likely to create blind spots or future incidents.
Reconciliation should feed a simple operating rule: if the key is still needed, assign ownership, confirm scope and put it on a rotation schedule; if it is not needed, retire it and remove every dependency that still trusts it. The Top 10 NHI Issues page is a useful companion for understanding why orphaned credentials, overprivilege and hidden dependencies tend to persist.
For broader operational context, the Ultimate Guide to NHIs, key challenges and risks section highlights the visibility gaps that inventory programs are designed to close. That is the same failure mode teams are trying to eliminate when they move from ad hoc key lists to continuous reconciliation.
Risk and Threat Considerations
Key inventory becomes a risk control as soon as keys are reused, forgotten or left in places no one monitors. The main exposure is not only theft, but also silent persistence: an exposed key can keep authenticating long after the owning team believes it has been replaced.
Failure mechanism: Weak inventory lets orphaned, duplicated or long-lived keys survive across systems, so rotation, revocation and access review do not reach every dependency. Attackers and insiders benefit from that gap because the credential still works while defenders think it has been retired.
Impact: Compromise can spread from one forgotten key to multiple services, environments or signing flows, which increases blast radius and makes containment slower. In the worst case, a missed certificate or signing key also undermines trust in downstream workloads, not just a single application.
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 addresses the attack surface, NIST SP 800-57 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Key inventory is a core part of key lifecycle and retirement management. |
| Recommendation — Establish inventory, ownership and rotation records for each cryptographic key. | ||
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Key inventory starts with discovering and tracking where key material exists. |
| CIS-5 — Account Management | Ownership and removal of stale key access depend on disciplined access control. | |
| Recommendation — Maintain an authoritative inventory of systems and locations that hold key material. Review who can use each key and remove unnecessary access paths. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Key inventory relies on an asset register for where cryptographic material exists. |
| Recommendation — Record keys, certificates and dependent systems in the asset inventory. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Long-lived keys and certificates are a central inventory and cleanup concern. |
| Recommendation — Find and rotate keys that have exceeded their intended lifetime. | ||
Practitioner Guidance
What to prioritise: Start with high-blast-radius material, such as production signing keys, keys with broad service reach and credentials that appear outside the official secrets platform. Those items create the fastest route from inventory work to risk reduction.
What to verify: Do not trust the inventory until each key has a named owner, a known location and a confirmed last-used or rotation signal. If you cannot prove current use, treat the item as suspicious and validate it before leaving it in place.
Decision rule: If a key has no owner or business purpose, classify it as a removal candidate; if it still serves a live dependency, assign custody and rotation dates before anything else. That prevents inventory from becoming a spreadsheet of unresolved exceptions.
Practitioner takeaway: The real value of key inventory is not counting keys, it is making every key attributable, reviewable and removable before it becomes forgotten infrastructure.