A year ago, I wrote about the road to quantum-safe cryptography in Red Hat OpenShift. At the time, much of that road was forward-looking: TLS 1.3 was not yet the default, Go did not support post-quantum algorithms, and the first NIST post-quantum cryptography (PQC) standards had only just been finalized. A lot has changed. This update covers where we are today, what shipped, what is next, and, critically, why digital signatures (ML-DSA) are the harder half of the quantum-safe migration.

What shipped: ML-KEM is in production

Red Hat OpenShift 4.22 ships ML-KEM (FIPS 203) by default. When a capable client connects to an OpenShift 4.22 cluster using TLS 1.3, the platform negotiates X25519MLKEM768 hybrid key exchange automatically. No configuration required. The "harvest now, decrypt later" threat, where an adversary captures encrypted traffic today for decryption by a future quantum computer, is mitigated at the transport layer.

This happened because 3 things aligned:

• Go 1.24 introduced crypto/mlkem and enabled X25519MLKEM768 hybrid key exchange in crypto/tls
• RHEL 9.8 and 10.2 shipped with OpenSSL 3.5 and updated GnuTLS, bringing ML-KEM to RHEL CoreOS and UBI container images
• TLS 1.3 became available across the full OpenShift control plane as of OpenShift 4.19, including the API server, kubelet, and ingress controller

OpenShift inherits its cryptographic capabilities from the intersection of Go, Red Hat Enterprise Linux (RHEL) CoreOS, and the UBI base images that core pods run on. When those 3 layers gained ML-KEM, OpenShift followed.

For customers who want to verify that their cluster is using post-quantum key exchange ,when your client also supports X25519MLKEM768, openssl s_client -connect <endpoint>:6443 shows X25519MLKEM768 in the key exchange group. The crypto-policy profile DEFAULT on RHEL 10.2+ enables this automatically. On RHEL 9.8+, set the DEFAULT:PQ subpolicy using the update-crypto-policies --set command to enable PQC algorithms.

TLS 1.3: The prerequisite is met

All PQC key exchange and signature mechanisms require TLS 1.3. TLS 1.2 cannot negotiate quantum-safe algorithms, the handshake does not support the necessary extensions. A year ago, the control plane still defaulted to the Intermediate TLS profile (which allows TLS 1.2). Today:

• The API server, kubelet, and ingress controller all support TLS 1.3 on OpenShift 4.19 and later
• OpenShift uses the Intermediate profile by default, which permits TLS 1.3 but does not require it
• Administrators can enforce TLS 1.3 by switching to the Modern profile or creating a custom TLS security profile that disables legacy cipher suites

For post-quantum key exchange (ML-KEM), no profile change is needed: ML-KEM is negotiated automatically when both sides support TLS 1.3. For a TLS 1.3-only posture, set the Modern profile cluster-wide. See the TLS configuration in OpenShift knowledge base article and the official documentation.

ML-DSA: The harder half

ML-KEM was the easier part. It protects TLS connections, one handshake at a time, at the transport layer, invisible to the certificate infrastructure. If one side does not support it, the peers fall back to classical key exchange. Deploying ML-KEM does not require changing a single certificate.

ML-DSA (FIPS 204) poses a deeper migration challenge. ML-DSA replaces the digital signatures that underpin every trust decision in the platform: X.509 certificates, code signing, container image signatures, JWT tokens, SAML assertions, admission webhook certificates, and operator bundle signatures. Signatures are not a transport concern: They are embedded in artifacts, stored on disk, validated across trust boundaries, and chained through certificate hierarchies.

Why is this harder? Because of how certificate chains work.

The certificate chain problem

ML-KEM operates connection-by-connection. 2 peers negotiate a key exchange. If one side does not support ML-KEM, they fall back to classical key exchange. No trust chain is involved.

ML-DSA certificates are not as flexible. An X.509 certificate chain requires every signature in the chain to be verifiable by the relying party. If a CA signs with ML-DSA, every component that validates that certificate must understand ML-DSA, or validation fails. There is no graceful fallback within a single chain: A certificate is either verifiable or it is not.

The practical solution is to run 2 certificate chains in parallel: One classical, one ML-DSA. Servers that support ML-DSA serve ML-DSA certificates to capable clients and classical certificates to everyone else. Nothing breaks, but components still on classical certificates are not quantum-safe. The migration is not a flag day. It is a gradual rollout where each component gains ML-DSA support, receives an ML-DSA certificate, and begins serving it to capable peers.

The challenge is completeness, not breakage. Until every component in the platform supports ML-DSA the quantum-safe posture has gaps. In OpenShift, "every component" means the API server, the kubelet, the ingress controller, every sidecar proxy, every admission webhook, and every operator that validates certificates. Each one must be upgraded, each certificate re-issued. This is an architectural migration, not a configuration change.

Dual certificate stacks: the transition mechanism

The transition to ML-DSA does not require a new certificate format. It requires issuing ML-DSA certificates alongside existing classical ones and serving the right certificate based on the client's capabilities.

Internal PKI

For internal PKI (control plane certificates, service mesh mTLS, operator-managed CAs): OpenShift will manage dual certificate chains: one classical, one pure ML-DSA. TLS servers already know how to select a certificate based on what the client announces in its ClientHello packet. No new protocol mechanisms are needed. When a client signals ML-DSA support, the server presents the ML-DSA certificate. When it does not, the server presents the classical certificate. Over time, as all components gain ML-DSA support, the classical chain is retired.

External certificates

For external certificates (ingress, routes, anything signed by a public CA): public certificate authorities will not issue composite or pure ML-DSA certificates in the traditional X.509 model. The certificate transparency infrastructure that underpins the Web PKI does not scale to ML-DSA signature sizes. Instead, the industry is converging on Merkle Tree Certificates (MTCs): A new certificate format designed specifically for post-quantum TLS authentication, which Google is actively promoting in Chrome. See draft-ietf-plants-merkle-tree-certs for the specification. OpenShift will need to support MTCs for any customer-facing endpoint that relies on publicly trusted certificates.

Composite (hybrid) certificates

Composite certificates (IETF draft-ietf-lamps-pq-composite-sigs) bundle a classical signature and an ML-DSA signature into a single certificate. They are not a transition mechanism. They are a defense-in-depth measure for organizations that want the safety net of a classical signature in case future cryptanalysis weakens ML-DSA. Composite certificates break legacy validators just as pure ML-DSA certificates do. They don't provide backward compatibility. For most deployments, pure ML-DSA certificates served using dual stacks are simpler and sufficient.

What ML-DSA touches in OpenShift

Every component that generates, signs, or validates a certificate or a signed artifact is in scope:

• Control plane certificates: API server serving certs, etcd peer and client certs, kubelet serving and client certs, service account signing keys
• Ingress and route certificates: Default ingress controller certs, custom route certs
• Service mesh mTLS: Istio/Envoy certificate authorities, workload identity certs
• IPsec: IKE authentication certificates for pod-to-pod and node-to-node encryption
• Operator signatures: Operator bundle signatures validated by OLM
• Container image signatures: Sigstore/cosign signatures, verified by policy controllers
• Token signing: JWT tokens for service accounts, OIDC tokens for workload identity federation
• cert-manager and custom CAs: any component that runs its own certificate authority

This list is not exhaustive (I could add OpenSSH, PKCS#11, Network-bound disk encryption, OAuth 2.0, and more). We are conducting an internal audit to catalog the full scope of certificate and signing operations across the platform.

Signature sizes: A practical consideration

ML-DSA signatures are significantly larger than their classical equivalents:

The impact on real-world certificate sizes depends on context. Internal cluster certificates (without certificate transparency timestamps) will be smaller, roughly 5-6 KB for an ML-DSA leaf certificate. Publicly-issued certificates are larger: a typical web certificate contains one public key plus three or four signatures (the CA signature and 2 or 3 signed certificate timestamp signatures). With ML-DSA, a single real-world certificate with CT timestamps can exceed 12 KB. This is one of the reasons the industry is moving toward Merkle Tree Certificates (MTC) for the public Web PKI: MTCs avoid transmitting large signatures during the TLS handshake.

TLS handshakes transmit the full certificate chain, not just the leaf certificate. Intermediate and root CA certificates add their own ML-DSA signatures and public keys to the total handshake size, and OCSP responses (if deployed) contribute additional signatures. The per-handshake overhead is a multiple of the per-certificate increase.

For OpenShift operators, the relevant number is the internal certificate size. In a cluster with thousands of certificates — etcd, kubelet, service mesh mTLS for every pod — the aggregate increase affects TLS handshake performance, certificate rotation timing, and etcd storage. This is not a blocker, but it requires performance validation before production deployment.

The RHEL foundation

OpenShift's quantum-safe capabilities come partly from RHEL. The current state:

• RHEL 9.x: OpenSSL 3.5 and updated NSS are backported to RHEL 9.8, bringing ML-KEM and partial ML-DSA support to the RHEL 9 stream, when enabling the DEFAULT:PQ cryptographic policy. OpenShift versions based on RHEL 9.8 EUS inherit these capabilities.
• RHEL 10.x: RHEL 10.2 ships OpenSSL 3.5 and enables both ML-KEM and ML-DSA in the DEFAULT cryptographic policy: no subpolicy or manual configuration required. Applications linked against OpenSSL on RHEL 10.2 negotiate ML-KEM key exchange and accept ML-DSA signatures by default.
• RHEL provided NSS: Support for ML-KEM (512 and 768-bit) is available in current RHEL versions. ML-KEM-1024 and ML-DSA support in NSS are under active development upstream.
• UBI images: UBI 9.7+ and UBI 10.x introduce PQC-capable OpenSSL. Layered applications and customer workloads built on these base images can use post-quantum key exchange today. On UBI 9.7+, set the cryptographic policy DEFAULT:PQ to enable PQC algorithms.

Go: The critical dependency

Many OpenShift components are written in Go. There is a tight coupling between Go versions, upstream Kubernetes versions, and OpenShift versions. OpenShift's own certificate handling relies on Go's crypto/x509 package, not only on RHEL-provided cryptography.

Go 1.24 (shipping in OpenShift 4.20) introduced crypto/mlkem for hybrid key exchange. No ML-DSA support.

Go 1.24 supports hybrid key exchange only: There is no pure ML-KEM mode in TLS. This is by design. RFC 10024 details post-quantum and traditional hybrid key agreement mechanisms for TLS 1.3, while the pure ML-KEM draft is still in IESG evaluation. Hybrid satisfies EU (BSI, ANSSI) requirements today, but not US (CNSA 2.0), which requires pure ML-KEM as deadlines approach in the 2030–2035 timeframe.

Go 1.27 introduces crypto/mldsa with first-class support for ML-DSA-44, ML-DSA-65, and ML-DSA-87. This includes X.509 certificate support (per RFC 9881), TLS 1.3 signature scheme support, and PKIX/PKCS#8 marshaling. This is the unlock for ML-DSA integration in OpenShift.

Components that generate certificates, such as cert-manager, Red Hat OpenShift Service Mesh, Red Hat Advanced Cluster Security, are all built in Go and operate their own certificate authorities. Once these components consume Go 1.27, they can begin issuing ML-DSA certificates. The migration order matters: the platform's own CA stack must support ML-DSA before any leaf certificate can be re-issued.

FIPS and PQC: It depends on the crypto stack

A year ago, the situation was simple: FIPS 140 and post-quantum cryptography were mutually exclusive. Today, the answer is more nuanced and depends on which cryptographic stack your component uses, and which hybrid key exchange group you negotiate.

The OpenSSL path (current OCP, RHEL 9.8 and 10.2)

The OpenSSL 3.5 cryptographic stack in RHEL 10.1 (and 10.2) ships post-quantum algorithms in its default provider rather than inside the FIPS validated provider. However, when operating in FIPS mode, system libraries allow functional hybrid key exchanges that pair FIPS-approved elliptic curves with PQ key encapsulation (specifically SecP256r1MLKEM768 and SecP384r1MLKEM1024). Under RHEL's 10.1+ standard FIPS policy, these hybrid groups are automatically enabled and prioritized. As a result, OpenSSL-linked components can achieve quantum resistant key exchange in FIPS mode today, though pure (non-hybrid) PQC key exchange and PQ digital signatures remain unavailable in FIPS mode until an updated FIPS provider clears government re-validation.

The Go path: Transition already underway

The second route to post-quantum FIPS doesn't go through OpenSSL at all. The Go language tool chain ships its own FIPS 140-3 validated cryptographic module, which includes ML-KEM inside the validated FIPS boundary itself for pure and hybrid operations.

OpenShift is built largely in Go, and Red Hat is planning to move its Go-based components onto this native module, which should land in a future version of OpenShift, as components are migrated. This brings pure PQC key exchange and (in a future version) PQ signatures (ML-DSA) directly into the certified boundary.

2 takeaways for planning purposes:

• First, during this transition window, a FIPS-enabled cluster's post-quantum posture varies by workload type and cryptographic function. . Evaluating whether a cluster is quantum-ready requires inspecting individual components as Go services may support native/pure PQC, while OpenSSL services rely on hybrid key exchanges. Any compliance attestation must take this into consideration.
• Second, both paths mitigate immediate HNDL risks for key exchange, but they do so differently. OpenSSL-linked services (such as load balancers, sidecars, Java and Python services) can use FIPS-compliant hybrid key exchanges (SecP256r1MLKEM768) with RHEL 10.2 today. The Go path leads for PQ signatures (ML-DSA) and pure PQC primitives. Organizations planning for CNSA 2.0 timelines can deploy hybrid encryption across non-Go workloads immediately, but should expect pure PQC signatures on non-Go workloads to lag until a standalone PQ OpenSSL provider completes certification.

Take away

Do not expect the FIPS and PQC situation to stabilize before 2028, proceed with caution if you need PQC support on FIPS OCP clusters before then.

The regulatory clock: Why this stopped being optional

The debate about when a cryptographically relevant quantum computer (CRQC) arrives does not matter for planning. A few facts to consider:

Data lifetime

Encrypted traffic captured today can be decrypted whenever the capability exists. This is the "harvest now, decrypt later" threat. Any data that must remain confidential into the 2030s is already exposed. No quantum forecast is required — the risk exists the moment the data is recorded. Regulators understood this first.

The deadlines are law

• U.S. Executive Order 14412 (June 2026) gives U.S. federal agencies hard dates: Post-quantum encryption on National Security Systems by December 2030, post-quantum authentication by December 2031. Procurement rules extend these requirements to government contractors on the same timeline. NIST deprecates RSA and ECC after 2030 and disallows them after 2035.
• CNSA 2.0 mandates ML-DSA-87 specifically: ML-DSA-44, ML-DSA-65, HashML-DSA, and SLH-DSA are all excluded for National Security Systems.
• The EU expects telecom, finance, and critical infrastructure fully transitioned by the end of 2030.
• France's ANSSI and Germany's BSI both recommend or require hybrid PQC for high-sensitivity systems in 2026.
• Australia disallows classical algorithms by 2030. Google has committed to completing its own migration by 2029.

These mandates sometimes collide with the current technical capabilities (for example, CNSA requires pure ML-KEM-1024, which is not available yet). The regulation demands a combination the tooling barely delivers. Waiting for the tooling to mature means starting a multi-year migration with the deadline already behind you.

The first step is the same under every jurisdiction: Build a cryptographic inventory. Almost every regulation in the world (such as U.S. Executive Order 14412) mandates a cryptographic bill of materials: Documenting which cryptography exists where.

Can your organizations answer that question today? Start there.

What to do now

You do not need to wait for full ML-DSA support to begin preparing.

Enforce TLS 1.3

Set the Modern TLS profile across your clusters. This ensures ML-KEM key exchange is negotiated automatically and prepares the transport layer for ML-DSA certificates when they become available.

Inventory your cryptography

Not just the certificates OpenShift manages, but the ones your applications generate, the signing keys your CI/CD pipelines use, the JWT tokens your identity providers issue. Any cryptographic operation will need a quantum-safe algorithm eventually. Build the inventory now.

Plan for certificate re-issuance

When ML-DSA certificates become available, every certificate in the platform will need to be re-issued, ML-DSA in parallel to the existing traditional ones during the transition phase, until all components can work with only quantum-safe certificates. Understand your certificate lifecycle: how many certificates exist, how they are rotated, what the blast radius is if rotation fails. If you are using cert-manager, ensure your cert-manager version supports ML-DSA issuance.

What's next for OpenShift

Red Hat is actively working on the ML-DSA migration. The key milestones ahead:

• Certificate audit: Cataloging every certificate, signing operation, and trust validation path in the platform. This determines the scope of the migration.
• Go 1.27 consumption: The first OpenShift release built on Go 1.27 unlocks ML-DSA integration. Coordinate with the upstream Kubernetes Go rebase schedule.
• cert-manager ML-DSA support: cert-manager is the certificate lifecycle manager for OpenShift workloads. If it cannot issue and rotate ML-DSA certificates, the migration stalls.
• Sigstore/cosign ML-DSA support: Container image signing with ML-DSA ensures supply chain integrity against quantum threats.
• Customer migration tooling: Existing clusters need a migration path. Re-issue all certificates, validate the chain, roll back if something breaks.

Conclusion

A year ago, quantum-safe cryptography in OpenShift was a roadmap. Today, ML-KEM is in production and protecting TLS connections against the harvest-now-decrypt-later threat. The transport layer is covered.

The next chapter is ML-DSA, quantum-safe digital signatures. This is architecturally harder than ML-KEM because it touches every certificate, every signed artifact, and every trust decision in the platform. The standards are final (FIPS 204, RFC 9881). The ecosystem is converging (Go 1.27, OpenSSL 3.5, Merkle Tree certificates). The regulatory deadlines are fixed (CNSA 2.0, FIPS CMVP, Australia, EU mandates).

The time to prepare is now. Enforce TLS 1.3. Inventory your cryptography. Test with PQC-enabled profiles. Plan for certificate re-issuance. Red Hat is committed to delivering quantum-safe OpenShift, and to ensuring the transition is practical, not just possible.