TL;DR: Cryptographic inventories must now track keys, certificates, algorithms, libraries and trust anchors across cloud, CI/CD pipelines and devices because manual records miss where cryptography actually lives, according to Keyfactor. Without that visibility, organisations cannot rotate, replace or assess cryptographic assets fast enough for compliance or quantum-safe planning.
At a glance
What this is: This guide explains how to build a cryptographic asset inventory across cloud, CI/CD pipelines and devices, with the central finding that partial records miss where cryptography actually lives.
Why it matters: For identity and security teams, cryptographic inventory now underpins certificate lifecycle control, cryptographic agility and post-quantum readiness across machine, workload and device estates.
Context
A cryptographic inventory is the authoritative record of where keys, certificates, algorithms, libraries and trust anchors exist, how they are used and who owns them. The problem is not theory, it is visibility: cryptography is distributed across cloud services, CI/CD pipelines and devices in ways that spreadsheets and point tools rarely capture.
For IAM and NHI programmes, the relevance is direct. Cryptographic assets behave like machine identities when they authenticate systems, sign software or protect workload traffic, so governance depends on knowing their lifecycle, exposure and ownership. The article argues that inventory is now a baseline control for cryptographic agility rather than a documentation exercise.
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 fragmented cryptographic inventories create operational risk?
A: Fragmented inventories hide where cryptographic assets live, who owns them, and which business services depend on them. That creates blind spots for renewal, rotation, and algorithm migration, which in turn increases outage risk and delays remediation. A visible estate is the minimum condition for controlled change.
Q: What are the signs that cryptographic inventory is failing?
A: Common warning signs include expired certificates discovered late, unknown trust anchors, hard-coded or reused keys in pipelines, and assets that cannot be tied to an owner or lifecycle record. If teams learn about cryptographic dependencies only during outages, audits or migration projects, the inventory is not operational enough.
A: Start with the links that carry long-lived sensitive data and high-value administrative traffic, then use hybrid cryptography where classical and post-quantum methods can coexist. This lets teams gain quantum-safe exposure reduction while preserving compatibility. The key is to treat PQC as a staged architecture change, not a single cutover event.
Technical breakdown
Why cryptographic inventory must be continuous in cloud environments
Cloud environments constantly introduce, update and retire cryptographic material across IaaS, PaaS and managed services. Certificates and keys also sit inside load balancers, gateways and service meshes that may not appear in central security consoles. A useful inventory therefore has to be automated, continuously updated and ownership-aware, otherwise the record drifts away from operational reality. The practical problem is not finding one asset, but keeping pace with change across ephemeral infrastructure, multi-account cloud estates and third-party managed services.
Practical implication: treat cloud cryptographic discovery as a living control, not a periodic audit task.
Why CI/CD pipelines are a blind spot for cryptographic assets
CI/CD pipelines carry cryptographic material through builds, tests and deployment steps, which means they often hold keys, certificates and secrets outside the places security teams traditionally scan. The article highlights that cryptographic libraries, embedded binaries, hard-coded keys and reused keys can all hide in the software delivery chain. That creates a governance gap between the built artefact and the runtime environment, especially when pipeline tooling itself stores or transmits credentials. Cryptographic inventory in this context has to include both the artefact and the workflow that produced it.
Practical implication: inventory pipeline-held cryptography and the build artefacts it touches as one governed surface.
How device and firmware cryptography changes the inventory problem
Devices and firmware add long-lived cryptographic dependencies that are harder to replace than cloud assets. Embedded certificates, hardware roots of trust and firmware signatures may persist for years, which makes them especially sensitive when algorithms change or when post-quantum planning begins. The article also notes that long-lived IoT and OT assets may be targets for harvest-now, decrypt-later risk. In governance terms, device cryptography cannot be treated as a static exception because it often becomes the least flexible part of the estate.
Practical implication: map device trust anchors and firmware signatures before you set any migration or replacement timetable.
Threat narrative
Attacker objective: The objective is to exploit invisible cryptographic dependencies before defenders can inventory, rotate or retire them.
- Entry occurs when cryptographic material is introduced into cloud services, CI/CD pipelines or devices without a complete inventory to record it.
- Credential or trust exposure follows when hard-coded keys, reused keys, unmanaged certificates or embedded trust anchors remain undiscovered.
- Impact emerges when teams cannot rotate, replace or deprecate affected cryptography quickly enough to avoid outages, compliance failure or quantum exposure.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Cryptographic inventory is now an access-control problem, not just an asset-management task. If you cannot enumerate where cryptographic trust exists, you cannot govern who or what depends on it. That makes inventory a prerequisite for policy enforcement across machine identities, certificate authorities and runtime trust paths. The practical conclusion is that cryptographic governance starts with discoverability, not with renewal workflows.
Manual records fail because cryptography is distributed across operational planes that do not share a lifecycle model. Cloud services, CI/CD pipelines and devices each produce different kinds of cryptographic persistence, and each hides assets in different places. This is why spreadsheet-based inventory collapses under operational change. The governance implication is that organisations need a single, continuously updated cryptographic source of truth rather than isolated team registers.
Cryptographic agility depends on knowing the exact blast radius of a change before the change is made. Algorithm replacement, certificate rotation and library upgrades all fail when ownership, dependencies and deployment scope are unclear. That is especially true when trust anchors live inside hardware or long-lived firmware. The practitioner takeaway is that agility is an outcome of inventory quality, not a separate programme.
Cryptographic inventory is the missing bridge between NHI governance and quantum-safe planning. Keys, certificates and trust anchors behave like non-human identity artefacts because they authenticate systems and sustain machine-to-machine trust. At the same time, post-quantum transition planning needs a precise map of where those artefacts exist and how long they will remain in service. Organisations should treat cryptographic inventory as the control plane for both present-day machine trust and future cryptographic migration.
The strongest inventory programmes will be risk-ranked, not merely complete. The article is clear that visibility alone is not enough if teams cannot prioritise expired, weak or hard-to-replace assets. That means owners need context on criticality, environment and replacement difficulty, then use that context to sequence remediation. The practical conclusion is to turn inventory into a decision system, not a catalogue.
From our research library:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Ultimate Guide to NHIs — Key Challenges and Risks
What this signals
Cryptographic inventory is becoming the control surface for machine trust. The practical change is that teams can no longer separate cryptographic governance from workload, pipeline and device governance. If keys, certificates and trust anchors are not centrally visible, every later decision about rotation, migration or deprecation starts from partial data.
Inventory quality now determines how quickly an organisation can respond to cryptographic change. That matters because algorithm replacement, certificate expiry and hardware trust anchor refresh all create operational friction when dependencies are unknown. Organisations that want cryptographic agility should treat discovery coverage, ownership quality and lifecycle accuracy as programme metrics.
Cryptographic inventory is also a migration prerequisite for the quantum-safe era. The article’s core message is that you cannot sequence post-quantum change until you know which assets depend on current algorithms and where those dependencies sit. The programme signal is clear: build the map first, then set the migration path.
For practitioners
- Build a continuous cryptographic inventory Track keys, certificates, algorithms, libraries and trust anchors across cloud services, CI/CD pipelines and devices as one living inventory, not as separate team spreadsheets.
- Assign ownership to every cryptographic asset Record a named owner for each certificate, key store, trust anchor and algorithm dependency so remediation and renewal have an accountable team.
- Scan CI/CD for embedded cryptography Include build pipelines, compiled binaries, repository files and automation tokens in discovery so hard-coded or reused keys do not escape governance.
- Map device trust anchors before migration Inventory embedded certificates, firmware signatures and hardware roots of trust on IoT, OT and edge devices before planning algorithm changes or quantum-safe transitions.
- Prioritise risk-ranked remediation Use asset criticality, expiration status, cryptographic strength and replacement difficulty to decide which items to rotate, replace or retire first.
Key takeaways
- Cryptographic inventory is now a governance baseline because missing assets block rotation, replacement and compliance decisions.
- The biggest visibility gaps sit in cloud services, CI/CD pipelines and devices, where cryptographic dependencies are often embedded rather than documented.
- Teams should turn discovery into a continuously updated, risk-ranked control so cryptographic agility and quantum-safe planning are both operationally possible.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | CI/CD and device cryptography often hides secrets outside managed vaults. |
| NHI-07 — Long-Lived Secrets | The article highlights certificates, keys and trust anchors that persist far too long. | |
| Recommendation — Scan pipelines and unmanaged assets for exposed cryptographic material and revoke leaked secrets immediately. Inventory long-lived cryptographic assets and set lifecycle thresholds for rotation or retirement. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Key and certificate lifecycle management sits at the centre of cryptographic inventory. |
| Recommendation — Apply IA-5 to govern issuance, rotation, revocation and replacement of cryptographic authenticators. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Hidden keys and pipeline secrets create a path from credential exposure to downstream misuse. |
| Recommendation — Map exposed cryptographic material to credential access and exfiltration tactics in detection and response. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Asset ownership and access scope are core to governing cryptographic objects. |
| Recommendation — Use PR.AA-05 to enforce ownership and authorization controls over cryptographic assets. | ||
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: The ability to change cryptographic algorithms, key lengths, or trust models without reworking every application. For machine identities, it reduces the risk that long-lived services will fail when standards shift or when post-quantum migration becomes necessary.
- Trust anchor: A trust anchor is the root authority that signs federation metadata and establishes the policies other participants inherit. In practice, it controls who can join, what cryptographic rules apply, and how trust is delegated across an ecosystem. The security posture of the whole federation depends heavily on this layer.
- 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.
Deepen your knowledge
NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.
Published by the NHIMG editorial team on June 4, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org