up:: The Human & Organizational Side MOC
PQC for Healthcare and ePHI
Post-quantum cryptography reaches healthcare through an unusual combination: patient records have to stay confidential for a lifetime, which is the longest data-confidentiality requirement most organizations will ever carry, while the regulation governing them binds three specific categories of entity rather than health data as a category, and its technical safeguards still mark encryption as an addressable implementation specification rather than a required one. The result is a sector with maximal harvest-now-decrypt-later exposure and a compliance floor that never names an algorithm.
The short version:
- HIPAA scopes by custodian. Under 45 CFR 160.103 a covered entity is a health plan, a health care clearinghouse, or a health care provider who transmits health information electronically in a covered transaction, so health data held by anyone outside that set and outside a business associate relationship falls outside the rule.
- The current Security Rule marks both encryption specifications at 45 CFR 164.312 as addressable, and the section’s amendment note is dated January 25, 2013.
- The proposed 2025 overhaul would make encryption of all ePHI at rest and in transit required, and would remove the required-versus-addressable distinction across the rule.
- That proposal deliberately declines to name a cryptographic standard, using the phrase “prevailing cryptographic standards” and stating that it is not proposing to define the phrase in regulatory text.
- It does address quantum computing, in a Request for Information and as something a regulated entity would document within its risk analysis, rather than as a control requirement.
Why is post-quantum arriving in healthcare now?
Because the confidentiality lifetime of the data has always been the trigger, and the arithmetic finally became legible. Mosca’s theorem holds that when the time data must stay secret plus the time a migration takes exceeds the time until a cryptographically relevant quantum computer arrives, the exposure is present rather than future. A diagnosis recorded today can damage someone in 40 years, which puts health records at the far end of the first variable before anyone argues about the third.
Health data also travels well beyond the institution that created it. Claims flow to payers and clearinghouses, imaging goes to remote reading services, research extracts go to academic partners, and revenue-cycle work goes to outsourced processors. Each hop is a transmission that can be recorded now and read later, and the record does not stop mattering when it arrives.
The third force is the one specific to this sector: the regulation is being rewritten. The rewrite is what turns a general argument about data lifetime into a dated compliance question, and the shape of the proposal matters more than its existence.
Who does HIPAA actually bind?
Three categories of organization, named individually. The definition at 45 CFR 160.103 reads: “Covered entity means: (1) A health plan. (2) A health care clearinghouse. (3) A health care provider who transmits any health information in electronic form in connection with a transaction covered by this subchapter.”
Source: eCFR, “45 CFR 160.103, Definitions,” ecfr.gov.
The rule extends to business associates, defined in the same section as a person who, on behalf of a covered entity, “creates, receives, maintains, or transmits protected health information for a function or activity regulated by this subchapter,” including claims processing, data analysis, utilization review, quality assurance, billing and benefit management. That extension is what pulls a large part of the health technology supply chain into scope, and it is bounded by the relationship rather than by the data.
The structural consequence is worth stating precisely, because it drives where the sector’s real exposure sits. HIPAA is scoped by custodian, not by data type. Health information held by an organization that is neither a covered entity nor acting as a business associate of one is outside the rule regardless of how medical the information is. Wellness and fitness platforms, direct-to-consumer testing services, symptom trackers and health-adjacent advertising infrastructure can hold data that looks identical to ePHI while sitting outside the Security Rule entirely, and the cryptographic obligations that follow are correspondingly different.
For a post-quantum program this matters twice over. It determines which parts of a health data flow have any encryption mandate at all, and it means a cryptographic discovery exercise scoped to the covered entity will miss the segments of the flow where the data has left the regulated perimeter.
What does the Security Rule require about encryption today?
Less than most people believe. The technical safeguards at 45 CFR 164.312 divide implementation specifications into required and addressable, and both encryption specifications sit in the second category.
| Specification | Location | Status today |
|---|---|---|
| Unique user identification | 164.312(a)(2)(i) | Required |
| Emergency access procedure | 164.312(a)(2)(ii) | Required |
| Automatic logoff | 164.312(a)(2)(iii) | Addressable |
| Encryption and decryption | 164.312(a)(2)(iv) | Addressable |
| Mechanism to authenticate ePHI | 164.312(c)(2) | Addressable |
| Integrity controls in transmission | 164.312(e)(2)(i) | Addressable |
| Encryption in transmission | 164.312(e)(2)(ii) | Addressable |
Source: eCFR, “45 CFR 164.312, Technical safeguards,” ecfr.gov.
Addressable has a specific meaning rather than an optional one. The proposed rule’s own preamble describes the existing obligation: a regulated entity “must assess whether encryption is a reasonable and appropriate safeguard in its environment,” implement it if so, and where it is not, “document why it would not be reasonable and appropriate” and implement an equivalent alternative measure if reasonable and appropriate. The obligation is to reason and document rather than to encrypt.
Two details anchor the current state. The transmission-security specification requires encryption only “whenever deemed appropriate,” and the amendment note at the end of the section reads 78 FR 5694, January 25, 2013. The technical safeguards governing patient data have stood in that form since 2013, and as of 3 September 2026 the eCFR text still reads that way.
What would the proposed Security Rule change?
The Department of Health and Human Services published a notice of proposed rulemaking on January 6, 2025, “HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information,” under RIN 0945-AA22, with a comment period that closed March 7, 2025.
Source: HHS Office for Civil Rights, “HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information,” 90 FR 898, January 6, 2025, federalregister.gov.
Two changes in it matter most for cryptography. The proposal would “remove the distinction between required and addressable implementation specifications and make all implementation specifications required, with specific, limited exceptions,” and it “proposes to require regulated entities to encrypt all ePHI at rest and in transit and proposes a transmission security standard in which regulated entities would be required to deploy technical controls to guard against unauthorized access to ePHI” in transmission. Alongside those, the proposal would require regulated entities to inventory their technology assets and map the movement of ePHI through their information systems, which is the same discipline a cryptographic bill of materials applies to cryptography specifically.
Which cryptographic standards would the proposed rule require?
None by name, and the document says so directly. The proposal requires encryption “in a manner that is consistent with prevailing cryptographic standards,” and defines that phrase only in the preamble, as “widely accepted standards for encryption and decryption that are recommended by authoritative sources and that ensure the confidentiality, integrity, and availability of ePHI at the time the regulated entity” deploys them. It then states: “We are not proposing to define prevailing cryptographic standards in regulatory text at this time.”
The published document contains no reference to a Federal Information Processing Standard, does not name AES or any other algorithm, and does not use the term crypto-agility. What it does say about algorithm quality is a floor rather than a specification: “a regulated entity using an encryption algorithm that is known to be insecure would not be in compliance with the proposed requirement to deploy an encryption algorithm that meets prevailing cryptographic standards.”
That drafting choice cuts both ways, and the ambiguity is the point worth understanding. A requirement tied to prevailing standards at the time of use moves with the field, so it does not freeze a 2025 algorithm list into regulation the way a named standard would, and in that respect it behaves like a crypto-agility requirement expressed in legal rather than architectural terms. It also supplies no verifiable floor, no parameter set, no validation requirement such as FIPS 140-3, and no mechanism by which a reviewer can establish what “prevailing” meant on a given date. Compare that with CNSA 2.0 or the NIST civilian track, both of which name algorithms and dates.
Does the proposed rule address the quantum threat?
Yes, and the form it takes is what determines its practical weight. The proposal carries a section headed “New and Emerging Technologies Request for Information,” whose first subsection is Quantum Computing, and it treats the subject seriously within that frame. It cites National Security Memorandum 10 and the joint CISA, NSA and NIST guidance “Quantum-Readiness: Migration to Post-Quantum Cryptography” of August 21, 2023, and it records that the National Committee on Vital and Health Statistics advised the Department that guidance on vulnerable cryptographic systems “is necessary to strengthen the Technical Safeguards within the Security Rule.”
The operative provision is narrower than the discussion. Under the proposal, a regulated entity “would be expected to, as part of the risk analysis, consider whether quantum computing poses a reasonably anticipated threat to the confidentiality, integrity, or availability of its ePHI and whether there is a vulnerability or predisposing condition that corresponds to that threat, and to document those considerations.”
So the quantum obligation, as proposed, is an obligation to consider and document within a risk analysis. It does not require migration to ML-KEM or ML-DSA, does not set a date, and does not require a cryptographic inventory scoped to quantum-vulnerable algorithms specifically. The Department also encourages regulated entities to adopt the joint guidance’s steps, including preparing a cryptographic inventory and discussing post-quantum roadmaps with technology vendors, in language that encourages rather than binds.
The precise reading matters because the loose version of this point circulates in both directions. The proposal is not silent on quantum, and it does not mandate post-quantum cryptography either. It asks regulated entities to think about the threat and write down that they did.
Why does patient data have such a long confidentiality lifetime?
Because the information stays true and stays sensitive. A genome does not expire, a psychiatric history does not become irrelevant, an HIV status or a reproductive-health record can affect employment, insurance and personal safety decades after the encounter that produced it, and none of it can be reissued the way a payment card can. HNDL exposure is triaged by exactly this variable, and health records sit at the extreme end of it alongside biometric identifiers and national-security communications.
There is a second multiplier specific to this sector. Health data is high-dimensional, so it is unusually re-identifiable even after identifiers are stripped, which means a de-identified extract harvested today retains value to an adversary who later obtains an auxiliary dataset. The cryptographic clock and the re-identification clock run in parallel, and the linkage keys that connect de-identified extracts back to patients are themselves long-lived secrets that rarely appear in any inventory.
Where does cryptography actually live in a health system?
Across surfaces owned by very different parties, which is why an inventory built from one layer misses most of the estate. The distinction between what a control list reports and what an inventory records is the subject of primitive versus algorithm versus protocol, and it applies with force here, because summaries of health-system security are usually written as control lists.
| Surface | What the cryptography protects | Who controls the migration |
|---|---|---|
| The electronic health record platform | data at rest, session access, audit integrity | the platform vendor, on its release cycle |
| Clinical interfaces and messaging | records moving between systems and institutions | interface standards plus both endpoints |
| Claims and payer exchange | transactions leaving the provider entirely | clearinghouses and payers |
| Imaging and diagnostic pipelines | studies moving to and from reading services | modality vendors and remote services |
| Connected medical devices | device identity, firmware signing, telemetry | device manufacturers, per medical device PQC |
| Research and analytics extracts | de-identified data and the keys that reverse it | internal data teams, usually outside security |
| Identity and access infrastructure | who can reach any of the above | identity providers and federation partners |
| Backups and archives | decades of stored records | storage platforms and retention policy |
The pattern this table describes is vendor-controlled crypto surfaces, and healthcare carries a heavier concentration of it than most sectors, because clinical software is bought rather than built and clinical devices have long field lives. A hospital’s post-quantum timeline is therefore substantially set by parties outside the hospital, which is the same dependency cryptographic supply-chain risk describes, and it is why the questions that produce useful answers are addressed to vendors as much as to internal teams.
Common misconceptions
- “HIPAA requires encryption.” The current Security Rule marks both encryption specifications as addressable, which obliges an entity to assess and document rather than to encrypt.
- “HIPAA covers health data.” It covers health plans, clearinghouses, providers who transmit electronically, and their business associates. The same information held outside those relationships falls outside the rule.
- “The 2025 proposal fixes the quantum problem.” As proposed, quantum computing appears in a Request for Information and as a documented consideration inside the risk analysis, without an algorithm requirement or a date.
- “AES-256 at rest answers the question.” That is a statement about one primitive and one key size at one layer, and it says nothing about key management, transport, or the interfaces through which the same data is readable.
- “De-identified extracts are outside the risk.” High-dimensional health data re-identifies well, and the keys that deliberately reverse de-identification are long-lived secrets in their own right.
- “Our EHR vendor handles cryptography.” The platform covers one surface. Claims exchange, imaging, devices, research extracts, identity and archives each sit with different parties.
Questions people ask
Does HIPAA require encryption of ePHI today? No. 45 CFR 164.312(a)(2)(iv) and (e)(2)(ii) are both addressable, which requires the entity to assess whether encryption is reasonable and appropriate, implement it if it is, and otherwise document why and implement an equivalent alternative if reasonable and appropriate.
Has the proposed Security Rule been finalized? As of 3 September 2026, the eCFR text of 164.312 still marks encryption as addressable and carries an amendment note dated January 25, 2013, which is what a reader should check rather than relying on any secondary summary.
Which algorithms would the proposed rule require? It names none. It requires encryption consistent with “prevailing cryptographic standards” and states that it is not proposing to define that phrase in regulatory text.
Why is healthcare considered high harvest-now-decrypt-later exposure? Because the confidentiality lifetime of a medical record approaches a human lifespan, which is the variable Mosca’s theorem weighs against migration time and the arrival of a capable quantum computer.
Are health technology platforms outside HIPAA really unregulated? They are outside the HIPAA Security Rule when they are neither a covered entity nor a business associate, which is a statement about that rule specifically. Other regimes may apply, and those obligations vary by jurisdiction and by the nature of the service.
Does a business associate agreement transfer the cryptographic obligation? It extends the rule’s obligations to the business associate. It does not remove the covered entity’s own obligations, and it does not give either party visibility into the other’s cryptography without a separate mechanism such as a CBOM.
What is the first thing a post-quantum discussion with a clinical vendor should establish? Which cryptography the product controls versus inherits, and whether post-quantum support is available, default, or absent in a named release. Those are the same questions the vendor-facing view describes from the other side of the table.
Do connected medical devices change the timeline? They extend it, because field lives are long and firmware update paths are constrained. The specifics are covered in PQC in medical devices.
Is hybrid key exchange relevant to a hospital? It is the deployed form of post-quantum key establishment in TLS today, and whether a given connection uses it depends on both endpoints, per hybrid key exchange.
Everything here is the map, given freely. When a health system needs its own cryptography inventoried across the platforms, devices and partners that actually hold patient data, that’s the work I do.
Last verified 2026-09-03 · Maintained by Addie LaMarr, LaMarr Labs.