Red Hat’s Post-Quantum Cryptography Is Already Live in Production
The countdown to Q-day is getting louder. Across the tech industry, organizations are rushing to publish post-quantum cryptography (PQC) roadmaps. Research now suggests a cryptographically-relevant quantum computer (CRQC) could arrive before 2030, and that’s no longer a fringe theory. Red Hat, however, isn’t counting down. Instead, the company has already shipped post-quantum cryptography into production.
Red Hat began building its PQC foundation years before the current wave of urgency. In May 2025, Red Hat Enterprise Linux 10 shipped with support for ML-KEM, ML-DSA, and SLH-DSA in core libraries like OpenSSL and Network Security Services (NSS). These are NIST-standardized algorithms, not experiments.
That head start matters. Enterprise infrastructure is vastly more complex than SaaS. A cloud provider can update its edge servers overnight. Red Hat, by contrast, protects entire ecosystems, banks, governments, telecom providers. For those customers, a single mismanaged update can trigger a catastrophic outage. That’s why Red Hat frames PQC not as a patch, but as a multi-year architectural revolution.
To understand the real urgency, Red Hat points to Mosca’s Theorem: x + y > z. Shelf-life (x) is how long your data must stay secret. Migration time (y) is how long updating your entire cryptographic stack takes. The threat clock (z) is how long until a CRQC arrives. For a healthcare provider managing pediatric records, shelf-life stretches to 50 years. Migration, for fragile, life-critical systems, can take seven years or more. The safety window is shrinking fast.
Red Hat isn’t just shipping algorithms—it’s actively shaping standards. The company’s engineers work deep inside OpenSSL, NSS, and the Linux kernel. With RHEL 10.1, Red Hat became the first major Linux distribution to sign RPM packages with post-quantum keys using ML-DSA. That means the software your infrastructure runs on is already verifiable in a post-quantum world.
The PQC rollout extends across the full Red Hat portfolio. Red Hat OpenShift 4.20 introduced post-quantum cryptography support for the OpenShift control plane. OpenShift 4.21 and Red Hat OpenShift Service Mesh 3.3 expanded that protection to the application layer, using the X25519MLKEM768 hybrid algorithm for quantum-protected mTLS between microservices. Meanwhile, Red Hat is scanning over 90 repositories across 27 OpenStack teams for quantum-vulnerable cryptography.
There are two distinct risks in play. The first is “harvest now, decrypt later”, adversaries are already capturing encrypted data today, waiting for quantum computers to unlock it. The second is quantum forgery, where a future attacker could forge digital signatures, impersonate administrators, or sign malicious software updates. Both threats require action now, not in 2028.
Red Hat’s work on the software supply chain addresses the forgery risk directly. Since March 2025, the company has pushed post-quantum cryptography integration into Sigstore, presented at OpenSSF Day EU 2025 and DevConf US. A proof-of-concept using ML-DSA, OpenSSL, and Cloudflare’s CIRCL is already documented in Red Hat Research Quarterly. These features are being integrated into Red Hat Trusted Artifact Signer, with a target release in early 2027.
Throughout 2026 and into 2027, Red Hat is expanding post-quantum cryptography readiness into Red Hat Ansible Automation Platform and its broader portfolio. The goal is consistent, end-to-end resilience across every workload, not just the web edge.
The industry has shifted from “this is too early” to “we needed this yesterday.” Red Hat was already in the trenches when that shift happened. For enterprises managing legacy systems, that runway is exactly what makes the difference between a smooth transition and a painful reinvention.
