To understand Red Hat OpenShift’s journey to quantum-safe cryptography, it helps to look at the current and planned post-quantum cryptography support in Red Hat Enterprise Linux (RHEL). This is because OpenShift includes Red Hat Enterprise Linux CoreOS (RHCOS), which provides several important cryptographic libraries. Bringing post-quantum cryptography to OpenShift is not a one-line configuration, of course. It’s an architectural transition.
There are three main areas of focus when considering post-quantum cryptography for OpenShift:
RHCOS kernelsOpenShift Core userspaceGo versions used by the Kubernetes components upon which OpenShift is based
For an overview of post-quantum cryptography support in RHEL 10, read the Post-quantum cryptography in Red Hat Enterprise Linux 10 article.
RHEL 10 and the beginning of quantum-safe integration
RHEL 10 introduces TEST-PQ mode, a crypto policy profile designed for early adoption and testing of post-quantum cryptography algorithms. These implementations offer developers and security teams a platform to validate PQC algorithm compatibility and performance. In subsequent versions of RHEL 10, we expect quantum-safe support to be part of the default security profile.
The lattice-based key encapsulation mechanism ML-KEM is supported in RHEL 10 for key exchange across several crypto libraries, including OpenSSL, GnuTLS, NSS, and OpenSSH. This enables post-quantum cryptography-capable key exchange for transport layer security (TLS) connections, SSH sessions, and application-layer cryptography in compatible services.
RHEL 10 also introduces preliminary support for ML-DSA, the digital signature scheme. Initially, RHEL 10 supports only pure ML-DSA, available in OpenSSL 3.2 (a tech preview based on the draft-ietf-lamps-dilithium-certificates-07 specification, which is still a work in progress and subject to change). RHEL 10 does not yet include support for SLH-DSA (a hash-based alternative) or composite or hybrid signatures (such as ML-DSA + RSA). However, expect broader signature support (including SLH-DSA) to be available with RHEL 10.1 or later, pending finalization of standards and readiness.
Digital signatures in TLS require support for PQC-based X.509 certificates. However, the relevant standards are still in progress, specifically draft-ietf-lamps-dilithium-certificates and draft-ietf-lamps-pq-composite-sigs. RHEL 10 offers experimental OpenSSL integration of these draft mechanisms, but production-ready certificate chain support does not yet exist. Finalized support for TLS authentication with PQC signatures is tentatively targeted for Q4 2025, pending stabilization of the RFC and validation of the cryptographic module.
NSS is shared with Firefox, so Red Hat rebases it frequently because the Mozilla Foundation requires an up-to-date NSS version.
RHEL 10 includes support for ML-KEM (512-bit and 768-bit, but not 1024-bit yet)ML-KEM-1024 support in RHEL 10 is expected by Summer 2025ML-DSA support in NSS is under active development, expected in RHEL 10.1+
Regarding RHEL 9, preliminary quantum-safe support arrives in version RHEL 9.7. Red Hat will deliver this support by backporting OpenSSL 3.5 and NSS. With RHEL 9.7, planned for later this year, you can expect support for partial ML-DSA and, in tech preview, SLH-DSA.
Transport layer security 1.3 (TLS)
Supporting post-quantum cryptography with transport layer security requires using TLS 1.3 standards. All PQC key exchange mechanisms are designed to operate only within TLS 1.3. TLS 1.2 does not support the necessary handshake extensions to negotiate quantum-safe algorithms. As such, enabling and enforcing TLS 1.3 across OpenShift is the first critical step.
OpenShift uses the Intermediate TLS security profile by default. Administrators must explicitly configure OpenShift to use the Modern TLS security profile, which requires TLS 1.3 at minimum. Once quantum-safe algorithms are available, it will be possible to create a custom TLS profile that disables legacy algorithms entirely.
For more detail, read the TLS configuration in OpenShift article and also refer to the official documentation. These articles describe how you can define TLS level and custom profiles for the control plane, the ingress controller, and the kubelet (when it acts as an HTTP server for the Kubernetes API server.)
Both the kubelet and the ingress controller can leverage TLS 1.3 on all supported OpenShift versions. The control plane will support TLS 1.3 as of OpenShift 4.19, expected summer 2025. Once TLS 1.3 is in place, other components can begin to layer in post-quantum cryptography capabilities, but many of these require deep integration with the platform.
OpenShift and post-quantum cryptography support
OpenShift nodes use RHEL CoreOS, both for kernels and user space. As such, OpenShift inherits quantum-safe capabilities when it starts consuming quantum-safe capable RHEL code.
Another key aspect is the programming language Go. Each upstream Kubernetes version uses a specific version of Go to build its components, and many OpenShift components rely on Go cryptography.
Red Hat Enterprise Linux CoreOS
RHCOS is a minimal, container-optimized operating system based on RHEL. Post-quantum cryptography support depends on the availability of crypto libraries and kernel-level tooling that can support newer algorithms.
Some RHCOS versions are based on RHEL 9.6, which does not ship with post-quantum cryptography-enabled OpenSSL or GnuTLSFuture RHCOS builds, based on RHEL 9.8 or 10.x, will inherit post-quantum cryptography capabilities as OpenSSL 3.5 and other libraries mature
Even if user-space containers support post-quantum cryptography, the underlying node operating system must be upgraded to ensure platform-wide compatibility for actions leveraging kernel calls, such as IPsec.
OpenShift user space (core pods and containers)
Most OpenShift core components run inside containers based on RHEL 9.x Universal Base Image (UBI) builds. These container images inherit cryptographic libraries (such as OpenSSL and NSS) from the base operating system.
OpenShift 4.20 will still consume RHEL 9.6-based containers, which lack full PQC support. Only traditional TLS key exchange mechanisms (ECDHE and RSA) are available in this version.
Even if the platform is not post-quantum cryptography-capable, UBI 9.7, UBI 10, and UBI 10.1 will introduce PQC-capable OpenSSL (3.2, then 3.5), with support for ML-KEM for key exchange, ML-DSA (Tech Preview, pending RFCs), and SLH-DSA. Layered applications and workloads that adopt these new UBI images can begin using PQC, assuming other dependencies are in place.
Because OpenShift is based only on EUS releases of RHEL, we must wait until RHEL 9.8 and 10.2 releases (planned for Spring 2026) to get quantum-safe support in core OpenShift components.
But one piece of the puzzle is still missing.
Go is a critical dependency
Many OpenShift components are written in Go. There is a tight integration between Go versions and Kubernetes upstream versions, as well as OpenShift versions. For example, Kubernetes 1.32 is based on Golang 1.23, and this translates into OpenShift 4.19 . Upstream, Kubernetes 1.33 moved to Go 1.24. OpenShift 4.20 will be based on Kubernetes 1.33 and Go 1.24.
OpenShift also relies on using Go’s crypto/x509 package, not only on Red Hat-provided cryptography. This means we also need proper quantum-safe support there. Go 1.23 provides no post-quantum cryptography support at all.
Go 1.24 introduced limited post-quantum cryptography support, specifically X25519 + ML-KEM-768 for hybrid key exchange. However, digital signature algorithms like ML-DSA are not yet supported in crypto/x509. The road to Go 1.25 is unclear. As of the time of writing, it is still unknown whether digital signatures will be supported or if they’ll have to wait until Go 1.26, which is expected to gradually introduce support for PQC-based X.509 certificates and hybrid and composite signatures.
The dependency on Go cryptography affects components that generate certificates, such as cert-manager, Red Hat OpenShift Service Mesh, and Red Hat Advanced Cluster Security, all of which are built in Go and operate their own certificate authorities.
Federal Information Processing Standards 140 and PQC are still incompatible
RHEL’s Federal Information Processing Standards (FIPS)-certified crypto modules do not support post-quantum cryptography. It is not yet clear when NIST will begin defining quantum-safe FIPS requirements.
In the meantime, the same FIPS provider module used in RHEL 9.4, 9.5, and 9.6 will be present in RHEL 10.0. But at the moment, customers must choose: FIPS 140 support or enabling quantum-safe algorithms. It’s not possible to have both, for now.
Mitigations in 2025: ML-KEM with Service Mesh/Ingress
You don’t need full quantum-safe support to start a quantum-safe journey. The first risk to mitigate is the “harvest now, decrypt later” scenario, where bad actors steal key exchanges now that could be broken by quantum computers later, revealing the content of the shared secrets, along with the content of the stored traffic. Using ML-KEM for key exchange in layered applications is possible with Go 1.24 and later.
Red Hat is exploring ways to bring quantum-safe aspects to OpenShift in 2025, to the ingress controller, Service Mesh, or by using frontend proxies with a quantum-safe TLS key exchange. More on this in a subsequent blog article.
You must also consider your use of cryptography, not only in the components you develop, but in all the external dependencies you pull in when building. Any cryptographic function will have to support a quantum-safe algorithm in the future. Now is the time to create a clear inventory. At Red Hat, we are conducting an inventory of cryptographic components used across our portfolio.
Conclusion
To summarize the requirements and timing for complete quantum-safe support (both ML-KEM and ML-DSA) in Red Hat OpenShift:
Kernel versions: RHEL kernel versions 9.8 or 10.2 are required.RHCOS and user space: RHCOS needs a user space built upon RHEL or UBI version 9.7 or 10.1 and higher.Go language version: Adopting Go version 1.26 is highly probable, although Go version 1.25 remains a possibility.
To achieve quantum-safe capabilities, those components must align. Considering the typical release cycles of RHEL, OpenShift, and the Go language, aligning all these components for full quantum-safe support is expected around OpenShift version 4.22.
However, quantum-safe support for application data in motion will be available with OpenShift Service Mesh sooner.
This timeline is a best-estimate projection, not a formal commitment.
Quantum-safe cryptography is becoming a cornerstone of modern infrastructure security. Red Hat is committed to helping you navigate this transition by:
Integrating NIST-backed PQC algorithms into RHEL and OpenShiftEnabling forward-compatible crypto libraries and profilesEnsuring open source projects remain interoperable and auditable
The time to act is now, not when the first cryptographically relevant quantum computer (CRQC) arrives. Explore Red Hat’s TEST-PQ profiles, experiment with TLS 1.3 across OpenShift clusters and secure key encapsulation when you can.
