The DHA post-quantum transition: A phased security roadmap

The Defense Health Agency (DHA) manages a massive, multi-petabyte data estate across more than 700 medical, dental, and veterinary clinics at risk from harvest now, decrypt later (HNDL) attacks and quantum forgery in the future.¹ DHA needs to build a crypto-agility foundation now to allow a future, targeted re-encryption of the highest-sensitivity medical data and protect operational systems. A phased approach achievable on DHA's timeline avoids an emergency response to Q-Day, the approaching moment a cryptographically relevant quantum computer (CRQC) can break existing encryption algorithms underpinning modern digital security. 

The DHA operates as a critical combat support agency (CSA) leading the Military Health System (MHS) to sustain warfighter readiness. This mission relies on an immense, continuously expanding data estate containing multiple petabytes of protected health information (PHI), personally identifiable information (PII), and operational health records spanning more than 9.5 million beneficiaries¹ and 150 military treatment facilities (MTFs) globally.²

The rise of quantum computing renders classical cryptographic protections obsolete. In 1994, Peter Shor devised an algorithm that factors integers and computes discrete logarithms in polynomial time on a quantum computer.³ A sufficiently advanced quantum computer running Shor's algorithm can crack Rivest–Shamir–Adleman (RSA), elliptic-curve cryptography (ECC), and Diffie-Hellman in polynomial time. Adversaries are actively using HNDL tactics: intercepting encrypted communications today to retroactively decrypt them when technology matures. HNDL remains a serious threat, but other dangers exist. As Q-Day approaches, agencies must account for a much wider circle of vulnerabilities, which is why the National Institute of Standards and Technology (NIST) guides federal agencies to begin migration immediately.

Because clinical records, genomic profiles, and deployment health histories remain sensitive for the lifetime of a service member and beyond, near-term exposure presents a direct threat to national security. DHA's massive petabyte scale makes a wholesale, immediate re-encryption of all data at rest operationally impossible without severe disruption of live clinical workflows.

Red Hat’s strategy for DHA’s quantum transition focuses on 4 pillars: securing data in motion, hardening access layers for security, continuous cryptographic discovery using Cryptographic Bills of Materials (CBOMs), and automating the rollout process.

Instead of treating post-quantum migration as a single, overwhelming data-at-rest overhaul, Red Hat recommends sequencing remediation where the threat is most immediate and the fix is most attainable: securing data in motion and tightening data access controls at the platform layer. Achieving agility with this strategy will allow the DHA to migrate data and systems in the future without disrupting clinical operations that directly support warfighter readiness.

By building an automated foundation of crypto-agility using Red Hat® Enterprise Linux® 10, Red Hat OpenShift®, Red Hat OpenShift Virtualization, and Red Hat Ansible® Automation Platform, the DHA can systematically isolate and address quantum risks without interfering with active clinical care. This foundation checklist offers 4 detailed points to consider:

1. Securing data in motion

Data in transit is the most exposed attack surface. Every TLS session transporting patient files or telehealth data, such as connections between an MTF, MHS GENESIS, or a TRICARE network partner, is a prime target for encryption harvesting. Red Hat Enterprise Linux 10 natively supports all 3 NIST-finalized post-quantum cryptographic (PQC) algorithm families in its core cryptographic libraries—OpenSSL and Network Security Services (NSS): 

• Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM or FIPS 203): Used for quantum-safe key exchange in TLS, immediately securing sessions moving data between MTFs, telehealth services, and MHS GENESIS.
• Module-Lattice-Based Digital Signature Algorithm (ML-DSA or FIPS 204): A lattice-based digital signature algorithm integrated for quantum-safe TLS authentication.
• Stateless Hash-Based Digital Signature Algorithm (SLH-DSA or FIPS 205): A stateless hash-based digital signature algorithm providing mathematical diversity for long-lived assets, including firmware and software attestation. 

Red Hat OpenShift inherits these capabilities with Red Hat Enterprise Linux CoreOS, allowing DHA to deploy TLS 1.3 quantum-safe key exchanges across its entire container control plane, kubelets, and ingress controllers.

2. Hardening the access layer to restrict blast radius

Identity, authentication, and certificate issuance govern who and what can interface with a hyper-scale petabyte data storage estate. Implementing post-quantum signatures (ML-DSA and SLH-DSA) hardens access gateways against credential forgery and unauthorized entry, safely insulating data at rest without needing to touch underlying storage. Demonstrating this readiness, Red Hat successfully generated the 1st fully PQC-signed RPM Package Manager (RPM) package for Red Hat Enterprise Linux 10.1, proving that artifact authenticity can be enforced at the packaging level so that clinical nodes run only untampered software.

3. Using CBOMs for continuous discovery

DHA cannot protect what it cannot locate. Discovery is the foundational activity that makes this strategy executable, and Ansible Automation Platform is the natural orchestration layer for turning CBOM discovery from a one-time audit into a scalable, continuously maintained program. Once assembled, the CBOM becomes the basis for risk-ranking remediation work, surfacing which systems carrying PHI still depend on classical algorithms and should be addressed first.

Cryptography is typically embedded deep within application codes, container images, and existing vendor systems accumulated over decades without centralized tracking. Red Hat Enterprise Linux and Red Hat OpenShift address this lack of transparency by exposing core cryptographic configurations directly. Using standards like CycloneDX's CBOM specification, DHA can generate a structured, machine-readable inventory of cryptographic assets, key length, library versions, and certificates across the network, turning future reencryption tasks into scoped, risk-prioritized action.

4. Operationalizing with automation

DHA can scale its transition by turning its existing investment in Ansible Automation Platform into a continuous orchestration layer. Ansible Playbooks handle 3 vital workstreams that transform a future re-encryption effort from a guess into a scoped, prioritized program: 

• Automated CBOM generation: Systematically scans hosts, containers, and virtual machines to map out cipher suites and library versions without manual audits.
• Risk prioritization: Ranks systems holding critical PHI that still rely on classical traditional algorithms to guide early migration phases.
• Phased rollouts: Sequences and validates configuration rollouts (like enforcing TLS 1.3 or PQC key exchanges) in waves across MTF gateways.

Red Hat recommends a phased approach to implementing this strategy. This reflects DHA's stated priorities—protecting data in motion and tightening data access now, while building toward a scoped, risk-prioritized re-encryption program for data at rest.

Red Hat Enterprise Linux 10 and Red Hat OpenShift bring quantum-safe TLS to the connections carrying PHI today with emerging PQC certificate and signature support to harden the identity and access systems that gate the data estate. Ansible Automation Platform builds the cryptographic inventory and automation that will turn a future re-encryption program into a scoped, prioritized effort rather than an emergency response.

Table 2. 3-phase post-quantum approach timeline

This phased approach lets DHA reduce its most pressing quantum exposure now, on a timeline and budget compatible with its operational realities—while laying the groundwork to protect the full data estate as the PQC ecosystem matures.

Protecting existing workloads with OpenShift Virtualization

Red Hat’s strategy also acknowledges that a major portion of DHA's applications—including those integrated into MHS GENESIS and existing MTF frameworks—run as VMs rather than cloud-native containers. OpenShift Virtualization lets these VM-based workloads run directly on the same Red Hat Enterprise Linux CoreOS base as modern containerized applications. Existing systems instantly inherit Red Hat Enterprise Linux 10 native quantum-safe cryptographic libraries and TLS 1.3 support, shielding data in motion without forcing costly application refactoring. 

Real-world integration reveals that cryptographic protections do not automatically inherit upward, because production-grade certificate support is still maturing. And while PQC performance overhead is real, it is manageable with correct configuration.

Red Hat's full-system PQC integration testing exposed crucial technical realities for distributed medical environments: 

• Crypto does not inherit upward: Patching the underlying operating system layer does not automatically protect applications running above it. Runtime layers (Go, Java, Python) and operators require individual cryptographic validation, highlighting why phase 2 CBOM mapping is vital.
• Ecosystem gaps: While NIST standards are finalized, several Internet Engineering Task Force Requests for Comments (IETF RFCs) governing their use inside TLS remain in draft. Production-grade certificate chain support for PQC signatures is still actively maturing, reinforcing why data-in-motion protections must lead the transition.
• Performance overhead is real but manageable: Post-quantum signature schemes use larger keys and demand more computational overhead than classical schemes. However, Red Hat testing confirms that correct configuration tuning keeps latency acceptable for live production clinical workloads.

Is your agency or organization ready for the post-quantum transition? Visit red.ht/dha to contact Red Hat’s defense technology team or schedule an executive briefing to get help mapping your cryptographic dependencies.

• Assess your cryptographic exposure: Run a playbook in Ansible using Ansible Automation Platform to initiate automated discovery and map out an active Cryptographic Bill of Materials (CBOM) across core environments.
• Shield front-end clinical traffic: Deploy Red Hat Enterprise Linux,⁷ Red Hat OpenShift, and OpenShift Virtualization across high-volume networks to deliver native TLS 1.3 and ML-KEM post-quantum protections to active telehealth and MHS GENESIS connections.
• Review native platform libraries: Talk to Red Hat product specialists to review the post-quantum cryptographic roadmaps built natively into Red Hat Enterprise Linux 10 to schedule core system base upgrades.