Red Hat’s RHEL 10 Turns Post-Quantum Migration Into a Financial Services Deadline

Red Hat used its July 29 company blog to make a narrow, specific argument: financial services firms that are still waiting for a regulatory mandate before starting post-quantum cryptography (PQC) migration are already behind schedule, whether or not that mandate has arrived yet. The post, written by John Gerbino of Red Hat’s Global Product and Solutions Marketing team, ties the claim to a straightforward timeline mismatch, then pairs it with a specific product argument: Red Hat Enterprise Linux (RHEL) 10, which Red Hat calls the first enterprise Linux distribution built to be post-quantum capable.

The timeline problem is easy to state. Red Hat estimates that quantum computers capable of breaking current public-key encryption, a milestone often called “Q-Day,” are “within 2-5 years away.” Large-scale systems remediation inside a financial services institution, per the same post, “typically takes 5 to 7 years.” When a rollout takes longer than the runway before the threat arrives, the math stops working: “any data requiring confidentiality beyond the estimated quantum threat horizon (roughly estimated to be 2031), is already compromised if protected solely by classical cryptography,” even though no quantum computer capable of actually reading that data exists yet.

What “Harvest Now, Decrypt Later” Actually Means

That last claim rests on a specific attack model, not speculation about future hardware. Red Hat describes harvest now, decrypt later (HNDL) plainly: it is “where malicious actors intercept and store encrypted financial data today with the intention of decrypting it once quantum computers are powerful enough and become available.” An adversary does not need a working quantum computer today. They need only to capture and store ciphertext now, then wait.

That makes HNDL a data retention problem before it is a cryptography problem. Ordinary transaction data with a short useful shelf life is a low priority target under this model. Data with a long required confidentiality window, loan underwriting files, know your customer and anti-money-laundering records, trade secrets embedded in financial models, custodial and estate records meant to stay confidential for decades, is a different story. If that data is protected today only by RSA or elliptic curve cryptography (ECC), and it needs to stay confidential past the early 2030s, HNDL means the exposure event may already have happened. The decryption is just delayed.

The Regulatory Clock Started Before the Technology Did

United States: An Inventory Mandate Since 2022

Washington’s clock started earlier than most financial sector compliance conversations acknowledge. On December 21, 2022, President Biden signed the Quantum Computing Cybersecurity Preparedness Act (H.R. 7535) into law. The act does not regulate banks directly, it applies to federal executive agencies, but it establishes a sequence worth noting: it requires each covered agency to maintain an inventory of IT systems vulnerable to decryption by quantum computers, and directs the Office of Management and Budget to issue government-wide guidance on migrating those systems to post-quantum cryptography. Inventory first, migration guidance second, is the same sequence Red Hat’s own recommendation for financial services follows later in this post.

European Union: A Roadmap With Real Dates

Europe has gone further and published actual dates. On June 23, 2025, the European Commission and EU member states released a coordinated roadmap for the transition to post-quantum cryptography. It sets checkpoints: all member states should start transitioning by the end of 2026; critical infrastructure and other high-risk systems should be migrated to PQC “as soon as possible, no later than by the end of 2030”; and the remaining medium and low risk systems are expected to complete the transition by 2035.

Layered on top of that roadmap, the EU’s Digital Operational Resilience Act (DORA), applicable to financial entities since January 17, 2025, already requires protecting cryptographic keys through their full lifecycle and building strong authentication into ICT systems, and requires ICT risk assessments that explicitly cover cryptographic assets and certificate infrastructure. DORA does not name post-quantum cryptography directly, but a regulation that already forces financial firms to inventory and risk assess their cryptographic assets gives auditors an existing hook to start asking about quantum readiness well before any PQC specific rule is finalized.

NIST Finished Its Job in 2024; Now It’s an Infrastructure Problem

The algorithms themselves stopped being an open research question in August 2024. On August 13, 2024, the U.S. National Institute of Standards and Technology finalized its first three post-quantum cryptography standards: FIPS 203 (ML-KEM, built on the CRYSTALS-Kyber algorithm), the primary standard for general purpose encryption and key establishment; FIPS 204 (ML-DSA, built on CRYSTALS-Dilithium), the primary standard for digital signatures; and FIPS 205 (SLH-DSA, built on SPHINCS+), a structurally different signature scheme held in reserve in case a weakness is ever found in ML-DSA. NIST’s own announcement was blunt that organizations should start transitioning immediately, since full integration will take time.

That last point is really what Red Hat’s post is about. Finalized standards answer the question of which math to use. They do not answer the operational question of how a bank rolls new key exchange and signature algorithms into TLS termination points, SSH fleets, certificate authorities, hardware security modules, and decades old batch systems without breaking anything. ML-KEM and ML-DSA keys and signatures are also considerably larger than the RSA and ECC values they replace, which means fixed size fields in old protocols, database schemas, and firmware can silently break the moment a system tries to use them. Standardizing the primitive was the easy part. Red Hat’s argument is that the actual bottleneck, for financial services specifically, is now infrastructure and operations, not cryptography research.

Where RHEL 10 Fits: Turning a Standard Into an OS Level Default

Red Hat’s answer to the operational half of that problem is to build PQC support into the operating system layer rather than leaving it to individual applications. According to Red Hat’s own technical documentation, RHEL 10.0 shipped with ML-KEM available for TLS connections through OpenSSL, GnuTLS, and NSS, and for SSH connections through OpenSSH. That is a meaningfully broad footprint: getting hybrid post-quantum key exchange working across three separate TLS libraries and the standard Linux SSH stack at once means most applications that rely on the system’s own cryptographic libraries, rather than rolling their own, inherit PQC support without being individually rewritten.

There is a version level nuance the “first post-quantum capable” framing glosses over. Red Hat’s own documentation notes that enabling PQC on RHEL 10.0 required an administrator to manually change the system’s crypto policy: installing the relevant package and switching crypto policies was “only required on RHEL 10.0.” Post-quantum algorithms only became part of the DEFAULT system wide crypto policy, meaning enabled out of the box with no configuration change, starting with RHEL 10.1. Security teams building a migration timeline should treat “PQ capable” and “PQ by default” as two different milestones that arrived in two different point releases, not one announcement.

A Four-Phase Roadmap

Red Hat frames the broader transition as four phases. Classical is the traditional state, with no quantum resistant algorithms available. PQ-Capable is the phase where quantum resistant algorithms exist and can be turned on, but classical algorithms remain the default, which is where RHEL 10.0 sits. PQ-Ready is the phase where quantum resistant algorithms become the default and classical algorithms remain available only as a fallback, which lines up with where RHEL 10.1’s default policy landed. Deprecation and removal is the eventual end state, where classical algorithms are phased out entirely. Naming the migration as discrete phases, rather than a single cutover date, gives security teams a shared vocabulary for tracking where a given system actually sits, instead of a binary “have we done PQC yet” checkbox.

A Narrower Fix for a Real Certification Problem

One detail in Red Hat’s post addresses a specific, well known operational pain point rather than a cryptographic one. RHEL 10 splits out a dedicated FIPS validation module, which Red Hat says “allows FIPS cryptographic standards to be validated separately,” so that critical security fixes can be applied immediately “without waiting for a new FIPS validation certificate,” a recertification process Red Hat describes as sometimes taking “more than 300 days.” Financial institutions operating under FIPS 140 requirements have historically had to choose between shipping a security patch quickly and staying on a certified cryptographic module, because the certificate technically covers one specific, frozen build. Decoupling the FIPS module from the rest of the OS release cycle targets that tradeoff directly, independent of anything specific to post-quantum algorithms.

What This Means for Financial Services Security Teams

Red Hat’s own recommendation for organizations breaks into two phases, and neither one is RHEL specific.

Phase 1: Find Every Place You Use Public-Key Cryptography

The first phase is inventory and risk assessment: deploy automated discovery tools to map every use of public-key cryptography, RSA and ECC keys and certificates, across hardware, firmware, operating systems, and protocols; classify what is found by criticality and by how long that data needs to stay confidential; and audit third party vendors for their own PQC roadmaps. That last item matters more than it might sound. A bank’s own infrastructure being PQ ready does not help if its core banking vendor, payment processor, or a critical SaaS provider has no migration plan of its own, since a financial transaction’s cryptographic protection is only as strong as its weakest hop.

Phase 2: Roll Out Hybrid Encryption, Starting With the Network

The second phase is architectural remediation: begin a phased PQC rollout starting with network encryption, since that is where OS level and library level support is most mature today; test new implementations thoroughly given the larger key and signature sizes involved; and upgrade key management systems to handle the new algorithm types and artifact sizes. The through line across both phases is a hybrid approach, running classical and post-quantum algorithms simultaneously rather than a hard cutover, so systems stay interoperable with anything on the other end of a connection that has not migrated yet.

The Math Doesn’t Change by Vendor

Strip away the RHEL specific detail and the underlying argument is not really about Red Hat at all. NIST closed the algorithm question in August 2024. The United States has required federal agencies to inventory quantum vulnerable systems since December 2022. The European Union has published specific migration checkpoints for 2026, 2030, and 2035, and its financial sector operational resilience regulation already requires the kind of cryptographic asset inventory that PQC migration depends on. None of those dates moved because a vendor released a new product.

What changes by vendor is only how much of the operational burden shows up as a line in someone’s project plan versus something the operating system, network stack, or key management platform already handles. Red Hat’s pitch is that shipping PQC support at the OS layer removes a chunk of that burden for RHEL customers specifically. The harder number in the post, that a five to seven year remediation project needs to fit inside a two to five year threat window, stays the same regardless of which vendor’s logo is on the server rack.

Sources

• Red Hat Blog: No time to lose, why post-quantum security for financial services must start now
• Red Hat Blog: Post-quantum cryptography in Red Hat Enterprise Linux 10
• NIST: NIST Releases First 3 Finalized Post-Quantum Encryption Standards
• The Quantum Insider: President Signs Quantum Computing Cybersecurity Preparedness Act
• European Commission: EU reinforces its cybersecurity with post-quantum cryptography
• EUR-Lex: Regulation (EU) 2022/2554, Digital Operational Resilience Act

Image credit: IBM Quantum System Two at its Ikerbasque inauguration in Donostia-San Sebastian, Spain. Photo by Iñigo Sierra / Irekia-Eusko Jaurlaritza, licensed CC BY 4.0 via Wikimedia Commons; cropped, resized, and converted to WebP for sxz.io.