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.

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.

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, associate those dependencies with application versions, inspect container images, record signing mechanisms and connect artifacts to their source repositories. Those records can then feed a centralized cryptographic inventory rather than creating another manually maintained security spreadsheet.

This approach also fits naturally with DevSecOps practices. DevOps.com’s guidance on integrating security into CI/CD emphasizes automation and embedding security controls throughout the development lifecycle rather than treating security as a final-stage review.

Software provenance provides another useful relationship. SLSA defines provenance as information describing where, when and how software artifacts were produced. SLSA Provenance specification, when combined with cryptographic metadata, this can help organizations trace a vulnerable dependency from a production workload through its container image, build process, dependency tree, and source repository.

The objective is not to expose private keys in build metadata. The inventory should describe the cryptographic dependency and its lifecycle, while actual secret material remains protected by appropriate key management systems.

Containers Can Change the Cryptographic Environment

Containers create another reason to connect cryptographic inventory with software provenance. An application can be rebuilt using a new base image without any change to its own source code. That new image may contain a different operating system cryptographic library, certificate store, TLS implementation or security configuration.

From a DevOps perspective, updating a base image is routine maintenance. From a cryptographic perspective, it can represent a change in the application’s security behavior.

A useful inventory should therefore connect cryptographic components to specific image versions and deployed workloads. If a vulnerable implementation is discovered, engineers should be able to identify which images contain it and which environments are currently running those images.

This is consistent with the broader software supply chain approach in which visibility must extend from source code to the actual artifacts deployed into production.

Kubernetes Makes Dependency Mapping More Important

Kubernetes environments can introduce multiple cryptographic layers into a single application architecture. TLS might terminate at a cloud load balancer, ingress controller, API gateway, service mesh or application process. Certificates may be issued automatically, stored through Kubernetes Secrets, managed by an external secrets platform or backed by a KMS or HSM.

Consider an application using an ingress controller for external TLS and a service mesh for internal mTLS. The application itself may have no direct control over either cryptographic layer, yet both could become relevant during a cryptographic transition.

A useful inventory should capture relationships such as:

Workload → Ingress → TLS Configuration → Certificate → Issuer → Key Management

and, where applicable:

Workload → Service Mesh → mTLS → Certificate → Identity Provider

These relationships are considerably more useful than recording that “Application A uses TLS.”

They allow engineering teams to understand what will actually need to change when cryptographic requirements evolve.

Third Party Cryptography Creates Another Blind Spot

Not every cryptographic dependency is controlled internally. Cloud providers, managed databases, CDN platforms, identity providers, API gateways, container registries and SaaS platforms can all perform cryptographic operations on behalf of customers.

These dependencies may not appear in source code, SBOMs or container images.

NIST’s migration guidance therefore considers cryptographic use across applications, services, systems, devices and data flows rather than limiting discovery to software repositories.

This has direct implications for vendor management. If a critical SaaS platform or cloud service depends on a cryptographic mechanism that eventually needs to change, the customer’s migration schedule may depend on the provider’s roadmap.

A mature inventory should therefore identify not only what cryptography an organization controls, but also what cryptography it consumes from third parties.

This is particularly relevant because third-party involvement is already a major security concern. Verizon’s 2025 DBIR analyzed more than 22,000 incidents and 12,195 confirmed breaches and reported that third-party involvement had doubled to 30%. Verizon 2025 Data Breach Investigations Report The statistic is not a PQC-specific measurement, but it illustrates why organizations should not limit dependency visibility to assets they operate themselves.

Not Every Cryptographic Dependency Has the Same Risk

An inventory becomes useful when it supports prioritization. Simply discovering thousands of cryptographic dependencies does not tell an organization which ones should be addressed first.

A practical prioritization model can consider several factors:

The business impact of poor visibility also deserves consideration. IBM’s 2025 Cost of a Data Breach research reported a global average breach cost of $4.4 million, while the India-specific findings placed the average at INR 220 million.

These figures do not represent the cost of PQC migration itself, but they reinforce the broader engineering principle: organizations need enough visibility to prioritize security investments according to actual exposure and business impact.

The “Harvest Now, Decrypt Later” Problem

Quantum readiness cannot be separated from the lifetime of the information being protected. The “harvest now, decrypt later” scenario describes attackers collecting encrypted information today with the expectation that future capabilities may make that information easier to decrypt.

NIST recommends that organizations begin preparing for post quantum cryptography now and specifically advises technology managers to inventory applications that use encryption and identify systems that will need to transition.

This changes how data should be represented in a cryptographic inventory. Teams need to understand not only which algorithm protects information but also how long that information needs to remain confidential.

A transaction record with a short operational lifetime may have a very different migration priority from confidential research, intellectual property, financial information or other data that remains sensitive for many years. Connecting cryptographic mechanisms with data sensitivity and retention gives organizations a much stronger basis for deciding where PQC migration should begin.

Cryptographic Inventory Is the Foundation of Crypto Agility

Crypto agility is the ability to replace and adapt cryptographic mechanisms without causing unacceptable disruption to applications and infrastructure. NIST’s current crypto agility guidance covers protocols, applications, software, hardware, firmware and infrastructure, emphasizing the need to make cryptographic changes while maintaining security and operational continuity.

But crypto agility is difficult to achieve without inventory.

An organization cannot replace an algorithm efficiently if it does not know where that algorithm is being used. It cannot test a migration properly if it does not know which applications depend on the existing implementation. It cannot coordinate a rollout if ownership and deployment relationships are unknown.

For DevOps teams, this creates a direct relationship between cryptographic inventory and the delivery pipeline:

Discovery → Inventory → Prioritization → Testing → Deployment → Monitoring

The inventory provides the visibility required for every stage that follows.

If replacing a cryptographic mechanism requires manually changing dozens of production systems, the organization has limited crypto agility regardless of how modern its current algorithms are.

Make Cryptographic Inventory Continuous

A one-time cryptographic inventory will quickly become outdated in a DevOps environment. Applications change, containers are rebuilt, dependencies are upgraded, certificates are replaced, infrastructure is recreated and cloud services evolve continuously.

The inventory should therefore be connected to existing engineering processes wherever possible. Dependency analysis, container scanning, certificate discovery, Infrastructure as Code analysis, CI/CD metadata, cloud configuration, KMS and HSM records, application ownership data and CBOM generation can all contribute to a continuously updated view.

Automation should handle as much discovery as possible, but automated results still require engineering context. A scanner can identify that a service uses RSA, for example, but it may not know why the dependency exists, what data it protects, whether it is exposed externally or whether a vendor controls the implementation.

The goal is not to create another manual security task. It is to make cryptographic visibility a natural consequence of the software delivery process.

Quantum Readiness Starts in the Software Supply Chain

The most important lesson for DevOps organizations is that quantum readiness does not begin when a team deploys ML KEM or starts replacing RSA certificates. It begins when the organization develops the ability to discover and understand its existing cryptographic dependencies.

That means looking beyond application code and certificates to the complete software delivery chain: source repositories, third party packages, CI/CD systems, build artifacts, container images, Kubernetes infrastructure, service meshes, cloud platforms, APIs, databases, signing systems and external services.

NIST’s current migration guidance makes this sequence explicit: organizations should perform cryptographic asset discovery and inventory so they understand the extent, location and use of existing cryptography before deciding what needs to be migrated.

The organizations that establish this visibility early will have a much clearer path when cryptographic requirements change. They will know which applications are affected, which teams own them, which dependencies require vendor coordination, which data deserves priority and which changes can be automated through existing deployment processes.

Post quantum migration will eventually involve algorithms, protocols, certificates, libraries and infrastructure. But before those changes can be implemented safely, there is a more fundamental engineering requirement:

Know where your cryptography is.

For DevOps teams, cryptographic inventory is therefore not simply a documentation exercise. It is becoming part of the operational foundation for PQC migration, crypto agility, software supply chain visibility and long-term security resilience.