Encryption for Telemedicine: In Transit, at Rest, End-to-End

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

Encryption is the rare compliance control that pays for itself twice: it satisfies a Security Rule safeguard, and it can make a stolen laptop or a lost backup legally a non-event instead of a 60-day notification campaign. Yet the published OCR settlements — $1,040,000 for one stolen unencrypted MacBook, $2.5 million for a laptop with 1,391 records — show how often healthcare organizations get it wrong, and telemedicine multiplies the places where patient data sits and moves. This article is for the founder, product manager, or hospital IT lead who needs to answer four questions precisely: what must be encrypted in transit, what must be encrypted at rest, when end-to-end encryption is actually required, and who should hold the keys. You will leave with the rule citations, the NIST standards by number, the arithmetic, and a one-page checklist your team can run against a real build.

Three questions, then a fourth

Conversations about telemedicine encryption go in circles because three different questions wear the same word. It is worth separating them once, plainly, before touching any regulation.

In transit asks: while data moves between two machines — patient app to server, server to clinician, service to service — can someone in the middle read it? The protection is transport encryption: the data is scrambled for each hop of the journey and unscrambled at each trusted stop, the way a courier carries a sealed pouch between offices that each hold a key.

At rest asks: while data sits on a disk — a recordings bucket, a database, a backup tape, a laptop — can someone who takes the disk read it? The protection is storage encryption: the file is scrambled on the medium itself, so possession of the hardware is not possession of the data.

End-to-end asks something stricter than either: can anyone other than the sender and the intended recipient read it — including the servers that carry it, including you, the platform operator? End-to-end encryption (E2EE) means the scrambling key exists only on the participants' devices, so every machine in the middle forwards sealed envelopes it cannot open.

The fourth question hides inside the other three, and it decides whether any of them actually protect anything: who holds the keys? An encryption key is the small secret that unscrambles the data. Encrypting a backup and storing the key on the same drive is locking the door and taping the key to it — the math works, the protection does not. Every section below ends at this question, and US health-privacy law, as we will see, makes key custody the exact line between "breach" and "no breach."

Figure 1. The three encryption layers on one telemedicine consult. Transport encryption (DTLS-SRTP, TLS) covers every hop; storage encryption covers everything that lands on disk; end-to-end encryption, when used, seals media past your own servers — and past your recording and AI features too.

What HIPAA actually says about encryption — all two lines of it

The Health Insurance Portability and Accountability Act (HIPAA) protects health information that can be tied to a person — protected health information, or PHI — and its Security Rule governs the electronic kind (ePHI). For the full architecture of the law, start with HIPAA in plain English for product teams; here we need only the two implementation specifications that mention encryption.

The first sits under the access-control standard: "Implement a mechanism to encrypt and decrypt electronic protected health information" (45 CFR §164.312(a)(2)(iv)). In practice this is the at-rest requirement — it concerns ePHI your systems maintain. The second sits under the transmission-security standard, which requires you to "guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network" (§164.312(e)(1)), with an encryption specification underneath it: "Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate" (§164.312(e)(2)(ii)).

Both specifications are labelled addressable, and the word trips up every team that meets it. Addressable does not mean optional. Under §164.306(d), you must assess whether the safeguard is reasonable and appropriate for your environment; if it is, you implement it, and if you decide it is not, you must document why and implement an equivalent alternative. For a telemedicine platform — patient data crossing the public internet to people's homes, recordings accumulating in cloud storage — try writing the memo that argues encryption is not reasonable and appropriate. No serious reviewer will accept it, and the Office for Civil Rights (OCR), the HHS agency that enforces HIPAA, has settled for seven figures with organizations that documented the need for encryption and then failed to finish the rollout: Lifespan paid $1,040,000 in 2020 after exactly that sequence ended with an unencrypted laptop stolen from an employee's car.

Notice what the rule text does not say. It names no algorithm, no key length, no protocol — not AES, not TLS, nothing. HIPAA defines encryption only as "the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key" (§164.304). The regulation was written to outlive any particular cipher. The specific technologies enter through a different door, and that door is the most useful thing in this article.

One more thing the current rule does not say: "required." That is changing. The proposed 2026 HIPAA Security Rule update (Notice of Proposed Rulemaking, 90 FR 898, January 6, 2025) would abolish the addressable category and make encryption of ePHI at rest and in transit its own required standard — proposed §164.312(b) — with narrow exceptions, such as a patient who asks to receive their own data unencrypted. As of June 11, 2026 the update remains a proposal, not law; OCR's regulatory agenda targeted spring 2026 and that window has passed without a final rule. We track the whole change set, requirement by requirement, in the 2026 Security Rule article. The practical posture: build as if encryption were already mandatory, because for every customer questionnaire and every auditor you will meet, it effectively is.

The breach safe harbor: the one place encryption buys legal relief

HIPAA's Breach Notification Rule turns on a single defined term. A breach is an impermissible acquisition, access, use, or disclosure of unsecured PHI (45 CFR §164.402) — and "unsecured" means PHI that has not been rendered "unusable, unreadable, or indecipherable to unauthorized persons" through a technology specified by HHS guidance. Data that was so secured is outside the definition. Lose it, and there is no breach to report: no letters to patients within 60 days (§164.404), no notice to HHS, no media notice for incidents touching 500 or more people (§164.406). Practitioners call this the encryption safe harbor, and it is the only mechanism in HIPAA that converts a security control directly into legal protection.

The HHS guidance (issued under §13402(h)(2) of the HITECH Act, the 2009 law that added breach notification to HIPAA) is where the actual technology names live, so cite it precisely:

• Data at rest is secured if encrypted consistent with NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices — full-disk, volume, or file/folder encryption done to the standard's processes.
• Data in motion is secured if encrypted per NIST SP 800-52 (TLS), SP 800-77 (IPsec VPNs), or SP 800-113 (SSL VPNs), or another process that is FIPS 140-2 validated — FIPS 140 being the US government's certification program for cryptographic modules.
• The condition that decides everything: the safe harbor holds only if "the confidential process or key that might enable decryption has not been breached," and HHS directs that decryption tools be stored on a device or at a location separate from the data they protect. Encrypted drive plus key on the same drive equals unsecured PHI.
• Destruction is the other path: electronic media sanitized per NIST SP 800-88 also takes data out of "unsecured" — relevant when you retire recording-store disks. Redaction explicitly does not count.

Two freshness notes a 2026 reader should have. The guidance still cites FIPS 140-2; the validation program has moved on — FIPS 140-2 certificates stop being accepted for new federal procurements on September 21, 2026, with FIPS 140-3 the successor — so new builds should look for 140-3 validation even though the HHS text lags. And NIST opened public comment in May 2026 on revising SP 800-52 Rev. 2 itself, signalling a stronger tilt toward TLS 1.3. Neither wrinkle weakens the safe harbor; both reward teams that read version numbers.

Figure 2. The breach safe harbor as a decision tree. The technology question (NIST-conformant encryption?) and the custody question (keys uncompromised and stored separately?) must both pass — then a loss event stays an internal incident instead of a notification campaign.

The arithmetic of a lost drive

Walk one scenario with numbers, because the safe harbor is abstract until you price it. Suppose a backup drive holding 20,000 patient records goes missing — roughly the Lifespan incident's size.

Path A — encrypted to the guidance. The drive carries XTS-AES full-disk encryption per NIST SP 800-111; the key lives in a cloud key-management service, never on the drive. The data is not unsecured PHI. Result: an internal security incident, a police report, a documented risk assessment. Notifications required: zero.

Path B — unencrypted. The Breach Notification Rule applies in full: individual notices without unreasonable delay and no later than 60 days, HHS notice, media notice because 20,000 > 500. Then enforcement risk: Lifespan's settlement for its 20,431-record laptop was $1,040,000 — divide it out and the settlement alone is $1,040,000 ÷ 20,431 ≈ $51 per record, before the mailing, the call center, the credit monitoring, and the corrective-action plan. CardioNet's 2017 settlement ran $2,500,000 for 1,391 records — $2,500,000 ÷ 1,391 ≈ $1,800 per record — proof that penalties do not scale down kindly for small incidents. For wider context, IBM's 2025 Cost of a Data Breach report puts the average healthcare breach at $7.42 million, the costliest industry for the fourteenth straight year.

The asymmetry is the lesson. Path A's price is an encryption flag and key discipline that, as we will compute below, costs on the order of dollars per month. Path B's price has six zeros. Encryption is not just a safeguard; it is the cheapest insurance policy HIPAA sells — but only with the keys held separately, which is why key management gets its own section.

In transit: the call is the easy part — finish the rest

Here is the good news the vendor listicles bury: for the live video consult itself, a competently built WebRTC platform is already encrypted, with no opt-out to misconfigure.

WebRTC — the real-time engine inside every major browser and most telemedicine apps — mandates encryption at the standards level. The IETF's WebRTC security architecture (RFC 8827) requires all media to run over SRTP, the Secure Real-time Transport Protocol (RFC 3711), with keys negotiated through DTLS-SRTP (RFC 5764), a handshake derived from the same TLS family that protects websites. There is no plaintext media mode in a compliant WebRTC stack. Audio and video packets leave the patient's device scrambled with AES and arrive scrambled at the next hop; signaling — the "let's set up a call" messages — and your REST APIs ride ordinary HTTPS/TLS. For the protocol mechanics we keep one canonical explainer in the Video Streaming section: WebRTC security: DTLS and SRTP; this article stays on the compliance layer.

What a compliance reader must understand is the shape of that encryption: it is hop-by-hop, not end-to-end. A two-person consult can flow peer-to-peer, encrypted device to device. But the moment your product uses a media server — a Selective Forwarding Unit (SFU), the standard component that receives each participant's stream and forwards it to the others — the SFU performs the DTLS handshake itself. It decrypts each incoming stream, handles it as plaintext in memory, and re-encrypts it toward each recipient. Your server can read the media. That is not a defect; it is what makes recording, transcription, and group calls work. It simply means the SFU sits squarely inside your PHI boundary: it needs the same hardening, the same audit logging, and — if a vendor runs it — a signed Business Associate Agreement, the contract HIPAA requires before any vendor touches PHI. A TURN relay, by contrast — the fallback server that forwards packets when home and hospital firewalls block direct paths — never completes the media handshake; it shovels still-encrypted packets and cannot read them. Your data-flow map should say so, because the two servers carry different risk.

Transit encryption fails in telemedicine builds at three unglamorous spots, none of them the call:

The terminated edge. TLS from the patient's browser is terminated at a load balancer, and traffic continues to internal services as plaintext on the theory that "it's our private network." The proposed 2026 rule's mandatory-encryption standard does not carve out your VPC, and neither does a competent auditor. Encrypt service-to-service links (TLS or mutual TLS) or document a compensating control you actually believe.

The version floor. NIST SP 800-52 Rev. 2 — the standard the safe harbor points to for TLS — sets TLS 1.2 as the minimum with approved cipher suites and requires TLS 1.3 support on government-facing servers since January 2024. Telemedicine platforms still answering on TLS 1.0/1.1 fail vendor security reviews weekly. Set the floor at 1.2, prefer 1.3, and revisit when NIST's 2026 revision of SP 800-52 lands.

The side channels. The consult is encrypted; the appointment-reminder SMS, the email with the visit summary, and the webhook to your analytics tool are not, or not under your control. Classic SMS and email are not encrypted end to end, which is one reason patient communications carry their own consent rules and why PHI does not belong in a push-notification payload at all.

At rest: where telemedicine products actually fail

A video consult that is never stored leaves nothing to encrypt at rest. Real products store plenty. The honest exercise is an inventory — the same ePHI map the 2026 update would make mandatory — and in a typical telemedicine platform it reads: the recordings bucket, the transcripts database, chat history and shared files, the signaling and scheduling database (names, appointment times, complaint text — all PHI), logs (which should not contain PHI, but check), backups of all of the above, and the laptops and phones of anyone who can export any of it. The pattern in OCR's enforcement history is monotonous: the production database was encrypted; the thing that walked away was a laptop, a backup, or a forgotten secondary store.

Figure 3. The at-rest inventory for a typical telemedicine platform. The consult is ephemeral; these seven stores are not. Each box needs an encryption mechanism, a key source, and an owner — the diagram is the audit answer.

Mechanically, modern storage encryption is the cheapest control you will ever deploy. Current CPUs encrypt AES at multiple gigabytes per second per core in hardware; cloud object stores encrypt new objects by default (AWS S3 has since January 2023); managed databases enable encryption with a checkbox at no added storage cost. Run the numbers for a mid-size platform: 1,000 recorded consults per day at 20 minutes and 1.5 Mbps is 20 × 60 s × 1.5 Mbit/s = 1,800 Mbit ≈ 225 MB per consult, so 1,000 × 225 MB = 225 GB of new recordings per day, call it 6.75 TB a month. Encrypting all of it server-side with a customer-managed key costs roughly the key ($1/month in the major clouds) plus per-request key operations (about $0.03 per 10,000) — order of a few dollars a month against a storage bill in the hundreds. "Encryption is too expensive" stopped being an argument years ago; what remains expensive is the discipline around it.

Three at-rest distinctions separate a checkbox from actual protection:

Bucket-default is necessary, not sufficient. Server-side encryption protects you if someone steals the cloud provider's disks — the least likely attack on the list. It does nothing against your own leaked credentials, an over-broad IAM role, or a signed URL that never expires, because the storage service helpfully decrypts for anyone authorized. Encryption at rest must travel with access control and audit logging; the trio is one control with three legs.

The safe harbor follows NIST, not the checkbox. For the devices that actually get lost — laptops, phones, USB drives — SP 800-111-consistent encryption means full-disk or file-level encryption with managed keys: FileVault/BitLocker enforced by MDM (mobile device management) policy, not "we told staff to turn it on." Lifespan's failure was precisely the gap between policy and enforcement.

Backups and exports inherit the requirement. A nightly database dump to an unencrypted second bucket, a support engineer's local copy, a data-science export "just for the demo" — each is a new at-rest store with no key discipline. If the risk analysis says data lands somewhere, encryption and key custody land there too.

Retention closes the loop: encrypted data you no longer need is still risk. When recordings age out of your retention schedule, destroy them to NIST SP 800-88 — and note the elegant shortcut called crypto-erase: destroy every copy of the key, and a mountain of ciphertext becomes noise without touching a single object.

End-to-end: when transport encryption is not enough — and what E2EE costs you

Now the question the marketing pages muddle. Every serious telemedicine platform encrypts in transit and at rest. End-to-end encryption is a different, stricter property: the platform itself cannot read the media. Keys are generated and held on the participants' devices; the SFU forwards opaque frames (in modern WebRTC, via encoded-transform APIs with a scheme like SFrame, RFC 9605); your servers, your cloud, your subpoenaed-or-breached infrastructure see ciphertext only.

State the regulatory fact plainly, because half the internet gets it wrong: HIPAA does not require end-to-end encryption. The Security Rule's transmission-security standard requires guarding data in transit, which transport encryption satisfies; the proposed 2026 update strengthens that requirement and still does not mandate E2EE. When a vendor page or a listicle says "HIPAA requires end-to-end encryption," it is almost always using "end-to-end" loosely to mean "encrypted in transit everywhere" — a confusion worth resisting, because the real E2EE decision has heavy product consequences. (The reverse confusion also circulates: "Zoom is encrypted, so it's compliant." Encryption was never the issue; the BAA was. "Encrypted" and "compliant" are different properties — our section repeats this on purpose.)

The consequence that matters: E2EE and server-side features are mutually exclusive by construction. A server that cannot read media cannot record it for the clinical chart, cannot transcribe it, cannot caption it for accessibility, cannot run an AI scribe, cannot composite a multi-party recording, and cannot let a supervisor audit a session. Every E2EE telehealth design therefore either drops those features, moves them onto the endpoint devices (client-side recording with its own custody problems), or punches deliberate holes ("the recording bot is a silent E2EE participant holding keys") that demand honest documentation, because a hole you do not document is a hole an auditor finds. There are verticals where the trade is right — high-sensitivity behavioral health with no recording requirement is the canonical case — and the full decision framework, including group-key management with MLS (RFC 9420), lives in end-to-end encryption in telehealth: when you need it and what it costs. The rule of thumb to carry out of this article: choose E2EE because your threat model says the platform operator must be outside the trust boundary — never because a blog post said HIPAA demands it.

Key management: the question that decides the other three

Every layer above reduces to key custody. The breach safe harbor's load-bearing clause is about keys. The difference between transport encryption and E2EE is who holds keys. The difference between an encrypted bucket and a secure one is who can call the key. NIST maintains an entire key-management bible (SP 800-57 Part 1) — here is the telemedicine-sized portion.

Use envelope encryption, the pattern every cloud KMS implements. A key-management service (KMS) is a hardened, audited service whose root keys never leave validated hardware. Each recording or row gets its own data key; the data key encrypts the object, and the KMS root key encrypts the data key, which is stored alongside the ciphertext like a sealed envelope only the KMS can open. Decryption requires an authorized, logged KMS call — which means key access produces exactly the audit trail the Security Rule's audit controls expect, and revoking one role's KMS permission instantly revokes its access to every object that role could otherwise fetch.

Keep keys and data in different failure domains. That is the HHS separation requirement translated into architecture: the KMS is a separate service with separate credentials; the backup drive's key is not on the backup drive; the database password and the disk-encryption key do not live in the same secrets file. One compromise should never yield both ciphertext and key.

Decide who controls the root key — deliberately. Provider-managed keys (the cloud's default) are fine for most stores. Customer-managed keys (CMK/BYOK — you create and control the key the cloud uses) add revocation power and a cleaner audit story, and hospital procurement increasingly asks for them. Holding keys entirely outside the cloud, or on patient devices (E2EE), is the far end of the spectrum — maximum custody, maximum operational weight. Place each store on that spectrum on purpose, and write the placement down; "who can decrypt the recordings, exactly?" is a question a compliance architecture must answer in one sentence.

Rotate and retire on a schedule. Envelope encryption makes rotation cheap — re-encrypt data keys, not terabytes of media. Annual root-key rotation is the conventional floor; crypto-erase (destroy the keys) is the exit for expired data; and an incident response plan should treat "key material possibly exposed" as its own scenario with its own runbook, because a breached key silently converts every safe-harbored store back into unsecured PHI.

Figure 4. Envelope encryption and the custody spectrum. The KMS opens sealed data keys; data keys open objects; and the safe harbor lives or dies on keys and data never being taken together.

The map on one page

The table compresses the article's thesis: the rows are independent controls answering different threats, the safe harbor pays out only when the technology row and the key row both hold, and the only row HIPAA never demands is the one most loudly advertised.

The mistakes we keep finding

A short failure gallery from real telemedicine reviews — each one a working product with a true sentence ("we use encryption") hiding a false one ("therefore the data is protected").

The encrypted bucket with the eternal URL. Recordings server-side encrypted, then shared via signed URLs with no expiry, pasted into support tickets and EHR notes. The encryption never mattered; the URL is the key, and it is in plaintext everywhere. Expire URLs in minutes, log every fetch.

TLS to the front door, plaintext behind it. Grade-A TLS at the load balancer, unencrypted gRPC between services, "it's a private network." One misconfigured peering or one compromised pod and the consult transcript crosses readable. Mutual TLS inside the boundary, or a documented compensating control.

Keys in the same drawer. Database encrypted; key in a config file in the same repository as the backup scripts; backup and config land on the same drive. The safe-harbor memo writes itself — in the wrong direction.

"It's encrypted" as the whole answer. The vendor's consumer tier encrypts beautifully and still has no BAA covering your use; the analytics SDK ships PHI over faultless TLS to a company that must never receive it. Encryption answers "can outsiders read it in flight or at rest?" — it never answers "was this party allowed to have it?"

The unmanaged laptop. Everything server-side perfect; a clinician exports a recording for a case review onto a personal machine with no disk encryption. CardioNet, Lifespan — the pattern is twenty years old. MDM-enforced full-disk encryption on every device that can touch ePHI, because policy without enforcement lost Lifespan a million dollars.

Where Fora Soft fits in

Fora Soft has built video software since 2005 — telemedicine, video conferencing, streaming, surveillance, e-learning — and encryption architecture is where our compliance work and our WebRTC work meet. In our telemedicine builds the controls in this article are design inputs, not retrofits: DTLS-SRTP media planes with TLS-everywhere service meshes behind them, recording pipelines that envelope-encrypt before the first byte lands in storage, KMS layouts where key custody is separated and logged from day one, and E2EE only where the product's threat model genuinely calls for it — with the recording and AI trade-offs put in front of the client before a line is written. If you are scoping a platform or retrofitting one against the coming mandatory-encryption baseline, talk to our telemedicine team.

What to read next

• The 2026 HIPAA Security Rule update — what changed and what it means for video
• End-to-end encryption in telehealth: when you need it and what it costs
• Recording clinical sessions: when, how, and the compliance tension

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your hipaa encryption requirements plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Telemedicine Encryption Checklist — One page: the in-transit checks, the at-rest inventory, the key-custody rules, and the breach safe-harbor conditions — with 45 CFR and NIST citations.

References

1. 45 CFR §164.312 — Security Rule technical safeguards: access control encryption (a)(2)(iv), transmission security (e)(1), transmission encryption (e)(2)(ii). eCFR, read 2026-06-11. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 Tier 1.
2. 45 CFR §164.304 — Definitions: "encryption." eCFR. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.304 Tier 1.
3. 45 CFR §164.306(d) — Flexibility of approach: addressable implementation specifications. eCFR. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.306 Tier 1.
4. 45 CFR §§164.402, 164.404, 164.406 — Breach Notification Rule: "unsecured PHI" definition, 60-day individual notice, media notice. eCFR. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D Tier 1.
5. HHS — Guidance to Render Unsecured Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals (HITECH §13402(h)(2); NIST SP 800-111 at rest; SP 800-52/800-77/800-113 or FIPS 140-2-validated in motion; key separation; SP 800-88 destruction). Read 2026-06-11. https://www.hhs.gov/hipaa/for-professionals/breach-notification/guidance/index.html Tier 1.
6. HHS OCR — HIPAA Security Rule NPRM, "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information," 90 FR 898, January 6, 2025 (proposed §164.312(b) mandatory encryption; status: proposed as of 2026-06-11). https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information Tier 1.
7. IETF RFC 8827 — WebRTC Security Architecture (mandatory DTLS-SRTP/SRTP for media). https://datatracker.ietf.org/doc/html/rfc8827 Tier 1.
8. IETF RFC 3711 — The Secure Real-time Transport Protocol (SRTP); RFC 5764 — DTLS Extension for SRTP key establishment. https://datatracker.ietf.org/doc/html/rfc3711 · https://datatracker.ietf.org/doc/html/rfc5764 Tier 1.
9. IETF RFC 9605 — Secure Frame (SFrame) for end-to-end media encryption; RFC 9420 — Messaging Layer Security (MLS). https://datatracker.ietf.org/doc/html/rfc9605 · https://datatracker.ietf.org/doc/html/rfc9420 Tier 1.
10. NIST SP 800-52 Rev. 2 — Guidelines for TLS Implementations (TLS 1.2 minimum, TLS 1.3 support; May 2026 public-comment notice on revision, comments through 2026-07-10). https://csrc.nist.gov/pubs/sp/800/52/r2/final · https://www.nist.gov/news-events/news/2026/05/nist-requests-public-comments-sp-800-52-rev-2-guidelines-selection Tier 1.
11. NIST SP 800-111 — Guide to Storage Encryption Technologies for End User Devices. https://csrc.nist.gov/pubs/sp/800/111/final Tier 1.
12. NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management; NIST SP 800-88 Rev. 1 — Guidelines for Media Sanitization. https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final · https://csrc.nist.gov/pubs/sp/800/88/r1/final Tier 1.
13. NIST CMVP — FIPS 140-3 Transition (FIPS 140-2 certificates move to the historical list 2026-09-21). https://csrc.nist.gov/projects/fips-140-3-transition-effort Tier 1.
14. HHS OCR — "Lifespan Pays $1,040,000 to OCR to Settle Unencrypted Stolen Laptop Breach," July 2020 (20,431 individuals; failure to implement planned encryption). https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/lifespan/index.html Tier 2.
15. HHS OCR — CardioNet resolution agreement, $2.5M, April 2017 (1,391 individuals; stolen unencrypted laptop; draft-only policies). Via HHS enforcement archive / HIPAA Journal summary. https://www.hipaajournal.com/wireless-health-services-provider-settles-hipaa-violations-ocr-2-5-million-8780/ Tier 2 (agency action reported).
16. HHS — Cloud computing guidance (no-view vendors holding encrypted ePHI without keys are business associates). https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html Tier 2.
17. IBM — Cost of a Data Breach Report 2025 (healthcare average $7.42M; 279-day identify-and-contain). https://www.ibm.com/reports/data-breach Tier 5.
18. The HIPAA Journal — "HIPAA Encryption Requirements – 2026 Update" (competitor reference; correct on addressable status, thin on telemedicine specifics — overridden where it implies AES is a HIPAA-named standard: HIPAA names no cipher; NIST guidance supplies the technologies). https://www.hipaajournal.com/hipaa-encryption-requirements/ Tier 7 (competitor reference only).

Where lower-tier sources disagreed with rule text, the rule text won: claims that "HIPAA requires end-to-end encryption" (assorted vendor pages) are contradicted by §164.312(e) and the NPRM, which require transmission security, not E2EE; claims that "HIPAA requires AES-256" are contradicted by §164.304's technology-neutral definition — AES strengths enter via NIST SP 800-111/FIPS validation, with AES-128 the approved floor and AES-256 common practice.