Preparing for Q-day: Four steps to prepare your hybrid cloud today
Article by: JP Jung, Red Hat
The arrival of a cryptographically relevant quantum computer, often referred to as Q-day, is moving from a distant theoretical mathematical challenge to an urgent timeline that security teams must plan for today. Bad actors are already engaging in harvest now, decrypt later activities. This means they are capturing and storing encrypted enterprise traffic, intellectual property, and data logs today with the intention of running them through quantum hardware as soon as it becomes available.
At Red Hat, we believe taking this threat seriously means acting before the crisis arrives. Rather than viewing post-quantum cryptography (PQC) as a distant compliance box to check, we are actively leading the charge by embedding quantum-safe capabilities directly into the foundational layers of hybrid cloud infrastructure. This approach gives organizations the tools they need to protect their digital assets today while preparing for Q-day in the not-too-distant future.
This urgency is not hypothetical. According to the White House Executive Order 14412, federal agencies are expected to achieve a pilot migration to post-quantum cryptography (PQC) readiness by 2027 and complete full-scale execution by 2029. This aligns with the National Security Agency’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) mandate, which requires quantum-safe algorithms for national security systems, with commercial TLS implementations facing strict enforcement deadlines by 2030. The strategic question is not whether you are 100% sure a cryptographically relevant quantum computer will exist in 2030; the question is whether you are 100% sure it will not. Organizations that wait until quantum computers arrive to begin their migration will find themselves three to five years behind, with their archived data most likely already compromised.
A portfolio built on market-first quantum innovation
Red Hat addresses these urgent challenges through a unified, joint-solution approach that bakes quantum security into the very foundation of your hybrid cloud. Red Hat Enterprise Linux (RHEL) 10 is the first enterprise Linux distribution to ship with NIST-standardized post-quantum algorithms, including ML-KEM and ML-DSA-enabled natively at the operating system level.
Built entirely on that hardened foundation, Red Hat OpenShift inherits these capabilities. OpenShift does not attempt to build its own cryptographic libraries from scratch. Instead, it positions RHEL as the underlying engine providing the compliance and security math, which OpenShift then operationalizes and scales across distributed environments.
By shifting security from fragmented application layers down to a unified RHEL and OpenShift infrastructure, organizations gain a more secure, compliant, and cost-effective platform. This joint architecture protects your most valuable artificial intelligence (AI) assets from future quantum decryption and regulatory overreach today, all while reducing cloud operational complexity and expenses.
Here are the top four things you can do to be ready for Q-day:
- Inventory your hidden cryptographic footprint across the hybrid cloud
Organizations cannot defend what they cannot see, and most enterprises run millions of automated software connections that rely on older, quantum-vulnerable public security algorithms. Security teams need a comprehensive understanding of where data is scrambled and where digital keys are created across distributed environments. This shifts the operational focus toward mapping high-value assets like AI model weights and training logs.
The default system-wide cryptographic policy in Red Hat Enterprise Linux 10 provides next-generation cryptographic settings by enabling advanced, quantum-resistant algorithms. Operators can instantly enable all core host communication to use quantum-safe standards for key encapsulation. This allows teams to test real-world application performance, processing overhead, and latency before moving workloads to production. Security teams should evaluate core software platforms to identify legacy hardcoded or outdated security standards, making sure foundational infrastructure layers provide clear visibility into internal network communications.
- Test next-generation cryptographic primitives in non-production environments
Transitioning to quantum-resistant security requires evaluating how new mathematical encryption methods affect overall application performance, network response times, and processing overhead. RHEL 10’s system-wide crypto-policy profiles, including the FUTURE policy, allow operators to switch the entire host’s cryptographic posture to quantum-resistant standards with a single command. This makes it practical for security teams to test real-world behavior across the full stack rather than in isolated application experiments.
The newly released Red Hat OpenShift 4.22 delivers quantum-safe key exchange as a generally available, production-ready capability. ML-KEM hybrid key exchange is active by default. That means every TLS handshake between control plane components uses quantum-safe cryptography out of the box, with no configuration required. Workloads running on the platform inherit PQC-capable TLS without any application code changes.
Because RHEL handles the low-level security libraries (like OpenSSL), individual application developers do not have to rewrite code or manage complex algorithm selection. This platform-wide inheritance contrasts with traditional fragmented approaches from other Kubernetes-derived platforms, which lack native, end-to-end, out-of-the-box control plane PQC integration. While full production implementations require ongoing technical validation to determine optimal enterprise configurations, this technology preview provides a valuable mechanism for validating software compatibility and preparing infrastructure teams for the broader migration ahead.
- Shift security boundaries from the application layer to the platform layer
Expecting individual development teams to manually rewrite every single application to support post-quantum cryptography creates massive operational friction, delays project timelines, and introduces configuration errors.
To understand the business value, imagine every connection your applications make as an encrypted phone call. Adversaries don’t need to understand those calls today, they only need to record them. The tapes are gibberish now, but recordings don’t expire, and the bet is that quantum computers will eventually play them back in the clear. This means that any “information conversation” happening today, whether it’s training data moving to a GPU cluster, model weights replicating between sites, or agents exchanging credentials, is already potentially exposed to this “harvest now, decrypt later” strategy. Red Hat OpenShift changes the encryption on every one of those calls at the platform level, using algorithms designed to resist quantum attack, so that the recordings being made today stay gibberish, without any application team touching its own code.
We believe quantum security is an immediate requirement for protecting AI assets in transit. This moves the conversation away from a theoretical future browser issue to protecting your proprietary training data, model weights, and agent logs from immediate interception. Red Hat customers can benefit from establishing a unified, crypto-agile application platform layer that automatically handles secure handshakes on behalf of the underlying workloads.
Using platform-wide secure networking tools allows organizations to test post-quantum cryptographic connections, instantly shielding container communication from interceptors without requiring changes to application source code. Cryptographic upgrades happen once in RHEL, propagate automatically through OpenShift, and protect every workload running on top. Individual application teams do not need to rewrite TLS code, swap libraries, or manage algorithm selection. The platform handles it.
- Assert absolute operational control over data placement and execution
True quantum readiness requires more than updated security keys; it demands
complete authority over where data resides and how infrastructure executes workloads. Relinquishing architectural command to a centralized public cloud control plane leaves your organization operationally vulnerable to platform decisions and management policies that are not your own.
Operators can maximize infrastructure control by using isolated platform environments to maintain strict boundaries between computing workloads. This helps verify that data paths never cross into locations where digital cargo can be compromised. Organizations can pair this strategy with hardware-enforced solutions like confidential containers to shield sensitive data while it is actively being processed.
You do not need to wait for Q-day to start preparing. Start by inventorying your cryptographic footprint: know which algorithms, key lengths, and protocols your applications depend on today. Review the RHEL post-quantum cryptography documentation and the OCP 4.22 release notes to understand what is available now. Then talk to your Red Hat account team about a PQC readiness assessment—we can help you map your migration path before the deadlines arrive.
