Medical records are the longest-lived sensitive data in any industry. HIPAA requires a minimum of six years of retention. Most US states mandate seven to ten. Pediatric records in many states must be kept until the patient turns 21 — or longer. Mental health records, cancer registry data, and research cohort data carry retention windows of twenty to thirty years.
Now consider that every one of those records is being encrypted today with RSA or ECDSA — algorithms NIST will formally deprecate in 2030.
A patient record created today, encrypted with RSA-2048, must remain confidential until 2040 or beyond. A quantum computer capable of breaking RSA is expected by the mid-2030s. The arithmetic is not complicated. Healthcare is not just vulnerable to Harvest Now, Decrypt Later attacks — it is the most exposed sector of any.
The HIPAA–NIST Compliance Chain Most CISOs Haven't Mapped
HIPAA's Security Rule is deliberately algorithm-agnostic. The regulation itself — 45 CFR §164.312(a)(2)(iv) and §164.312(e)(2)(ii) — requires covered entities to implement encryption mechanisms to protect PHI at rest and in transit. It does not name RSA. It does not name AES. It defers entirely to NIST for guidance on what "reasonable and appropriate" cryptography looks like.
That deferral runs through NIST SP 800-66 Rev 2 (the HIPAA Security Rule implementation guide, updated December 2023), which references NIST-approved cryptographic standards throughout. When OCR (HHS Office for Civil Rights) audits a covered entity's cryptographic controls, it evaluates them against this guidance.
This is not a theoretical future risk. OCR has levied fines exceeding $1.9 million for inadequate encryption controls. The standard it applies is the NIST standard. As that standard moves, HIPAA compliance moves with it — whether the industry is ready or not.
Why PHI Retention Makes Healthcare the Highest-Risk Sector
The Harvest Now, Decrypt Later attack is straightforward: an adversary captures encrypted data today and waits for a quantum computer to decrypt it. The viability of the attack depends entirely on one variable — how long the stolen data needs to remain confidential.
For a SaaS company storing session tokens, HNDL is a minor concern. Tokens expire. For a hospital storing a patient's complete medical history, HNDL is an existential threat. Here's why:
| Record type | Typical retention | Sensitivity window | HNDL exposure |
|---|---|---|---|
| Standard adult medical records | 7–10 years | Lifetime of patient | High |
| Pediatric records | Until age 21–28 (state-dependent) | 25+ years from creation | Critical |
| Mental health / psychiatric records | 10+ years (many states) | Lifetime — stigma is permanent | Critical |
| Oncology / cancer registry | Permanent in many states | Lifetime | Critical |
| Research cohort / clinical trial data | 15–30 years | Duration of study + beyond | High |
| Claims and billing data | 7–10 years | Fraud liability window | Medium–High |
A paediatric mental health record created today could legally need to remain confidential until 2055. It will be encrypted with RSA. A nation-state actor capturing that data today has thirty years to find a quantum computer. They will not need thirty years.
What Is Actually Encrypted in a Healthcare System
Most healthcare CISOs focus their encryption conversation on EHR database encryption and HTTPS for the patient portal. The actual cryptographic attack surface in a modern health system is significantly broader:
| System | Algorithm in use | PHI exposure |
|---|---|---|
| EHR platform (Epic, Oracle Cerner, athenahealth) | RSA-2048 key wrapping, TLS with ECDSA certs | Complete patient records |
| PACS / DICOM imaging archives | RSA-based TLS; many PACS use older cipher suites | Radiology, pathology, cardiology images — stored permanently |
| HL7 FHIR APIs | TLS with RSA/ECDSA certificates | Interoperability data flows between systems and payers |
| Patient portal (MyChart, FollowMyHealth) | HTTPS with RSA/ECDSA TLS | All patient-facing PHI |
| VPN / remote clinician access | IPSec with Diffie-Hellman key exchange | Everything a clinician accesses remotely |
| Secure messaging (secure email, in-app) | S/MIME with RSA; or proprietary with RSA | Clinical communications, referral notes |
| HIE / health information exchange | XML digital signatures (RSA), TLS | Multi-organisation PHI sharing |
| Connected medical devices (IoMT) | Often RSA or weak cipher suites; some unencrypted | Vital signs, infusion pump data, implantable device telemetry |
| Backup and archive systems | RSA-wrapped AES keys | The long-term archive — the highest HNDL target of all |
The backup and archive systems deserve a separate mention. Long-term PHI archives — the exact records with 20-year retention requirements — are typically encrypted once and left alone. A Harvest Now, Decrypt Later attacker does not need to compromise your live EHR. They need to capture one backup transfer.
The FHIR Mandate Makes This Urgent Right Now
CMS's Interoperability and Prior Authorization Final Rule (CMS-0057-F, effective 2024–2027) requires most payers and providers to expose PHI via FHIR APIs to patients, third-party apps, and other payers. This is a compliance requirement — and it substantially expands the cryptographic attack surface.
Every FHIR API endpoint is a TLS connection using RSA or ECDSA certificates. Every patient authorisation token is signed with RSA or ECDSA. The interoperability mandate that regulators designed to improve care is simultaneously increasing the number of encrypted channels carrying PHI — channels that all need post-quantum migration.
5 Things Healthcare CISOs Need to Do Before 2027
-
1
Map your PHI retention schedule to your cryptographic inventory
Not all PHI is equal risk. A record with a 7-year retention window has different HNDL exposure than a paediatric mental health record with a 28-year window. Your migration prioritisation should be driven by retention schedule — start with the data that must stay confidential the longest. You cannot do this without knowing which systems hold which data types and which encryption algorithms protect them.
-
2
Audit your FHIR API and HL7 cryptographic surface
The interoperability mandate has likely added dozens of new encrypted endpoints to your environment in the last two years. Many organisations do not have a complete picture of which certificates are in use on these endpoints, who issued them, and when they expire. This is the fastest-growing part of the healthcare cryptographic attack surface — audit it first.
-
3
Address your backup and archive encryption separately
Long-term archives are the highest HNDL target in healthcare. They are also the most overlooked in cryptographic reviews — because they are not actively used, they rarely appear in security scanning. Explicitly scope your cryptographic inventory to include backup systems, tape archives, cloud cold storage, and any system that holds long-term PHI at rest.
-
4
Get ahead of your EHR vendor's migration timeline
Epic, Oracle Cerner, and the major EHR platforms will publish PQC migration roadmaps — but they will move on their schedule, not yours. Understand which cryptographic operations your EHR vendor controls (platform-level TLS, database encryption) versus which you control (network layer, VPN, backup encryption). Your migration plan needs to account for both — and the vendor timeline may not align with your HIPAA compliance obligations.
-
5
Document your quantum risk posture for your next OCR audit
OCR audits have become significantly more sophisticated. Auditors now ask about encryption key management, algorithm selection rationale, and future-proofing. Having a documented cryptographic inventory and a NIST-aligned PQC migration roadmap on file is increasingly the difference between a finding and a clean audit. Organisations that start this work in 2026 will have documentation. Those that wait will not.
Know your PHI cryptographic exposure in 48 hours
We scan your public cryptographic surface — TLS certificates, cipher suites, FHIR endpoint exposure — and deliver a risk-scored PDF report. No code access. No PHI leaves your environment.
Scan My Domain Free →What the Migration Actually Looks Like for a Health System
Post-quantum migration in healthcare is not a single project. It is a sequence of workstreams running in parallel, each with different owners, timelines, and dependencies.
The recommended approach is hybrid deployment: run classical and post-quantum algorithms simultaneously during the transition. For key exchange, this means X25519 + ML-KEM-768 in parallel. For signatures, RSA + ML-DSA together. If either algorithm holds, the communication is secure. This is the approach used by Cloudflare, Google, and Apple — and it is the only approach that maintains backward compatibility with EHR vendors, health information exchanges, and payer systems that may be on their own migration timelines.
The realistic migration sequence for a 500-bed health system looks like this:
| Phase | Workstream | Timeline |
|---|---|---|
| 1 | Cryptographic inventory — all systems, certs, keys, APIs | 4–8 weeks |
| 2 | Risk scoring by PHI retention window and sensitivity | 2–3 weeks |
| 3 | Hybrid PQC on external-facing systems (patient portal, FHIR APIs) | 3–6 months |
| 4 | VPN and remote access migration | 2–4 months |
| 5 | Internal PKI and certificate reissuance | 4–8 months |
| 6 | Backup and archive re-encryption (highest HNDL priority) | Parallel from Phase 3 |
| 7 | IoMT / medical device vendor coordination | 12–24 months (vendor-dependent) |
Total timeline for a complete migration: 18 to 36 months, depending on system complexity and vendor responsiveness. Which is precisely why 2026 is the right time to start — and 2028 is not.
The Medical Device Problem Nobody Is Talking About
IoMT (Internet of Medical Things) devices — infusion pumps, patient monitors, implantable device programmers, imaging equipment — present a unique challenge. Many run embedded firmware with RSA hardcoded and no upgrade path. The device vendor controls the cryptographic implementation, not the health system.
CISA and the FDA have both flagged medical device cryptography as an emerging risk. The FDA's cybersecurity guidance for medical devices now requires manufacturers to submit Software Bills of Materials (SBOMs) — but PQC migration plans for existing deployed devices are largely absent from regulatory requirements today.
This is not a reason to delay the rest of your migration. It is a reason to start your inventory now, so you know exactly which devices are the long-tail problem before your HIPAA auditor finds them first.
What Novaders Does for Healthcare Organisations
We implemented ML-DSA-65 (NIST FIPS 204) in our own AuthentiScan platform — one of the first production deployments on finalised post-quantum standards. We understand what the migration engineering looks like at the implementation level, not just the advisory level.
For healthcare organisations, our Quantum Ready assessment covers:
- →Full cryptographic surface scan across EHR endpoints, FHIR APIs, TLS certificates, VPN infrastructure, and backup systems
- →PHI retention mapping — risk scored by sensitivity window against NIST IR 8547 deprecation deadlines
- →FHIR API and interoperability cryptographic exposure report
- →Prioritised migration roadmap with hybrid deployment path and effort estimates per workstream
- →OCR-audit-ready documentation of your quantum risk posture and migration progress
The Starter Assessment — public surface scan of your TLS certificates, cipher suites, and FHIR-facing endpoints — is delivered within 48 hours. No PHI access. No code access. No commitment.