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 leadershipRed 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 SaaSThere'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 ecosystemThe 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 countdownsRed 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 dateLet’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.