Healthcare organisations hold data with longer mandatory retention periods than almost any other sector. A patient record created today may be held for seven to ten years under state law; genomic data has no natural end to its confidentiality requirement. When you encrypt that data under RSA-2048 key exchange in 2024 and a state-level adversary captures the encrypted traffic for later decryption, the confidentiality window extends well into the period where the first cryptographically relevant quantum computer is expected to become operational. HIPAA has not yet told you what to do about that. This article explains why that silence is not the same as permission to wait.

What HIPAA requires on cryptography, and where the quantum gap opens

The HIPAA Security Rule (45 CFR Part 164, Subpart C) requires covered entities and business associates to implement technical safeguards to guard against unauthorised access to electronic protected health information (ePHI) that is being transmitted or maintained. The encryption specifications at 45 CFR 164.312(a)(2)(iv) for ePHI at rest and 164.312(e)(2)(ii) for ePHI in transit are "addressable," not "required." In HIPAA terminology, addressable means the covered entity must implement the specification if it is reasonable and appropriate for its environment, or document a justified equivalent alternative. It does not mean optional. [VERIFIED: HIPAA Security Rule, 45 CFR 164.312(a)(2)(iv) and (e)(2)(ii), https://www.ecfr.gov/current/title-45/part-164.]

Where encryption is implemented, the "reasonable and appropriate" standard in 45 CFR 164.306(b) governs algorithm selection. HHS OCR guidance on HIPAA encryption references NIST SP 800-111 for data at rest and NIST SP 800-52 for TLS in transit as acceptable standards. Both of these NIST documents are in revision to reflect post-quantum cryptographic requirements following the August 2024 FIPS publications. [VERIFIED: NIST SP 800-111, https://doi.org/10.6028/NIST.SP.800-111; NIST SP 800-52 Rev 2, https://doi.org/10.6028/NIST.SP.800-52r2. ASSUMED: verify whether updated revisions referencing FIPS 203/204/205/206 have been published before stating both are under active revision.] Until updated versions are published, both should be read alongside NIST IR 8547 (November 2024) and the relevant FIPS documents for the current technical baseline.

The trajectory of the "reasonable and appropriate" standard is the critical point. HIPAA does not name algorithms. Algorithm selection is governed by the "reasonable and appropriate" test and by the NIST reference documents. As NIST updates its SP 800-series guidance to reflect FIPS 203/204/205/206, the standard that covered entities are expected to meet shifts. A covered entity that continues implementing RSA-2048 key exchange for ePHI transmission after NIST formally deprecates RSA in new deployments (targeted for 2030 under NIST IR 8547) may face a challenge that its measures are no longer "reasonable and appropriate" under 45 CFR 164.306(b). [INFERRED: this argument is technically sound but untested in HHS enforcement as of knowledge cutoff. See legal review notice above.] HHS OCR has not published specific guidance on post-quantum cryptography and HIPAA compliance as of mid-2026. ASSUMED: verify whether any HHS OCR quantum-related HIPAA guidance has been published after August 2025 before finalising this claim. The absence of specific guidance does not extinguish the obligation. The "reasonable and appropriate" standard applies to the technical baseline that exists now, not to a guidance document that has not yet been written.

Patient data retention and the HNDL timeline

HIPAA itself requires covered entities to retain Security Rule policy and procedure documentation for six years from creation or last in effect under 45 CFR 164.530(j). [VERIFIED: HIPAA 45 CFR 164.530(j).] HIPAA does not directly mandate medical record retention periods. Those are governed by state law. Most US states require seven to ten years from date of service for adult patient records; records for minors are typically retained until the patient reaches the age of majority plus the state-mandated retention period. [INFERRED for state law ranges from AHA and AHIMA guidance; specific state requirements vary. Cite as "most US states" not as a specific uniform figure.]

Applying the Mosca inequality to a standard healthcare scenario makes the risk concrete. A patient record created in 2024, encrypted with RSA-2048, retained for ten years under state law: x (confidentiality requirement) equals 10 years; y (migration timeline for a healthcare system with EHR dependencies) equals approximately 3 years; z (time to Q-Day) equals approximately 9 years on current expert consensus placing Q-Day in the 2033 to 2035 range. x plus y (13 years) exceeds z (9 years). The risk is present now, not in 2030. [VERIFIED: Mosca inequality, IEEE Security and Privacy, 2018, https://doi.org/10.1109/MSP.2018.3761723. INFERRED for the Q-Day range: consistent with NSA, BSI, and NCSC published frameworks; no single Tier 1 source gives a specific year. Present as expert consensus range, not a prediction.]

Genomic data presents a distinct risk profile that sits outside any standard retention calculation. Whole-genome sequencing data has a permanent confidentiality requirement because a patient's genome does not change. For healthcare organisations with genomics programmes, the HNDL risk calculation operates on an indefinite confidentiality window, which means the Mosca test is satisfied by any finite Q-Day estimate. Genomic data encrypted today should be treated as the highest-priority category for PQC migration planning in any healthcare CBOM. [VERIFIED: NIH Genomic Data Sharing Policy, https://sharing.nih.gov/genomic-data-sharing-policy.]

A dependency that many healthcare security programmes do not explicitly address: the covered entity's PQC migration is substantially determined by its EHR vendor's platform roadmap. Epic, Cerner/Oracle Health, Meditech, and athenahealth are the primary ePHI repositories in US healthcare. The cryptographic controls protecting ePHI in a vendor-hosted EHR are under vendor control. A covered entity that relies on a vendor-hosted EHR must incorporate the vendor's PQC migration timeline into its HIPAA risk analysis as a third-party dependency, with the Business Associate Agreement framework under 45 CFR 164.308(b) and 164.314(a) as the contractual instrument for requiring vendor engagement. [VERIFIED for EHR market participants and BAA framework citation.]

The HIPAA Risk Analysis: adding quantum risk

HIPAA Security Rule 45 CFR 164.308(a)(1)(ii)(A) requires covered entities to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. The risk analysis is the instrument through which quantum risk must be identified. An organisation that has not included harvest-now-decrypt-later as a threat in its HIPAA risk analysis has a gap in the analysis that OCR could identify in an audit. No published OCR enforcement action has cited absence of quantum risk analysis as of the knowledge cutoff; this is a forward-looking compliance exposure, not a current enforcement finding. [INFERRED from risk analysis scope; see legal review notice.]

NIST SP 800-66 Rev 2 (February 2023), "Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide," is the current NIST guidance document for HIPAA implementation. It does not reference post-quantum cryptography. Its February 2023 publication date predates the August 2024 FIPS finalisation. It should be read alongside NIST IR 8547 and the FIPS documents for the current technical baseline. [VERIFIED: NIST SP 800-66 Rev 2, https://doi.org/10.6028/NIST.SP.800-66r2, February 2023.]

The HIPAA risk analysis should address five quantum-specific elements. First: inventory of all asymmetric cryptographic protections applied to ePHI, covering algorithms, key sizes, protocols, and systems. Second: assessment of the confidentiality lifetime of ePHI held, by data category and retention requirement. Third: Mosca inequality calculation for the highest-sensitivity data categories, using a documented Q-Day assumption with source cited. Fourth: assessment of EHR and health IT vendor PQC migration roadmaps, documented as a third-party risk item. Fifth: documentation of the risk management response, whether that is a migration plan with milestones, an acceptance rationale, or a hybrid TLS deployment as an interim control. [INFERRED from HIPAA risk analysis requirements at 45 CFR 164.308(a)(1) applied to the quantum threat model. No HHS OCR guidance document specifies these elements for quantum risk.]

HITECH, breach notification, and the CRQC scenario

The HITECH Act (42 U.S.C. § 17921 et seq.) strengthened HIPAA enforcement and established the Breach Notification Rule. Under 45 CFR Part 164, Subpart D, a breach of unsecured ePHI requires notification to affected individuals, HHS, and in some cases the media. "Unsecured" ePHI is defined as ePHI not rendered unusable, unreadable, or indecipherable through a technology or methodology specified by HHS guidance. Encryption using NIST-approved methods is the primary mechanism by which ePHI is classified as "secured." [VERIFIED: HITECH Act, 42 U.S.C. § 17921 et seq.; HIPAA Breach Notification Rule, 45 CFR 164.400 et seq.]

What happens when NIST formally deprecates RSA and the algorithms that currently classify ePHI as "secured"? The interaction between NIST IR 8547's deprecation timeline and the HHS "secured" ePHI definition is an open legal question that has not been addressed in HHS enforcement or in published HHS guidance. [INFERRED from the logical interaction between NIST IR 8547 and the "secured" ePHI definition; see legal review notice above.] A covered entity that continues using deprecated algorithms after the 2030 new-deployment deprecation date may face an argument that its ePHI is no longer classified as "secured" under HHS guidance, with implications for breach notification obligations and for the safe harbour that "secured" status currently provides.

A CRQC-enabled decryption event affecting a historical ePHI archive raises a further question: whether the decryption constitutes a "breach" of "unsecured" ePHI under the Breach Notification Rule, whether that assessment is made at the time of original collection, at the time of decryption, or at the time the deprecated algorithm becomes publicly known as inadequate. These are genuinely open legal questions. No HHS OCR guidance or court decision has addressed them. They are included here because they are the forward questions a healthcare CISO or Compliance Officer should be raising with legal counsel now, not after a CRQC event occurs. [See DRAFT FOR LEGAL REVIEW notice above.]

Five-step migration framework for covered entities

Step 1: Cryptographic inventory of ePHI protections. Map every system that stores or transmits ePHI, identify the cryptographic algorithms protecting each, and classify the ePHI by retention period and confidentiality lifetime. This is the CBOM process applied to the ePHI context, per NIST NCCoE SP 1800-38B methodology. The highest-priority systems in most healthcare environments: EHR system API connections and data exports; Health Information Exchange (HIE) TLS connections; ePHI backup and archive encryption; medical device communication protocols including HL7 FHIR and DICOM; and remote access VPNs handling ePHI. [VERIFIED: NIST NCCoE SP 1800-38B, https://www.nccoe.nist.gov/projects/migration-post-quantum-cryptography; HL7 FHIR and DICOM as primary ePHI transmission protocols.]

Step 2: Vendor engagement. Issue a formal request for information to your EHR vendor. The specific question: does your organisation have a published PQC migration roadmap, and when will your API and data exchange interfaces support ML-KEM (FIPS 203) and ML-DSA (FIPS 204)? Document the vendor's response, or the absence of a response, in the HIPAA risk analysis as a third-party risk item. For Business Associates handling ePHI, include a PQC readiness question in the next BAA review cycle under 45 CFR 164.308(b). A vendor with no response is a documented risk; a vendor with a committed timeline is a documented dependency that goes into the migration programme plan. [INFERRED from HIPAA BAA requirements applied to the vendor PQC dependency.]

Step 3: Deploy hybrid key exchange on internet-facing ePHI flows. The operational first step for protecting ePHI in transit against harvest-now-decrypt-later is deploying X25519+ML-KEM-768 hybrid key exchange in TLS 1.3 on all internet-facing endpoints that transmit ePHI. This is backwards-compatible with clients that do not support ML-KEM and provides HNDL protection for new traffic from the point of deployment. The hybrid key derivation approach follows IETF RFC 9496 (X-Wing Hybrid KEM) and IETF draft-ietf-tls-hybrid-design. Chrome and Cloudflare operated hybrid X25519+Kyber768 (draft-standard) deployments from 2023; the production transition to FIPS 203 ML-KEM-768 followed FIPS publication in August 2024. Healthcare IT security teams should confirm their TLS termination layer, whether a load balancer, CDN, or application server, supports hybrid key exchange configuration with the finalised ML-KEM-768 parameter set. [VERIFIED: IETF RFC 9496, https://www.rfc-editor.org/rfc/rfc9496; IETF draft-ietf-tls-hybrid-design; NIST FIPS 203, August 2024.]

Step 4: Update the HIPAA risk analysis. Add an explicit HNDL threat entry. Document: the threat source (state-level adversary with CRQC capability, projected 2033 to 2035 expert consensus); the threat action (decryption of historically captured ePHI); the vulnerability (RSA/ECDH key exchange on long-lived ePHI archives); a likelihood and impact assessment; and the mitigation measures, referencing hybrid TLS deployment status, migration timeline, and vendor engagement results. This entry demonstrates that quantum risk has been assessed under 45 CFR 164.308(a)(1)(ii)(A) and that a proportionate response is documented.

Step 5: Document the migration plan. The plan does not need to be complete. It needs to be documented, actioned, and tied to a review cadence. A documented plan showing the CBOM results, the prioritisation rationale (highest-sensitivity data and longest confidentiality lifetime first), the vendor engagement status, the hybrid TLS deployment status or timeline, and the review schedule is materially stronger than no plan under the HIPAA risk management requirement at 45 CFR 164.308(a)(1)(ii)(B). For any OCR audit context, documented partial progress is the position that demonstrates engagement with the obligation. Absence of documentation is the position that fails the "accurate and thorough" test. [INFERRED from HIPAA risk management requirements; no HHS guidance specifies these exact plan elements for quantum risk.]

UK NHS context

UK NHS organisations operate under a different regulatory framework. The NHS Records Management Code of Practice 2021 (England) specifies retention periods by record type: adult inpatient records to 8 years; maternity records to 25 years; records with clinical risk implications to longer periods. The HNDL risk for NHS organisations is acute in several categories because of those longer mandatory retention periods. [VERIFIED: NHS Records Management Code of Practice 2021, https://www.england.nhs.uk/records-management/. Note: NHSX merged into NHS England; the current authoritative path is england.nhs.uk.] UK NHS compliance obligations flow from the Data Security and Protection Toolkit (DSPT) referencing UK NCSC Cyber Essentials, not HIPAA. The UK NCSC has published quantum-safe cryptography guidance applicable to NHS organisations. [VERIFIED: NCSC Quantum-Safe Cryptography, https://www.ncsc.gov.uk/collection/post-quantum-cryptography.] UK readers should direct compliance questions to the DSPT and NCSC rather than treating the HIPAA framework as applicable.

What your next HIPAA risk analysis should contain

The minimum viable update to a HIPAA risk analysis in 2026 that incorporates quantum risk has five elements: the CBOM results for all ePHI systems, identifying every asymmetric key use; a Mosca inequality calculation for the highest-sensitivity data categories with a documented Q-Day assumption; EHR vendor PQC migration status documented as a third-party risk item; hybrid TLS deployment status or planned timeline for internet-facing ePHI endpoints; and a migration plan with at least one committed milestone.

An organisation that can produce these five elements under OCR examination has demonstrated that quantum risk has been assessed and that a proportionate response is underway. That is the test under 45 CFR 164.308(a)(1). An organisation that cannot produce any of them has a documented gap in the risk analysis, regardless of what the rest of the ISMS contains.

For the data classification methodology that prioritises which ePHI categories face the highest HNDL exposure, see our analysis at which data is most at risk from harvest-now-decrypt-later today. For the parallel treatment of the HNDL threat in financial services for readers with cross-sector responsibilities, see HNDL in financial services: regulatory and operational considerations.