Building the levee: Why Red Hat’s post-quantum strategy is already in production

Have you noticed the recent surge of post-quantum cryptography (PQC) roadmaps and Q-day countdowns? They’re hard to miss. Organizations across the industry are rushing to set PQC deadlines as research increasingly suggests the risk of a cryptographically-relevant quantum computer (CRQC) appearing before the year 2030 is no longer a fringe theory—it’s a real possibility. While the industry makes bets on the exact date the quantum clock will hit zero, Red Hat has taken a different, pragmatic approach by focusing on adoption, integration, and delivery of the tools and software you need so when the wave hits, the levee is already built.

Foundational leadership

Red Hat has been laying the groundwork for the post-quantum transition for years, highlighted by the first practical steps towards PQC shipping in Red Hat Enterprise Linux 10 (RHEL) in May 2025. This included support for ML-KEM, ML-DSA, and SLH-DSA in core libraries like OpenSSL and Network Security Services (NSS). The complexity of enterprise infrastructure requires deliberate, methodical changes. Transitioning the very basis of global trust—the cryptographic core—requires minimal disruption, which can only happen smoothly with years of testing and experience.

Infrastructure is more widespread (and complex) than SaaS

There's plenty of noise buzzing from the fear of Q-day. However, there is a fundamental difference in how we solve it. Software-as-a-Service (SaaS) providers often have a high-velocity path to readiness—they can update their edge servers or browsers almost overnight because their scope is narrow. But Red Hat protects entire ecosystems. When you provide the platform for a global bank or a telecommunications provider, you aren’t just updating a server, you're providing the migration path for thousands of interdependent legacy applications, internal networks, and hardware modules. This is why we’ve said PQC stretches far beyond a simple patch into a multi-year architectural revolution.

Protecting the ecosystem

The global enterprise ecosystem typically takes decades, not days, to move and modernize. To understand the scale of the PQC challenge, ask yourself: how much of your current enterprise is running software that is more than 1 major release behind the latest version? In sectors like banking and government, the answer is often “most of it.” These systems are tightly coupled with sensitive, legacy, or fragile applications where a single overnight update could result in a catastrophic outage.

Red Hat provides tools and software for banks, governments, and manufacturers to protect their entire world, not just their web edge. Updating a legacy database or global internal network is as complicated as a multi-year tri-dimensional chess match, coordinating the operating system, the hardware security modules, the firmware signatures, and the application stack to all move in calculated sequence.

This is why our approach has been different.  We recognize moving to PQC requires managing 2 estates simultaneously: classical cryptography and PQC. While your security team might be ready for PQC to land in your infrastructure yesterday, your app team may still be running Java 8. We’re bridging this gap at the platform level, layering the new math needed to provide protection in a quantum era.

Code, not countdowns

Red Hat has a long-standing commitment to stable cryptographic foundations. We began planning for PQC in Fedora and RHEL years ago–right after the National Institute of Standards and Technology  (NIST) announced the winners for the PQC competition (July 2022). This was long before the number of qubits required to break RSA encryption plummeted from the 20 million once thought necessary to as few as 10,000. While the Q-day timeline has accelerated in the headlines, our engineering timeline remains steady.

Additionally, instead of watching standards develop from the sidelines, we're helping build them. Our teams are deep in the trenches of OpenSSL, NSS, and the Linux kernel, helping integrate ML-KEM (FIPS 203) and ML-DSA (FIPS 204) into the very bedrock of the operating system (OS). With RHEL 10.1, we became the first major distribution to start signing our RPM packages with post-quantum keys (ML-DSA). By providing these signatures, your infrastructure remains verifiable and trusted in a post-quantum world, even as the hardware underneath it begins to shift. 

We continue to show up, participate, and contribute in these communities and others to support open source and critical libraries in this paramount transition. It is our goal to serve as a steady hand in building the foundation of modern cryptography. While the broader industry continues to debate when the quantum threat will arrive, Red Hat is focused on making sure that when it does, your foundation is already reinforced with a lock on the door (TLS) and verifying the delivery (software updates).

The deadline is not a start date

Let’s take a moment to talk about that new timeline that’s pervasive today, dominating the industry conversations. Whether you are targeting 2029 or 2030, that due date is your count down to be ready. It's not a date to get started. For the global enterprise, the long tail of infrastructure means that a transition of this scale can’t happen overnight.  

When we talk to customers about when this transition actually matters, we point to Mosca’s Theorem (a topic we covered in 2022). It is a simple risk equation that helps quantify a very complex reality: x + y > z.

Mosca’s Theorem poses 3 variables to consider:

• Shelf-life (x) How long does your data need to stay secret? For medical records or government secrets this is often 20 to 50 years.
• Migration time (y) How long will it take to update your entire cryptographic stack? Historically, moving from SHA-1 to SHA-2 took an enterprise 5-7 years.
• The threat clock (z) How long until a CRQC arrives? While the industry once pointed to 2035, the consensus today has moved much closer to 2029.

An image demonstrating Mosca’s Theorem as it applies to most organizations' secrets and migration timelines.

The math is unforgiving, if your shelf-life plus your migration time is greater than the threat clock, you are already exposed. Let’s take a regional health care provider managing records of millions of patients. Various regulations (like HIPAA in the US) require medical records to remain confidential for the life of the patient. For pediatric patients, that shelf-life is at least 50 years, through 2076. Healthcare itself is very fragmented, with providers having to update thousands of medical devices running embedded OSs, legacy scanning equipment tightly coupled to specific workstations (i.e. MRIs, CT machines), interconnected insurance billing systems, and cloud-based patient portals. With the testing and validation time required for life-critical systems, a best case migration time can be estimated at 7 years.

It’s currently 2026—the safety window is only 3 years. X (50) + y(7) = 57 > 3. Given this formula, we can theorize that healthcare is at significant risk to "harvest now, decrypt later" attacks. Without Red Hat, they may have to invent the PQC path themselves, likely pushing y to 10+ years. With Red Hat, they leverage a platform (RHEL 10.1) that has already integrated, tested, and enabled PQC by default. This shrinks their migration time from years of invention to months of implementation.

Most organizations will experience a painful moment of clarity, often bordering on panic, when they realize the depth of their cryptographic technical debt or even just the migration time being longer than they were prepared for. From legacy applications with hard-coded cryptographic lengths to networks that lack the abstraction layers needed for crypto-agility, the path forward is particularly thorny. By shipping RHEL 10.1 with PQC enabled and preferred by the default crypto policy, we’re giving you the working tools to begin testing and migrating your most complex systems today, not in 2028. 

This transition is about addressing 2 distinct windows of risk: 

• Harvest now, decrypt later (HNDL): this is a current, passive threat to your confidentiality. Data being intercepted today is being archived by adversaries, waiting for a quantum computer to unlock access to those secrets.
• Quantum forgery: This is a future, active threat to your integrity. On Q-Day, an adversary could forge digital signatures, allowing them to impersonate admins, sign malicious software updates, or manipulate financial transactions not protected with PQC.

Our strategy is to change the math of this equation for you. We cannot change the threat clock, and we cannot change your legal data requirements, but we can shrink your migration time through software upgrades, automation capabilities from Red Hat Ansible Automation Platform and other approaches that are natively integrated in the product. By integrating PQC into the foundation of RHEL, we have done the heavy lifting of upstream integration and testing. We are helping you defend both the data you send today and the trust you’ll need tomorrow by making your migration a matter of configuration, not invention.

In the PQC trenches

Here's a quick recap of how Red Hat has helped move PQC from theory to reality.

Building the foundation of crypto today:

• RHEL 9: We're taking steps to prepare operating systems that are approaching the maintenance phase. In RHEL 9, OpenSSL and NSS both support post-quantum cryptography, and we're working on adding post-quantum support to OpenSSH. We also sign RPMs for RHEL 9.7 and above with PQC keys, but since our customers are expecting stability, these changes are not enabled by default, allowing enterprises to transition when they're ready. RHEL 9’s PQC support will always be limited, but we're making sure that customers that have to stay on older systems for a while are not left out in the rain.
• RHEL 10.1: In this release we enhanced the system’s security stance through our system-wide crypto policy to enable and prefer PQC by default. If your peer supports it, your TLS and SSH connections will automatically use post-quantum key encapsulation. With the addition of RPM signing with PQC keys, we're protecting both the transmission and integrity of the software.
• Red Hat OpenStack Services on OpenShift: We're systematically scanning every OpenStack component delivered with OpenStack Services on OpenShift for quantum-vulnerable cryptography, covering 27 teams and over 90 repositories. This analysis has already identified critical findings in services like Keystone (hardcoded ECDSA token signing), Barbican (RSA/DSA key generation), and cross-component TLS configurations. Work is underway to fix these issues, and we've created a dedicated initiative for post-upgrade PQC migration of existing OpenStack Services on OpenShift deployments, so customers don't need to redeploy to become quantum-safe.

Inheriting from this foundation:

• Red Hat OpenShift 4.20: Introduced PQC support for OpenShift control plane, protecting the internal TLS communication between critical cluster components. This was the first step in making the brain of your clusters quantum-resistant.
• OpenShift 4.21 and Red Hat OpenShift Service Mesh 3.3: Here we've expanded into the application layer. By using ML-KEM integrated with OpenSSL, OpenShift Service Mesh 3.3 now supports the X25519MLKEM768 hybrid algorithm. This allows for quantum-protected mTLS between microservices, protecting horizontal traffic in your clusters.

Integrating these algorithms wasn’t as simple as flipping a switch. Because Red Hat showed up early to the community conversations, before the standards began finalizing, we encountered some pushback. Early on, the industry consensus was often, “It’s too early, the math is too heavy, and the threat is too distant.” But by staying in the trenches of the OpenSSL, NSS, and Sequoia-PGP communities we were able to run product-wide testing that identified critical integration bugs long before they reached our customers.

As we shared in December 2025, we ran a RHEL-wide testing effort that uncovered a number of problems that have since been fixed upstream. This effort involved a comprehensive request for every RHEL engineering team to validate their specific components against the PQC-by-default TLS settings in our core cryptographic libraries. This system-wide integration testing not only hardens the bedrock of the operating system by catching complex integration bugs early, but also makes sure that essential high-priority applications—like Apache httpd and nginx—remain robust and functional in a quantum-protected environment. By proactively mapping dependencies and addressing needed changes for areas like high availability and confidential computing, we've eliminated the invention phase for our customers and replaced it with a stable, documented implementation path.

Protecting the software supply chain

Red Hat began consistent upstream advocacy for PQC in the software supply chain in March of 2025 through our involvement with Sigstore (discussed at OpenSSF Day EU 2025 and DevConf US). Despite initial community pushback, Red Hat remained committed to driving progress and building the necessary engineering infrastructure, rather than waiting for the industry to fully solidify foundational pieces.

The path isn't always linear. In the open source world, major language ecosystems and foundational libraries must balance security urgency with performance and stability. Projects like Sigstore often face a dependency waiting game—they cannot fully adopt PQC without the underlying language libraries finalizing support for new algorithms (ML-DSA). Aligned with the broader industry’s early hesitancy to move, the recent shift to urgency as a result of emerging CRQC research will resolve a critical dependency to the majority of cloud native and security-first projects. This includes Sigstore, which has been working towards cryptoagility and PQC since 2023.  

Rather than waiting for those pieces to settle, we took a proactive stance. Red Hat produced an open source proof-of-concept using Sigstore to sign software with ML-DSA leveraging OpenSSL and Cloudflare's CIRCL, described in Red Hat Research Quarterly and presented at SecurityCon EU, 2026. By showing up early to these communities, we’ve begun the work to address quantum forgery attacks before they materialize, with a runway to continue improving and iterating on these solutions alongside the community. These features are currently being integrated into Red Hat Trusted Artifact Signer with the aim of being released at the beginning of 2027.

The most refreshing shift we’ve seen in the last year is this industry pivot from, “No way is this happening,” to, “We needed this yesterday.” When we discuss the quantum forgery risk in  Mosca’s Theorem, we are talking about the root of trust. Integration of PQC in software supply chain security is essential so the root of trust maintains a fully verifiable chain of custody.  Because Red Hat took the early pushback on your behalf, our customers are now moving into a much smoother, well-tested transition path so the delivery of software is as trusted as the code inside it.

As we’ve shared in other blog posts on this topic, we aren’t stopping or slowing progress. Throughout 2026 and into 2027, Red Hat is expanding PQC readiness into the unified security fabric of our entire portfolio, from cloud-native infrastructure to enterprise automation. Our priority is removing the operational friction of this transition. For OpenShift, this means introducing streamlined configuration paths that simplify deployment for post-quantum-ready clusters, with automated enforcement to follow. Ansible Automation Platform will similarly integrate PQC-enabled components and images, so as you automate your environment, you are protecting it against future threats by default. This transformation extends beyond these individual platforms—we are methodically embedding PQC capabilities across the broader Red Hat ecosystem to provide consistent, end-to-end resilience for every workload.

Beyond implementation, we are prioritizing visibility and verification. We continue to work closely with NIST to deliver certified PQC-FIPS modules, providing our government and regulated industry customers with a verified, compliant path into the post-quantum era.

Open collaboration to the end

The post-quantum transition is far too large for any one company to solve in a silo. A transition of this magnitude can only succeed through open standards and relentless collaborative development. If the standards are fragmented, progress stalls. If we cannot reach a global agreement on implementation, we risk an ecosystem where the very systems meant to protect us cannot communicate with one another. 

We’ve seen this fracturing risk first hand. Without finalized standards like the FIPS 203 and 204 milestones we now have in hand, libraries and packages often deviate, creating a proprietary PQC trap that breaks the interoperability enterprises depend on.

RHEL sits as the base of so much sensitive global data and applications. But, because we’ve done the hard work of upstreaming our fixes into OpenSSL, NSS, and the Linux kernel, customers running the latest version of RHEL are already experiencing the benefit of Red Hat’s readiness. PQC protection is no longer opt-in—it's the very foundation your enterprise stands on.

We joined this conversation not out of obligation, but to provide the maturity and stability that a transition of this scale demands. Our mission has always been to turn complex, emerging technologies into boring, reliable infrastructure that runs the world.

Don’t wait for the tide to rise. Use the levee we’ve been building for years, built with transparency, trust, and the collaborative power of open source.