Why Your Container Images Matter in a Post-Quantum World

OpenSSL has supported post-quantum cryptographic algorithms since April 2025. But your application may still be unable to use them. The reason could be sitting in your container image: an older version of OpenSSL that your application links against.

This is an important distinction in the transition to post-quantum cryptography (PQC). Updating application code alone will not make software post-quantum ready. The libraries, runtimes and cryptographic dependencies packaged with it matter just as much.

As organizations begin planning their PQC migration, container images deserve a closer look.

The post-quantum transition has already begun

In August 2024, the National Institute of Standards and Technology (NIST) finalized its first three post-quantum cryptography standards:

• FIPS 203 (ML-KEM): A key-encapsulation mechanism for establishing shared encryption keys.
• FIPS 204 (ML-DSA): A digital signature algorithm for authentication and integrity.
• FIPS 205 (SLH-DSA): A stateless, hash-based digital signature algorithm.

These standards provide the foundation for replacing public-key cryptographic algorithms that could be vulnerable to sufficiently powerful quantum computers.

The transition is not based on the assumption that such computers are already capable of breaking today's encryption. It is about preparing before that capability arrives, particularly because of the harvest-now, decrypt-later risk: attackers can collect encrypted information today and attempt to decrypt it in the future.

NIST's final NIST IR 8547, published on October 27, 2026, sets out its transition approach. It plans to deprecate quantum-vulnerable public-key algorithms after 2030 and disallow their use under its standards and guidelines after 2035.

Separate federal requirements under Executive Order 14412 and OMB Memorandum M-26-15 set earlier deadlines for high-value federal assets and high-impact systems: post-quantum key establishment by December 31, 2030, and post-quantum digital signatures by December 31, 2031. These are federal requirements, not blanket deadlines for every private-sector organization.

For technology providers and their customers, however, the direction is clear: cryptographic migration needs to be planned well ahead of the transition deadlines.

Your application is only as ready as its cryptographic dependencies

Consider OpenSSL.

On April 8, 2025, OpenSSL 3.5 introduced support for ML-KEM, ML-DSA and SLH-DSA. It also expanded TLS key-establishment capabilities, including support for hybrid approaches.

But having an application that supports OpenSSL does not automatically mean it can use these newer algorithms. The version available in its runtime environment matters.

Consider two Debian-based container environments:

There is an important nuance here. Debian 12's regular security support ended in June 2026, and the Debian LTS team took over security maintenance. Bookworm LTS continues until June 2028.

That means Bookworm can continue receiving security fixes while retaining its OpenSSL 3.0.x baseline. LTS security maintenance does not, by itself, bring in the new PQC capabilities introduced in OpenSSL 3.5.

Security maintenance and PQC capability are not the same thing.

The same dependency challenge applies across the software stack:

Java provides another useful example. JDK 24 introduced implementations of ML-KEM and ML-DSA. However, application support still depends on the runtime version, provider configuration and how cryptographic operations are implemented. See the JDK 24 release notes.

SBOMs tell you what is present. CBOMs help reveal the cryptography.

A Software Bill of Materials (SBOM) provides an inventory of software components, packages and dependencies. It helps organizations understand what is included in an application or container image. 

But knowing that an image contains OpenSSL does not necessarily tell you which cryptographic algorithms are implemented, configured or actually used.

That is where a Cryptographic Bill of Materials (CBOM) becomes relevant.

CBOM provides a structured inventory of cryptographic assets, including algorithms, certificates, protocols and related cryptographic material. CycloneDX introduced CBOM support in version 1.6, released in April 2024.

The distinction matters:

• SBOM: What software components and dependencies are present?
• CBOM: What cryptographic assets and capabilities can be identified within the environment?

Together, SBOM and CBOM provide a stronger foundation for cryptographic discovery and migration planning. However, inventories alone cannot confirm which algorithms an application actually uses at runtime. Configuration and runtime analysis are still necessary to build a complete picture.

Software signing needs a post-quantum transition too

Encryption is only one part of the challenge.

Container security also depends on digital signatures. Organizations use signatures to verify the origin and integrity of container images, packages and other software artifacts.

Today, many software supply chain workflows rely on classical public-key algorithms such as ECDSA. These algorithms are among those that will need to transition to quantum-resistant alternatives.

NIST's ML-DSA and SLH-DSA standards provide post-quantum digital signature options. Adopting them requires changes across signing tools, verification systems, certificate infrastructure and transparency services. Larger signature sizes and compatibility requirements also mean that migration involves more than changing an algorithm in a command.

Sigstore's October 2026 PQC migration roadmap illustrates the scale of this work. The project is planning a separate post-quantum infrastructure, with a production-ready public instance targeted for mid-2027. Its roadmap also describes a transition toward ML-DSA-based signing and verification.

For container images, this is particularly important because signatures and provenance records may need to remain verifiable long after the original artifact was built and released.

What should organizations do now?

PQC migration does not need to happen all at once. It needs to begin with visibility and a plan.

Here are five practical steps:

1. Inventory your container images. Identify the base images, operating system packages, cryptographic libraries and runtimes used across your environments.
2. Assess cryptographic exposure. Identify where quantum-vulnerable algorithms are implemented or configured, including encryption, key exchange and digital signatures.
3. Evaluate dependency readiness. Check whether the OpenSSL, Java and other cryptographic components in your images support the algorithms and protocols your applications will need.
4. Build cryptographic agility. Avoid hard dependencies on a single algorithm or provider. Plan for updates to libraries, protocols, certificates and signing systems without requiring major application redesigns.
5. Strengthen software supply chain visibility. Maintain accurate SBOMs, explore CBOM adoption, and preserve verifiable build provenance and artifact integrity.

The post-quantum transition starts with the software foundations

PQC readiness depends on more than adopting new algorithms. Organizations need visibility into the cryptographic capabilities embedded across their software stack, from application dependencies to container images and signing infrastructure.

The post-quantum era will require software foundations that can evolve, and a supply chain whose integrity can be verified.

Explore Clean Images from CleanStart to build on verified, hardened container foundations.