From if to how: A year of post-quantum reality

For the last 5 years, post-quantum cryptography (PQC) has largely been discussed as a research topic. It was a question of if—if the standards are ratified, if the algorithms perform, if the threat is real.

In 2025, Red Hat changed the conversation. We stopped asking “if” and started defining “how.” This past year, we moved PQC out of the laboratory and into the operating system (OS). It wasn’t just about upgrading libraries, it was about pushing the entire modern software supply chain. We found that while the foundation is ready, the ecosystem has a long way to go.

Here is the story of how we made Red Hat Enterprise Linux (RHEL) quantum-ready, the skeletons we found in the closet along the way, and why 2026 is the year of the bridge for PQC.

The victory: RHEL is the anchor

The primary mission for 2025 was straightforward and simple: Prove that the plumbing works.

We targeted RHEL 10 as our first mover. The goal wasn’t just to include the algorithms, but to make them usable. This culminated in 2025, when our engineering team successfully generated the first fully PQC-signed RPM for RHEL 10.1. 

This wasn’t just a file, it is proof of artifact authenticity in a post-quantum world. It proved that our build systems, our signing servers, and our verification logic could handle the larger key sizes and complex signatures of ML-DSA without breaking. It also demonstrated that RHEL can handle both a classic and PQC signature on a single RPM. 

Additionally, we shipped a new post-quantum crypto-policies module with RHEL 9.7, allowing customers to select PQC algorithms today to test their own applications. You can enable this by running \update-crypto-policies --set DEFAULT:PQ. 

This was only possible with the extensive coordination across a multitude of teams and driven individuals who saw this through to success. We’re proud of not only what we accomplished, but also how our teams and engineers collaborated to achieve this amazing industry first.

The reality check: Apps and hardware are the brake

However, the year wasn’t a straight line to victory. While we proved the OS was ready, we discovered that the broader application layer needed to catch up.

In Q2 and Q3, we hit the supply chain wall. You cannot code your way out of a missing hardware module. Delays in PQC-capable hardware security modules (HSM) forced us to innovate with software-backed signing to keep development moving forward while coordinating with our HSM supplier in parallel for final production readiness with hardware-backed signing. 

While some lower-level language ecosystems were ready, higher-level language ecosystems struggled to align with the PQC needs of adopters. We faced friction with upstream communities that were missing native support for National Institute of Standards and Technology (NIST)-ratified signature algorithms, so we began targeted engagements with open source projects to collaborate, contribute, support, and align with industry needs and project constraints.

This forced a pivotal realization—complexity compounds as you ascend the stack because cryptography does not always inherit upward. At the operating system level, we act as the central governor of its cryptographic core. In the cloud-native ecosystem, however, everyone is beholden to the diverse release cycles of the various languages and frameworks that run on top of the OS. 

For example, Red Hat doesn’t just manage our code, we also manage the intersection of the Go language release cadence used by our products, the Java ecosystem’s transition, and the governance of hundreds of independent Kubernetes operators. Patching the foundation and expecting the structure to stay standing isn't viable, each and every part up the stack required a retrofit for PQC. This divergence defined our end-of-year strategy.

The unexpected win: Skeleton hunting

The most surprising outcome of 2025 wasn’t technical, it was organizational. The PQC program served as a forcing function that drove greater collaboration between our product teams, our Product Security team, and the office of the chief technology officer.

We discovered that we couldn’t just patch PQC into existence. To make the entire portfolio quantum-ready, we had to expose dependencies that had been opaque for years—the proverbial skeletons in the closet—quietly buried under organizational turnover, automation, and newer capabilities. These skeleton hunts forced teams that rarely had reason to collaborate to sit at the same table and begin standardizing their architectural patterns with a new understanding of the complex dependencies they all shared.

But let’s move from corporate speak to engineering realities—by doing this we caught silent failures that would have otherwise broken customer environments. Our RHEL-wide testing campaign exposed that nghttp2, a core building block of the modern web, lacked the necessary PQC support, which allowed us to engage directly with the upstream project for resolution. We discovered that tlshd was not ready for the new Module-Lattice-Based Digital Signature Algorithm (ML-DSA) certificates, and identified a gap in dual-certificate support for high-availability components such as pcsd. These were structural gaps that only a coordinated, portfolio-wide effort, backed by extensive testing, could have revealed.

Ultimately, 2025 proved RHEL is the anchor and collaboration is the accelerator. The rigid structure of the PQC program became the necessary framework that allowed these teams to move in unison, identify bugs early, and get them addressed quickly to enable continued stability and functionality.

2026: From discovery to standardization

As we look toward 2026, our strategy is shifting. If 2025 was about discovery (finding the gaps), 2026 is about standardization (filling them). As a result, we’re adopting a new architectural reality across the portfolio.

We cannot wait for every ecosystem and community to catch up. We need to contribute and help where we can, while still providing PQC assurances to our customers, with ample time to test and integrate, so we cause minimal disruption to customers' business operations. For 2026, we’re standardizing on a bridge approach to leverage proven, PQC-enabled libraries already present in RHEL. We’re also shifting from purely internal engineering to focusing more on upstream advocacy and engagement. We’ll be working directly with communities and hardware vendors to align PQC roadmaps with enterprise needs. 

Take a page from our book

Red Hat didn’t just ship PQC in 2025, we lived through the first phases of migration. If your organization is moving from research to readiness, here are 3 lessons we learned the hard way (so you don't have to):

1. Inventory is archaeology, not just a scanning effort

Code scanning has a lot of promise, but it can't tell you everything. To find real risk, you need to find the skeletons in the closet. Static analysis often misses the context of how cryptography is used. A cryptographic bill of materials (CBOM) can provide you with the list of what could be used or called, but talking with the longest-tenured engineers and running functional tests will allow you to find where your dependencies truly live.

2. Governance requires executive air cover

You’ve heard us say it before, PQC is not a feature but a cross-cutting concern that touches every layer of the stack. While direct engineer-to-engineer requests get stalled due to competing priorities, widespread efforts like PQC require formal escalation paths and integrating PQC requirements into existing planning cycles with engineering managers. Asking nicely doesn't upgrade a crypto library—a prioritized backlog with an assigned and accountable engineer does.

3. Your supply chain sets the speed limit on what you can get done

Our roadmap for 2026 is heavily dictated by release schedules of upstream communities and OEM partners. We had to adjust our own velocity to match the reality of the ecosystems we interact with. If you haven’t done so already, map your external blockers now. Identify which vendors are critical to your Harvest Now, Decrypt Later (HNDL) protection strategy, and begin requesting roadmaps. If they are blocked, you are blocked.

The road ahead

We enter 2026 with a highly connected internal network and a clear map of the terrain before us. The “if” is long gone, the “how” is defined. The OS is ready. The artifact is signed. Now we build the bridge for everything else.