End-to-End Encryption in Telehealth: When You Need It and What It Costs

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

Why this matters

If you are building or buying a telehealth platform, "end-to-end encryption" is a phrase that shows up in security questionnaires, sales decks, and the occasional anxious board meeting — usually with more heat than precision. Some teams ship it when they did not need it and quietly lose their AI scribe and their recordings. Others claim it in marketing when what they actually have is ordinary transport encryption, which is a misrepresentation a security reviewer or regulator can catch. This article is for founders, product managers, CTOs, and compliance leads who need to decide — clearly and defensibly — whether their product needs true E2EE, what they give up if they turn it on, and how to talk about it honestly. It is the decision companion to the layer-by-layer mechanics in securing the video pipeline end to end and the encryption deep-dive in encryption in transit, at rest, and end to end.

Two kinds of encryption, and why the difference is the whole article

Almost every confused conversation about telehealth encryption comes from blurring two different things. Pin them apart and the rest is easy.

The first is transport encryption, also called encryption in transit. It protects data while it travels between two points on a network, then the data is decrypted at each stop along the way. Think of it as an armored truck driving between buildings: the cash is safe on the road, but it is unloaded, counted, and reloaded at every depot it passes through. In a video call, the "depots" are your servers — the relay that forwards packets and, critically, the media server that mixes a group call. Those servers can see the decrypted audio and video, because they have to handle it. That is normal, and for most telehealth it is fine.

The second is end-to-end encryption (E2EE). It protects data the entire way from the sender to the final recipient, and nothing in the middle can read it — not the relay, not the media server, not the company that runs them. The armored truck is replaced by a locked box to which only the patient and the clinician hold keys; every depot can carry the box and see the shipping label, but none can open it. Your own servers become couriers that move ciphertext they cannot decode.

The single sentence that captures the difference: transport encryption protects data from outsiders on the network; E2EE protects data even from the platform itself. That is the entire decision. You add E2EE when "even we cannot see it" is a property you specifically need — and you live with the consequences of your own servers going blind.

Figure 1. Transport encryption protects each hop but the media server in the middle sees plaintext; end-to-end encryption keeps the call readable only at the two endpoints, so the server forwards ciphertext it cannot open.

What HIPAA actually requires — and what it does not

Here is the fact that surprises most teams: HIPAA does not require end-to-end encryption. It does not even use the phrase.

The U.S. rule that governs electronic patient data, the HIPAA Security Rule, lists encryption as an addressable specification for protecting Protected Health Information — PHI, meaning any health data tied to an identifiable person — both while it moves (45 CFR §164.312(e), transmission security) and while it sits on disk (§164.312(a)(2)(iv)). "Addressable" does not mean optional; for PHI crossing the public internet it is effectively mandatory. But the rule is technology-neutral and risk-based: it tells you to protect PHI in transit with reasonable encryption, not which encryption, and certainly not that the protection must extend end to end.

In practice that means the ordinary encryption built into every modern video call already clears the bar. WebRTC — the technology browsers and apps use for real-time calls — encrypts all media by default with DTLS-SRTP, a transport-level scheme with no plaintext option (RFC 8827). That satisfies the transmission-security safeguard for the media on the wire. HHS's own telehealth guidance reinforces the point: it encourages providers to enable available encryption and to run a risk analysis, framing strong encryption as a recommended control to weigh — not a mandate to deploy E2EE on every consult.

Even the proposed tightening of the rule keeps this distinction. The 2026 update to the Security Rule — a Notice of Proposed Rulemaking (90 FR 898, RIN 0945-AA22, published 2025-01-06) — would remove the "addressable" label and make encryption flatly required, but it still does not mandate end-to-end encryption specifically. As of 2026-06-14 it remains a proposal, not final law, so confirm its status with counsel before relying on it. The takeaway is stable either way: transport encryption is the floor HIPAA cares about; E2EE is a ceiling you reach for deliberately.

One more separation, because it trips up nearly everyone. Encryption — of any kind — is not the same as compliance. A perfectly E2EE call to a vendor that never signed a Business Associate Agreement (BAA), the contract a company must sign before it is allowed to handle PHI, is still a violation. E2EE changes who can read the data; it does not change who is allowed to be involved. We cover that contract in the Business Associate Agreement explained.

How end-to-end encryption actually works in a video call

You do not need to implement this yourself to make the decision, but knowing the moving parts keeps the cost discussion honest.

A normal WebRTC call encrypts media for transport, then the media server decrypts it to do its job — routing each person's stream to everyone else. To make the call end-to-end encrypted, you add a second, inner layer of encryption that the server has no key for. The patient's app encrypts each video frame a second time before it leaves the device; the clinician's app decrypts it on arrival; the server in between forwards the doubly wrapped frames and can read only the routing information on the outside, never the picture inside.

The browser hook that makes this possible is the WebRTC Encoded Transform API (you may also hear its earlier name, Insertable Streams). It lets your code reach into the pipeline after a frame is encoded but before it is sent, add the extra encryption, and reverse it on the far side. The encryption format itself is increasingly standardized as SFrame (Secure Frame, RFC 9605, 2024) — a scheme designed exactly for this, so the media server can still read the metadata it needs to route a group call while the media stays sealed. For group sessions, the keys are handed out and rotated with Messaging Layer Security (MLS, RFC 9420, 2023), a standard for giving a group a shared secret that stays safe even as people join and leave.

The catch is reach. As of 2026, the Encoded Transform API is fully available in Chrome and Chromium-based browsers, but Safari and Firefox support is incomplete, with Firefox still working toward the current RTCRtpScriptTransform form of the API. For a consumer telehealth product where patients arrive on whatever device they own — including iPhones, where the browser engine is Safari's — that gap is not academic. It means either a native app, a fallback path for unsupported browsers, or accepting that some patients cannot get the E2EE experience. That is the first hidden cost, and we will total them up shortly.

When you actually need E2EE

E2EE is the right call when the threat you are defending against includes your own infrastructure or provider being compromised or compelled — and when the data is sensitive enough that "the platform can technically see it" is itself a problem. In telehealth, that lands on a short, specific list.

Highly sensitive behavioral and substance-use care. A psychotherapy session or an addiction-treatment consult is among the most damaging data to leak. Substance-use-disorder records carry their own heightened federal regime, 42 CFR Part 2, on top of HIPAA. When a breach would be catastrophic and the clinical content is this intimate, minimizing the number of parties that can see the media — down to just the two endpoints — is a defensible, often expected, design choice. Mental-health platforms are the most common place E2EE genuinely earns its cost; we go deeper in mental and behavioral health telemedicine.

Infrastructure you do not fully control or trust. If parts of your media path run on hardware or in jurisdictions you cannot vouch for, E2EE lets you use that infrastructure without exposing PHI to it. The server forwards sealed frames; a compromise of that server leaks ciphertext, not consultations.

A contractual or customer mandate. Enterprise health systems, certain government buyers, and some international customers will require E2EE in a procurement contract regardless of what HIPAA says. Here the requirement is commercial, not regulatory — but it is just as binding on your roadmap.

Reducing your own breach blast radius and insider risk. E2EE means a rogue employee or an attacker who gets into your servers still cannot watch consultations. For a small team that cannot staff a large security organization, shrinking what the servers can ever see is a legitimate way to shrink risk.

If none of these apply — and for a great deal of primary care, urgent care, and routine follow-up, none do — transport encryption plus a properly guarded PHI boundary is the appropriate, compliant choice. Reaching for E2EE you do not need is not free diligence; it is a feature tax you pay forever, as the next section shows.

Figure 2. A decision rule: most routine care is well served by transport encryption; E2EE earns its cost for the most sensitive sessions, untrusted infrastructure, or a contractual mandate — and only if you can live without server-side features.

The cost: what end-to-end encryption takes away

E2EE's strength is also its bill. Because the server cannot read the media, every feature that depends on the server reading the media stops working. This is not a configuration tax you pay once; it is a permanent set of capabilities you trade away.

Server-side recording stops. The usual way to record a consultation for the medical record is to let the media server write the decrypted stream to storage. Under E2EE the server only ever has ciphertext, so it has nothing to record. For a product that must keep recordings — and many must, for the clinical record or for legal reasons — this is the single biggest consequence. We return to how teams work around it below; the broader recording tension is covered in recording clinical sessions: the compliance tension.

Live transcription and AI features stop. A live caption track, an ambient AI scribe that drafts the clinical note by listening to the visit, real-time translation for an interpreter — all of these read the audio on the server. Turn on E2EE and they go dark, because the server hears only noise. If your roadmap includes the AI scribe described in ambient clinical documentation, it is on a collision course with full E2EE, and you must choose. (There is a narrow exception: AI that runs entirely on the patient's or clinician's own device, inside the encryption, rather than on your server.)

Browser reach shrinks. As covered above, the Encoded Transform API is a Chrome-first feature in 2026. Supporting E2EE for everyone usually means shipping native mobile apps and a graceful fallback for unsupported browsers — more platforms to build, test, and maintain.

Key management becomes your problem. E2EE is only as good as its keys. You now have to distribute keys to the right endpoints, rotate them as participants join and leave a call, and — the hard part for healthcare — decide what happens when a key is lost. With true E2EE, if the keys are gone, the data is gone; there is no "reset my password and recover the recording." That is a feature against attackers and a liability against your own support desk.

Support and verification cost rises. Encrypted-call problems are harder to debug precisely because your servers cannot see the content. And E2EE only delivers its promise if endpoints verify each other's keys; without that verification step, a sufficiently capable attacker could substitute keys, and the "end-to-end" guarantee quietly weakens.

Table 1. What you keep and what you give up. The rows that flip to "not possible" under E2EE are the real decision — everything that needs a server to read the media.

Figure 4. The same trade-off as a one-glance card: the capabilities that flip to a workaround under end-to-end encryption are exactly the ones that need a server to read the media.

How products keep a recording without giving up E2EE — the compliance recorder

The most common objection is "we need E2EE and we have to record." These look mutually exclusive, but there are three established ways to have both, each a deliberate trade.

Client-side recording. Instead of recording on the server, record on an endpoint that already holds the keys — typically the clinician's app, inside the encryption. The recording is then encrypted at rest and uploaded to your storage. The media stays end-to-end encrypted in transit; only an authorized endpoint ever wrote it down. The cost is reliability: a client-side recorder depends on that device's network and battery, where a server recorder does not.

A designated "compliance recorder" as an authorized endpoint. This is the pattern most platforms settle on. You add a special participant to the call — a recording service — and give it a key, exactly as you would give one to a human participant. To the encryption scheme it is just another legitimate endpoint inside the group; to your product it is the recorder. The media is still never readable by the routing server, but it is readable by this one explicitly authorized, BAA-covered, access-logged recorder you control. Crucially, this is disclosed: patients and clinicians are told the session is recorded, consistent with consent rules. Done this way, you preserve the core E2EE promise — the general infrastructure stays blind — while meeting the recording obligation through one named, governed exception.

An organization-held compliance key. A variant where the encryption is designed so an organization key can also decrypt, held under strict control and used only for defined compliance purposes. This is the weakest form of "E2EE" and must be described honestly: if your organization can decrypt, the system is not end-to-end encrypted from the platform in the strict sense, and calling it so to a security reviewer is the kind of overstatement that erodes trust.

The honest framing for all three: true E2EE and routine server-side recording are in genuine tension, and every "we have both" architecture resolves it by naming a specific, authorized, logged endpoint that is allowed to see the media. The question is never whether you punched a hole in the encryption — to record, you did — but whether that hole is one named, governed, disclosed endpoint or an open door.

Figure 3. The compliance-recorder pattern: the routing server still sees only ciphertext, while one explicitly authorized, BAA-covered, access-logged recorder holds a key and writes the encrypted recording.

A worked example: the real price of turning E2EE on

Numbers make the trade concrete. Suppose you run a primary-care telehealth product and a large hospital customer asks for end-to-end encryption in their contract.

Walk the cost out loud. First, the build: adding an inner SFrame encryption layer, key distribution and rotation with MLS, endpoint key verification, and a fallback path for Safari and Firefox users is not a weekend — for a typical team it is a multi-month engineering effort plus ongoing maintenance of a second, trickier code path. Second, the feature loss: your live captions and your AI scribe stop working on the server, so to keep them you must either move them onto the endpoint devices or drop them — and the AI scribe was the feature driving your renewal rates. Third, recording: you now must build the compliance-recorder path described above instead of the simple server recording you have today. Fourth, support: encrypted-call debugging slows, and lost-key situations become unrecoverable by design.

Now weigh it. If that one contract is large enough to fund the build and you can move the AI scribe on-device or live without it, E2EE is a sound investment that also raises your security posture for every other customer. If it is a single mid-size deal and E2EE would kill the scribe that drives the rest of your business, the right answer may be to offer E2EE as a premium tier for the customers who require it, keep transport encryption as the default, and price the difference. The arithmetic is not "is E2EE good?" — it is good — but "is this security upgrade worth these specific features and this much engineering for this product?" Most of the time, for routine care, the answer is no; for the narrow sensitive cases above, the answer is clearly yes.

A common mistake to avoid

The most damaging error in this whole topic is claiming end-to-end encryption you do not have. A surprising number of telehealth products describe ordinary DTLS-SRTP transport encryption as "end-to-end" in marketing or security questionnaires. It is not: with transport encryption your media server reads the plaintext, which is the exact thing E2EE prevents. A capable security reviewer will ask one question — "can your servers technically see the media?" — and if the answer is yes, your "E2EE" claim is false. The second version of the mistake is subtler: a team ships real E2EE and an AI scribe and advertises both, not realizing the scribe reads audio on the server and therefore quietly contradicts the encryption claim. Decide which property you are actually selling, build that, and describe it precisely. In healthcare, an encryption claim that does not survive one pointed question is worse than no claim at all.

Where Fora Soft fits in

Fora Soft has built real-time video for healthcare since 2005, and the E2EE decision is one we work through with clients requirement-first: what threat are you defending against, what sensitivity is the data, and what server-side features — recording, transcription, AI — does the product depend on. When E2EE is warranted, we implement it with the WebRTC Encoded Transform API and SFrame-style frame encryption, design the key distribution and rotation, and build the compliance-recorder path so a clinical recording survives without breaking the encryption for the rest of the infrastructure. When it is not warranted, we say so and keep the platform on well-guarded transport encryption rather than selling a costly feature the product does not need. Telemedicine is one of several real-time-video verticals we work in, alongside video conferencing, streaming, e-learning, and surveillance, and the encryption discipline transfers directly. The clinical and legal sign-off stays with your counsel; we translate the requirement into the architecture.

What to read next

• Securing the video pipeline end to end
• Encryption in transit, at rest, and end to end
• 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 end-to-end encryption telehealth plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Telehealth E2EE Decision Guide — One page, two columns: when end-to-end encryption is worth its cost, what it takes away, and the decision rule — including the one question that exposes a false E2EE claim and how to keep a recording without breaking the encryption.

References

1. 45 CFR §164.312 — Technical safeguards (transmission security §164.312(e); encryption at rest §164.312(a)(2)(iv), both addressable). HHS / eCFR. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 — Tier 1. Encryption is addressable and technology-neutral; the rule does not name E2EE.
2. 45 CFR §164.502(e) — Business associate contracts (BAA requirement). HHS / eCFR. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.502 — Tier 1. Encryption does not remove the BAA obligation for any vendor that handles PHI.
3. HHS — Guidance on How the HIPAA Rules Permit Covered Providers to Use Remote Communication Technologies for Telehealth. HHS/OCR. https://www.hhs.gov/hipaa/for-professionals/special-topics/telehealth/index.html — Tier 1. Risk-based; encourages available encryption, does not mandate E2EE.
4. NPRM: HIPAA Security Rule To Strengthen the Cybersecurity of ePHI (90 FR 898, RIN 0945-AA22). HHS/OCR — Federal Register, 2025-01-06. https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information — Tier 1. PROPOSED, not final as of 2026-06-14; would make encryption required but still does not mandate E2EE.
5. 42 CFR Part 2 — Confidentiality of Substance Use Disorder Patient Records. HHS / SAMHSA / eCFR. https://www.ecfr.gov/current/title-42/chapter-I/subchapter-A/part-2 — Tier 1. Heightened protection for SUD records; a driver for stronger encryption in behavioral health.
6. RFC 8827 — WebRTC Security Architecture. IETF, 2021. https://www.rfc-editor.org/rfc/rfc8827.html — Tier 1 (standard). DTLS-SRTP is mandatory transport encryption for WebRTC media; protects the wire, not the server.
7. RFC 9605 — Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media. IETF, 2024. https://www.rfc-editor.org/rfc/rfc9605.html — Tier 1 (standard). End-to-end media encryption that lets an SFU route without reading the media.
8. RFC 9420 — The Messaging Layer Security (MLS) Protocol. IETF, 2023. https://www.rfc-editor.org/rfc/rfc9420.html — Tier 1 (standard). Group key establishment with forward secrecy and post-compromise security; used to key E2EE group calls.
9. W3C — WebRTC Encoded Transform (Insertable Streams) specification & explainer. W3C. https://www.w3.org/TR/webrtc-encoded-transform/ — Tier 3 (standards-author material). The browser API that enables an added E2EE layer; RTCRtpScriptTransform.
10. WebRTC browser support and Encoded Transform availability (2026). Ant Media / webrtcHacks engineering write-ups. https://antmedia.io/webrtc-browser-support/ — Tier 4 (engineering). Chrome-first availability; Safari/Firefox gaps as of 2026.