Why Cryptographic Inventory Is the First Step Toward Quantum Readiness

TL;DR - Key Takeaways - PQC migration starts with discovering where vulnerable cryptography exists-not simply swapping algorithms. - Cryptographic dependencies can hide across source code, libraries, containers, CI/CD, Kubernetes, cloud services and SaaS platforms. - SBOMs help map software components, but CBOMs and cryptographic inventories provide deeper visibility into keys, certificates, protocols and algorithms. - CI/CD pipelines can continuously collect cryptographic metadata and connect it to builds, images and deployed workloads. - A living inventory is essential for crypto agility, migration prioritization and reducing “harvest now, decrypt later” risk. Post-quantum cryptography is often framed as an algorithm replacement exercise. The discussion usually moves quickly toward RSA, elliptic curve cryptography, ML KEM, digital signatures, hybrid key exchange and the question of which algorithms should replace today’s public key systems. For DevOps teams, however, selecting a replacement algorithm is only one part of the problem. The harder task is determining where vulnerable cryptography exists, which applications and infrastructure depend on it, who owns those dependencies, and how difficult each one will be to change. That makes cryptographic inventory one of the most important foundations of quantum readiness. NIST’s current Migration to Post Quantum Cryptography project specifically identifies cryptographic visibility and risk management as a core workstream and recommends building and maintaining a comprehensive cryptographic inventory to guide migration. The inventory covers algorithms, protocols, keys, certificates, applications, services, devices and data flows rather than treating certificates as the entire cryptographic landscape. For DevOps organizations, this distinction is particularly important because cryptography is distributed throughout the software delivery lifecycle. A developer can introduce a cryptographic dependency through a package, a CI pipeline can sign an artifact, a container can inherit a TLS library from its base image, Kubernetes can terminate TLS through an ingress controller, and a cloud service can manage encryption keys through a KMS or HSM. None of these dependencies necessarily appears in a conventional certificate inventory. The first step toward quantum readiness is therefore not deploying a post quantum algorithm. It is establishing enough visibility to understand where cryptography exists and what depends on it. Cryptography Is Already Embedded in the DevOps Lifecycle Modern software delivery creates cryptographic dependencies long before an application reaches production. Git repositories typically use HTTPS or SSH, dependency managers retrieve packages through authenticated connections, CI systems communicate with external services over TLS, artifact repositories rely on certificates and authentication, and signing systems may use public key cryptography to establish software provenance. The runtime environment introduces another layer. Kubernetes clusters can use certificates for control plane communication, ingress controllers can terminate TLS, service meshes can establish encrypted service-to-service connections, APIs can validate signed tokens, databases can encrypt stored information, and cloud platforms can manage encryption keys. A single application can therefore depend on cryptography provided by several infrastructure layers owned by different teams. This is increasingly connected to the broader software supply chain security problem. DevOps.com has covered the growing need for visibility and governance across software supply chains, including the role of SBOMs, policy enforcement and runtime analysis. The scale of modern encrypted infrastructure also illustrates why this visibility cannot be limited to application code. Current SSL/TLS data shows how deeply HTTPS and certificate infrastructure have become embedded in websites, APIs and other Internet-facing services. A source code search for RSA, AES, ECDSA or SHA256 will therefore not reveal the complete picture. Applications frequently inherit cryptographic behavior from frameworks, operating systems, libraries, containers, infrastructure components and managed services. The cryptographic footprint of a production system is better represented as a dependency graph than as a list of algorithms. What Should a Cryptographic Inventory Actually Capture? A useful inventory needs more information than an algorithm name. It should provide enough context for engineers and security teams to determine where a cryptographic dependency exists, what it protects, who controls it and how it can eventually be replaced. | Inventory Element | What to Capture | Why It Matters | |---|---|---| | Algorithms | RSA, ECC, AES, SHA family, PQC algorithms | Identifies cryptographic exposure | | Libraries | OpenSSL, BoringSSL, language libraries and versions | Reveals implementation dependencies | | Protocols | TLS, SSH, VPN, mTLS and application protocols | Shows where cryptography is negotiated | | Certificates | Public key type, issuer, chain and expiration | Maps PKI dependencies | | Keys | Type, owner, lifecycle and location | Supports rotation and migration | | Applications | Services consuming cryptography | Establishes ownership | | Data | Sensitivity, retention and protection requirements | Helps prioritize migration | | Infrastructure | Kubernetes, load balancers, service meshes and gateways | Identifies operational dependencies | | Vendors | Cloud and SaaS cryptographic dependencies | Reveals external migration blockers | NIST’s current FAQ provides a similar scope, describing cryptographic inventories as records of algorithms, protocols, keys, certificates, systems, applications, components and protected data. Importantly, the inventory can describe key metadata without containing the actual key material. The relationships between these elements matter as much as the elements themselves. Knowing that an organization has thousands of RSA certificates does not reveal which applications use them, what services depend on those applications, what data is being protected or whether the underlying systems can support a different cryptographic mechanism. That turns inventory from an asset list into an operational map. Why an SBOM Is Not Enough Software Bills of Materials have become an important component of software supply chain security. An SBOM can identify software components, dependencies, package versions and relationships between application components. This information is valuable for vulnerability management and supply chain risk. Cryptographic visibility requires another level of detail. An application may contain a cryptographic library without directly invoking every algorithm supported by that library. A framework may perform cryptographic operations on behalf of the application. A container may inherit cryptographic packages from its operating system. Infrastructure may terminate TLS before traffic reaches the application. This is where a Cryptography Bill of Materials, or CBOM, becomes useful. CycloneDX’s CBOM capability is designed to represent cryptographic assets and their relationships, including algorithms, keys, certificates and their connections to software components. | Capability | SBOM | Cryptographic Inventory | CBOM | |---|---|---|---| | Software components | Yes | Yes | Yes | | Cryptographic algorithms | Limited | Yes | Yes | | Cryptographic libraries | Yes | Yes | Yes | | Certificates | No | Yes | Yes | | Keys | No | Yes | Yes | | Protocol dependencies | Limited | Yes | Yes | | Cryptographic relationships | Limited | Yes | Yes | | PQC migration planning | Limited | Yes | Yes | These approaches should not be treated as competing systems. An SBOM provides software visibility, while cryptographic inventory and CBOM add visibility into the cryptographic mechanisms embedded within or connected to that software. For organizations preparing for PQC, that additional layer can become critical. Where Cryptographic Dependencies Hide in a DevOps Environment The biggest inventory challenge is discovering cryptography that nobody considers part of the application. A typical DevOps environment can contain cryptographic dependencies across repositories, third-party packages, CI/CD systems, container images, Kubernetes, cloud services and runtime infrastructure. The most important discovery points include: - Source repositories: SSH, HTTPS, signing libraries and application-level cryptography - Third-party dependencies: Cryptographic libraries inherited through frameworks and packages - CI/CD systems: TLS connections, artifact signing and secure credentials - Container images: OpenSSL, operating system cryptographic packages and certificate stores - Kubernetes: Ingress TLS, service mesh encryption, certificates and secrets - Cloud infrastructure: Load balancers, API gateways, managed databases and KMS - Runtime services: TLS, mTLS, API signatures and encrypted storage - Software supply chain: Artifact signing, package verification and provenance - External services: SaaS platforms, identity providers and managed security services This distribution creates a significant DevSecOps visibility problem. DevOps.com has highlighted the broader challenge of closing software understanding gaps across DevSecOps, particularly around SBOMs, traceability and collaboration between engineering and security teams. Cryptographic discovery is effectively another dimension of the same visibility problem. CI/CD Can Become Part of Cryptographic Discovery DevOps pipelines already collect substantial metadata about software. CI systems know which commit produced an artifact, which dependencies were installed, which build environment was used and where the resulting artifact was published. That makes CI/CD a natural place to capture cryptographic information. A pipeline can identify cryptographic libraries in dependency trees, asso