Cryptographic asset inventory is now a governance baseline for agility

At a glance

What this is: This is an analysis of why cryptographic asset inventory has become a foundational control for cryptographic agility, compliance, and quantum-safe readiness.

Why it matters: IAM, NHI, and platform teams need a current view of cryptographic assets because hidden keys and certificates create the same governance blind spots as unmanaged machine identities.

By the numbers:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Keyfactor's guide to building a cryptographic asset inventory across cloud, CI/CD and devices

Context

Cryptographic inventory is the discipline of finding every key, certificate, algorithm, library and trust anchor that matters to an organisation’s security posture. The problem is not that assets do not exist, but that they are spread across cloud services, CI/CD pipelines, devices and legacy systems in ways that manual records cannot keep up with.

For identity and access teams, this is the same structural issue that appears in NHI governance: if you cannot see the asset, you cannot govern its lifecycle, ownership or exposure. The article’s central point is that cryptographic agility depends on an inventory that is continuous, contextual and operational rather than static.

Key questions

Q: How should security teams build a cryptographic inventory across cloud and CI/CD systems?

A: Start with automated discovery, not manual spreadsheets. Security teams should inventory certificates, keys, algorithms, libraries and trust anchors across cloud services, build pipelines and devices, then attach ownership, lifecycle status and risk context. The goal is a continuously updated source of truth that supports remediation, audit evidence and cryptographic agility.

Q: Why do cryptographic inventories matter for post-quantum readiness?

A: Because you cannot migrate what you cannot find. Post-quantum planning depends on knowing where vulnerable algorithms, signatures and trust anchors live, which systems depend on them, and which assets are hardest to replace. Inventory is the first control that turns a vague transition plan into a workable migration sequence.

Q: What do organisations get wrong about cryptographic bill of materials data?

A: A CBOM tells you what software can do, not how it is configured in a specific environment. Organisations get into trouble when they treat component visibility as operational visibility. Real governance requires runtime state, actual usage and ownership, otherwise the inventory cannot support rotation, replacement or compliance decisions.

Q: How can teams prioritise cryptographic remediation without creating chaos?

A: Start with asset criticality, exposure and lifecycle status. Expired certificates, weak algorithms and long-lived device trust anchors should rise to the top first because they create the highest operational and compliance risk. A good inventory turns remediation into a ranked queue rather than an unstructured backlog.

Technical breakdown

Why partial cryptographic inventories fail in cloud estates

Cloud environments constantly create, update and retire cryptographic objects across IaaS, PaaS and managed services. That means certificates and keys are not confined to one control plane, and they often sit inside load balancers, gateways, service meshes and managed databases with their own local stores. A partial inventory misses ownership, lifecycle status and embedded cryptography in third-party services. The result is not just weak visibility. It is a broken basis for deciding what needs rotation, replacement or remediation next.

Practical implication: build automated discovery across every cloud service boundary, not just the assets already under central security management.

CI/CD pipeline inventory and hardcoded secret risk

CI/CD pipelines are a second blind spot because they combine development artefacts, build logic and deployment credentials in one highly dynamic path. Cryptographic libraries may be embedded in binaries, while keys and certificates may appear in build systems, artefact stores or source files. A cryptographic bill of materials helps with component visibility, but it does not show how software is configured in a live environment. That gap matters because runtime exposure is what drives actual risk.

Practical implication: scan build pipelines for embedded cryptographic material and connect findings to runtime configuration, not just source-code components.

Device trust anchors and long-lived cryptography

Devices, firmware and industrial assets create the hardest inventory problem because they often carry long-lived trust anchors and signatures that are expensive to replace. These assets may stay in the field for years, use older cryptographic primitives, and support only limited interoperability. That makes them especially relevant to quantum-readiness planning and to harvest-now, decrypt-later scenarios. The inventory has to capture not only what is present, but what cannot be easily changed.

Practical implication: classify long-lived devices and firmware as priority cryptographic assets and map them into migration planning before algorithm changes become urgent.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cryptographic inventory is the missing control plane for cryptographic governance. The article makes clear that discovery alone is not enough; organisations need a central, continuously updated record that ties each cryptographic object to ownership, usage and risk. Without that, rotation, replacement and audit decisions are made against stale assumptions. The practitioner conclusion is simple: inventory is not documentation, it is operational governance.

Cryptographic sprawl creates identity-like governance failures across cloud, CI/CD and devices. Keys, certificates and trust anchors behave like non-human identities in practice because they need lifecycle control, ownership and revocation. The failure mode is not abstract complexity, but assets living in places no team can consistently see or update. The practitioner conclusion is that machine identity governance and cryptographic governance now overlap materially.

Runtime configuration is the real boundary of cryptographic risk. A cryptographic bill of materials can show what software is capable of, but it cannot prove what is actually enabled, trusted or deployed in a specific environment. That distinction matters for compliance and for migration planning because exposure is shaped by live configuration, not catalogue entries. The practitioner conclusion is to treat runtime state as the authoritative source of risk.

Cryptographic agility depends on being able to answer where, who and what first. The article’s strongest contribution is the reminder that algorithm changes, certificate rotation and quantum-safe transition planning all depend on asset visibility before they depend on remediation tooling. In other words, agility is a consequence of inventory quality. The practitioner conclusion is to make discovery completeness a board-level control objective, not a technical cleanup task.

Trust anchors in devices make inventory a lifecycle problem, not a scanning problem. Once cryptography is embedded in firmware or long-lived devices, the issue becomes ownership, replacement timing and migration feasibility. That is why a named concept matters here: cryptographic visibility debt is the accumulation of unmanaged keys, certificates and embedded trust that delays every later decision. The practitioner conclusion is to reduce that debt before it blocks quantum-safe and compliance programmes.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to the State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• For the broader remediation pattern, see NHI Lifecycle Management Guide for how inventory data should feed rotation, renewal and offboarding decisions.

What this signals

Cryptographic visibility debt: organisations are now carrying hidden keys, certificates and trust anchors in the same way they carry unmanaged machine identities, and that debt compounds every time a cloud service, build pipeline or device is added without lifecycle control. The practical response is to treat inventory completeness as a governance metric, not a technical nice-to-have.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, per the State of Secrets Sprawl 2026, the broader lesson is that discovery must extend into the software supply path, not stop at production systems. Teams should prepare for inventory programmes to merge with secrets management, build assurance and device lifecycle oversight.

For practitioner programmes, the next step is to connect cryptographic inventory to standards-led governance. The NIST Cybersecurity Framework 2.0 remains the clearest way to translate discovery into repeatable identify, protect and recover actions across cloud, CI/CD and device estates.

For practitioners

• Automate discovery across every cryptographic domain Map certificates, keys, algorithms, libraries and trust anchors across cloud services, CI/CD systems and devices. Include unmanaged network certificates, embedded keys and external KMS deployments so inventory does not stop at the assets already centralised. Use a single authoritative repository for decision-making, with ownership and lifecycle status attached to each record.
• Extend inventory into CI/CD build paths Scan build pipelines for certificates, keys and secrets used during compilation, packaging and deployment. Add binary and artefact inspection so embedded cryptographic material is visible even when it never appears in source repositories. This closes the gap between component visibility and runtime configuration.
• Classify long-lived devices as migration-critical Tag firmware, IoT, OT and edge assets that contain persistent trust anchors or long-lived signatures. Tie each asset to an owner, update path and replacement feasibility so quantum-safe planning starts with the hardest-to-change systems rather than the newest ones.
• Link inventory findings to remediation priorities Rank expired, weak or non-compliant cryptographic objects by asset criticality and exposure. Use the inventory to drive certificate renewal, key rotation, algorithm replacement and audit evidence generation from the same record instead of separate spreadsheets.

Key takeaways

• Cryptographic inventory is the control that makes cryptographic agility possible, because lifecycle decisions fail when asset visibility is incomplete.
• Cloud services, CI/CD pipelines and long-lived devices all hide cryptographic objects in different ways, so a partial inventory leaves the highest-risk assets outside governance.
• Teams should connect discovery to ownership, runtime configuration and remediation priorities so the inventory becomes an operating system for rotation, replacement and audit readiness.

Key terms

• Cryptographic Inventory: A cryptographic inventory is a continuously updated record of keys, certificates, algorithms, libraries and trust anchors across an organisation. It is not a spreadsheet or one-time audit output. In practice, it links each asset to ownership, usage, lifecycle state and risk so teams can make remediation decisions.
• Cryptographic Agility: Cryptographic agility is the ability to replace algorithms, certificates, keys and protocols without major operational disruption. It depends on knowing where cryptography lives, how it is configured and which systems depend on it. Without inventory and lifecycle control, agility is a claim, not a capability.
• Cryptographic Bill of Materials: A cryptographic bill of materials lists the cryptographic capabilities built into software components, such as supported algorithms and libraries. It is useful for component visibility, but it does not show live configuration, deployment context or actual runtime usage. That makes it a partial input, not the full governance record.
• Trust Anchor: A trust anchor is the root object a system relies on to establish cryptographic trust, such as a root certificate or hardware root of trust. For long-lived devices and firmware, trust anchors can be difficult to change, which makes them especially important in inventory, migration and quantum-safe planning.

Deepen your knowledge

Cryptographic inventory and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme that spans keys, certificates and machine identities, it is worth exploring.

This post draws on content published by Keyfactor: How to build a cryptographic asset inventory across cloud, CI/CD and devices. Read the original.