Securing the Video Pipeline End to End

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

Why this matters

If you are building or buying a telemedicine platform, the video call is the part everyone looks at and the part that is already well protected. The breaches happen everywhere else: a recordings bucket left open to the internet, a database connection with no encryption between two of your own servers, an API key for the medical record system sitting in a config file. This article is for founders, product managers, CTOs, and security leads who need to know what "secure the pipeline" actually means in concrete parts, talk to engineers and auditors with confidence, and pass a security review without surprises. It is the engineering companion to the regulatory requirements in Block 2 — where those articles tell you what the rule demands, this one tells you how the pipeline implements it.

What "the pipeline" actually is

Before you can secure something, you have to see it. The telemedicine video pipeline is the full path patient data travels from the moment a patient opens the app to the moment a recording is deleted years later. It has five stages, and each one is a different security problem.

First, the setup, called signaling — the back-and-forth that arranges a call before any video flows, like two people agreeing on a phone number and a time before they actually talk. Second, the live media — the real-time audio and video itself. Third, the relay and routing servers — the machines that help two devices find each other and that mix or forward streams in a group call. Fourth, the rest of your own backend — the API, the databases, the connections between your services. Fifth, the recordings and stored data — session recordings, transcripts, uploaded photos, the patient record, sitting on disk long after the call ends.

A useful way to hold it: the pipeline is a building with five rooms, and a security review walks every room, not just the lobby everyone admires. The lobby — the live video — has the best lock in the building already. The rooms in the back are where things get stolen.

The unit of risk in every room is the same: Protected Health Information, or PHI — any health data that can be tied to an identifiable person. Securing the pipeline means PHI is protected in motion (while it travels) and at rest (while it sits on disk), and that the line between "inside our protected system" and "outside" is drawn on purpose and guarded. That line has a name we will use throughout: the PHI boundary.

Figure 1. The PHI boundary made concrete: every component that can see patient data sits inside, under a signed contract, with encryption labeled on every hop that crosses the line.

The rule you are implementing: HIPAA technical safeguards

Securing the pipeline is not just good practice — most of it is a named federal requirement. The HIPAA Security Rule, the U.S. rule that governs electronic health data, lists a set of technical safeguards at 45 CFR §164.312. You do not have to memorize the citation, but you should know that five of its standards map almost one-to-one onto the pipeline work in this article.

The standard at §164.312(a)(1) is access control — only the right people and systems reach PHI. §164.312(b) is audit controls — you can prove who touched what (covered in depth in audit logging and access controls for clinical video). §164.312(c)(1) is integrity — data is not altered without detection. §164.312(d) is person or entity authentication — you verify who is connecting (covered in authentication and identity for patients and providers). And §164.312(e)(1) is transmission security — PHI is protected while it moves across a network. This article lives mostly in (e) and (a), and touches all five.

One detail trips up almost every first-time telehealth team. Several of these specifications — including encryption in transit at §164.312(e)(2)(ii) and encryption at rest at §164.312(a)(2)(iv) — are labeled addressable rather than required. "Addressable" sounds like "optional." It is not. It means you must implement the safeguard if it is reasonable and appropriate, and if you decide not to, you must document a written justification and put an equivalent protection in its place. For PHI moving across the public internet and PHI sitting in cloud storage, there is no credible argument that encryption is unreasonable. In practice, addressable encryption is mandatory; the only thing "addressable" buys you is paperwork if you somehow have a better alternative, which for video PHI you do not.

It is about to become explicit. A proposed update to the Security Rule — the Notice of Proposed Rulemaking titled "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information" (90 FR 898, RIN 0945-AA22, published 2025-01-06) — would remove the "addressable" label from encryption and make it flatly required, alongside mandatory multi-factor authentication, network segmentation, and a written technology asset inventory. As of 2026-06-14 this is still a proposal, not final law; the comment period closed 2025-03-07 and no final rule has issued, and more than a hundred provider organizations have asked the agency to withdraw or revise it. Treat its specifics as a strong signal of direction and confirm status with counsel before relying on it. The practical takeaway does not change: build as if encryption everywhere is mandatory, because for video PHI it effectively already is.

Layer 1 — The live call: WebRTC is encrypted by default

Start with the good news, because it is genuinely good. Modern telemedicine video runs on WebRTC (Web Real-Time Communication), the open standard browsers and mobile apps use for live audio and video. WebRTC does not let you send media unencrypted. There is no checkbox to turn encryption off, no plaintext mode, no way to do it by accident.

The mechanism is DTLS-SRTP. Two pieces, two jobs. SRTP (Secure Real-time Transport Protocol, defined in IETF RFC 3711) is the scrambler that encrypts the actual audio and video packets so anyone watching the wire sees noise. DTLS (Datagram Transport Layer Security) is the handshake that, before any media flows, lets the two endpoints agree on the secret key and prove to each other they are who they claim — so an attacker cannot quietly slip in and swap the key. The pairing is specified in RFC 5763 and RFC 5764, and the WebRTC Security Architecture (RFC 8827) makes DTLS-SRTP the only permitted media encryption for WebRTC. The keys are freshly generated for every call, so capturing one call tells an attacker nothing about the next.

For a non-technical reader, the one sentence to remember is this: the live video and audio between two endpoints is strongly encrypted automatically, and that satisfies the spirit of the transmission-security safeguard for the media itself. We cover the internals in WebRTC for telemedicine; the transport-security mechanics live in Video Streaming's WebRTC security: DTLS-SRTP and DTLS, SRTP, and TLS encryption of media. Do not re-derive those mechanics — link to them and move on to the parts that are actually exposed.

Because here is the catch that defines the rest of this article: DTLS-SRTP protects the media between two endpoints. It does nothing for the signaling that sets up the call, the relay servers that move the packets, the backend that issued the call token, or the recording written to disk afterward. The lobby has a great lock. Now we walk the back rooms.

Layer 2 — Signaling: encrypt the call setup

Signaling is the conversation that happens before the video starts: who is calling whom, what codecs each side supports, and — critically — the temporary credentials and connection details the two devices need to reach each other. WebRTC deliberately does not standardize signaling; you build it, usually over WebSockets, a persistent two-way browser connection.

That freedom is also the risk. The WebRTC threat model (RFC 8826) documents the central attack: if the signaling channel is not encrypted, an attacker who can read it can perform a man-in-the-middle — sit between the two parties, capture the connection details and temporary relay credentials, and impersonate a user or hijack the session. The media stays encrypted, but the attacker controls the setup.

The fix is simple and non-negotiable: signaling runs over WSS (WebSockets Secure), which is WebSockets wrapped in TLS, the same encryption that puts the padlock on a web address. Plain ws:// is forbidden for any clinical product; only wss:// is acceptable. This is also where you authenticate the user before issuing any call token, so a stranger cannot request a connection to a patient's session. Signaling is short, cheap to secure, and the most commonly overlooked door in the whole pipeline.

Layer 3 — Relay and routing: TURN credentials and the SFU inside the boundary

Two devices on the open internet usually cannot connect directly, because home and hospital networks hide them behind routers. WebRTC solves this with helper servers. A STUN server (RFC 8489) helps a device discover its own public address. When even that fails — common on locked-down hospital networks — a TURN server (Traversal Using Relays around NAT, RFC 8656) relays the media on the devices' behalf. The analogy: a TURN server is the post-office forwarding address a packet falls back to when two people cannot find each other directly.

TURN relays are a security concern for two reasons. First, running a TURN relay costs real bandwidth, so an exposed relay is a target for theft of service. Second, and more important for compliance, the relay sits in the media path. Two defenses matter. Use time-limited TURN credentials — short-lived username and password pairs that expire within roughly an hour, generated per session rather than shared and static, an approach built on the STUN third-party authorization extension (RFC 7635). And log every credential request so abuse is visible. A static, long-lived TURN password shared across all users is a classic finding in a telehealth security review.

Then there is the SFU (Selective Forwarding Unit), the media server that makes group calls work — a clinician, a patient, and an interpreter, for example. Here is the part teams miss. A plain TURN relay just forwards encrypted packets and never needs the key. An SFU is different: to route and selectively forward each participant's stream, it terminates the DTLS-SRTP connection, which means the SFU sees the decrypted clinical video. That single fact has a hard consequence. The SFU is processing PHI, so it must sit inside the PHI boundary: hosted on infrastructure you control or that is covered by a signed Business Associate Agreement (BAA) — the contract a vendor must sign before it is allowed to handle patient data. An SFU from a vendor with no BAA is an impermissible disclosure of PHI even though every packet was encrypted in transit. We return to the encrypted-is-not-compliant trap below; topology trade-offs are in P2P, SFU, and MCU for clinical use.

Figure 2. Every hop in the pipeline, with the protocol that protects it. The media is encrypted endpoint-to-endpoint; the SFU and recording store sit inside the boundary because they see plaintext PHI.

Layer 4 — Service to service: TLS and mTLS inside your own walls

Here is the mistake that hides for years: teams encrypt traffic from the patient to the server, then let their own services talk to each other in plaintext because "it is all inside our network." The connection from the API to the database, from the API to the recording store, from the signaling service to the SFU controller — if any of those carry PHI unencrypted, you have an unencrypted PHI transmission, and §164.312(e)(1) does not exempt traffic just because both ends belong to you.

The baseline fix is TLS everywhere, including service-to-service. Every internal connection that can carry PHI — database links, internal API calls, message queues, cache connections — uses TLS, ideally TLS 1.3 (RFC 8446), the current version, configured per NIST's TLS guidance (SP 800-52 Rev 2). Modern internal traffic should be encrypted by default; treat any plaintext hop carrying PHI as a defect.

For higher-sensitivity systems, go one step further to mTLS (mutual TLS). Ordinary TLS proves the server's identity to the client — your browser checks the website is really your bank. mTLS makes both sides prove their identity to each other with certificates, so a rogue service that somehow lands inside your network still cannot talk to your database, because it cannot present a valid certificate. The analogy: ordinary TLS is the guest checking the host's ID at the door; mTLS is both the guest and the host checking each other's badges before either says a word. mTLS between services is also exactly the kind of control the proposed 2026 Security Rule's network-segmentation requirement points toward.

Layer 5 — Network segmentation: shrink the blast radius

Encryption protects data; segmentation limits how far an attacker can move once inside. Network segmentation means dividing your infrastructure into isolated zones so a breach in one does not become a breach in all. The database holding PHI lives in a private subnet with no path to the public internet. The public-facing API talks to it only through a single, narrow, controlled route. The recordings store is reachable only by the specific service that writes to it and the specific service that reads it — nothing else.

The analogy is a ship's watertight compartments: a hull breach floods one compartment, not the whole vessel. Without segmentation, one compromised web server can reach every database; with it, the compromised server can reach almost nothing of value. Segmentation is appearing as an explicit requirement in the proposed 2026 Security Rule precisely because flat networks turned small intrusions into catastrophic breaches across healthcare. Combined with mTLS, segmentation is how you make "an attacker got one box" survivable instead of fatal.

Layer 6 — Recordings and stored data: the highest-value room

The recordings store is the most valuable and most sensitive room in the building. A session recording or transcript — especially in behavioral health — is uniquely damaging if leaked, and unlike a live call it sits on disk for years. Two controls do most of the work.

Encryption at rest. Every recording, transcript, photo, and database row of PHI is encrypted on disk, per §164.312(a)(2)(iv), using strong, standard algorithms — AES-256 is the usual choice — with NIST-validated cryptographic modules (FIPS 140-3) following NIST's storage-encryption guidance (SP 800-111). This has a second payoff beyond compliance: the HIPAA Breach Notification Rule's safe harbor. Under 45 CFR §164.402 and HHS's guidance on rendering PHI unusable, PHI that is encrypted to the named standard — with the keys kept separate and uncompromised — is not "unsecured PHI." If an encrypted backup is stolen but the keys are safe, you may avoid breach-notification obligations entirely. Encryption at rest is the one control that can turn a catastrophe into a non-event. Encryption choices in transit and at rest are covered in depth in encryption in transit, at rest, and end to end.

Signed URLs for access. Never serve a recording from a public link, and never make the storage bucket itself publicly readable — the misconfigured public bucket is the single most common cause of large healthcare data exposures. Instead use a signed URL (also called a pre-signed URL): a temporary, cryptographically signed web address that grants access to one specific file for a short window — five minutes, say — and then stops working. The analogy: a signed URL is a hotel key card cut for one room that self-destructs at checkout, not a master key handed to anyone who asks. Your backend checks that the requesting user is authorized for that specific recording, then mints a short-lived signed URL on the spot. The link cannot be reused, shared usefully, or guessed.

Figure 3. A signed URL grants access to one recording for one short window, then expires — no public bucket, no permanent link, no master key.

Layer 7 — Secrets management: protect the keys to everything

Every layer above depends on secrets: encryption keys, TURN credentials, the API key to the electronic health record (EHR) system, database passwords, signing keys for those URLs. If the secrets leak, every other control collapses. Yet the most common way secrets leak is depressingly simple — they sit in plaintext in a config file, a source-code repository, or an environment variable printed into a log.

Secrets management means storing these values in a dedicated, encrypted vault — a managed key service or secrets manager — never in code, never in a repository, never in a log line. Access to the vault is itself logged and restricted. Encryption keys deserve extra care, following NIST's key-management guidance (SP 800-57): keys are rotated on a schedule, stored separately from the data they protect (a key sitting next to its ciphertext protects nothing), and ideally held in a hardware security module. The breach safe harbor above only holds if the keys were not compromised — which is the entire reason secrets management is not optional. A stolen encrypted backup is a non-event; a stolen encrypted backup with the key in the same bucket is a full breach.

The trap that fails security reviews: "encrypted" is not "compliant"

Walk every layer above and you can still fail, because encryption answers a different question than compliance does. Encryption protects data from outsiders. A BAA governs who is allowed to be an insider. They are separate controls, and you need both.

The clearest example is the third-party SDK. A team adds an analytics tool, a crash reporter, a session-replay widget, or an AI feature, and that code quietly ships data — sometimes PHI, sometimes metadata that is still PHI in context — to a vendor over a perfectly encrypted HTTPS connection. The pipe is encrypted. It is still a HIPAA violation, because the data was disclosed to a company that never signed a BAA. HHS has been explicit even about storage-only vendors: a cloud provider that holds only encrypted PHI and has no decryption key is still a business associate that needs a BAA — there is no "we never see the plaintext" exemption (HHS HIPAA FAQ 2076).

So the rule to carry through your whole pipeline is this: every component that can see PHI — your SFU, your recording store, your transcription service, your cloud host, your AI vendor — must be either built by you or covered by a signed BAA, regardless of how well the connection to it is encrypted. Encryption and BAA coverage are two different gates, and PHI must pass both. We catalog the specific ways teams trip on this in common HIPAA mistakes in telemedicine builds, and the contract itself in the Business Associate Agreement explained.

A worked example: the cost of one missing layer

Numbers make the stakes concrete. Suppose your recordings bucket holds sessions for 5,000 patients and one engineer, in a hurry, sets the bucket to public to debug a playback issue and forgets to revert it.

Walk the arithmetic. If the recordings were not encrypted at rest, every one of the 5,000 files is now "unsecured PHI," and the Breach Notification Rule's clock starts: you must notify affected individuals without unreasonable delay and within 60 days (45 CFR §164.404), notify HHS, and — because more than 500 individuals are affected — notify prominent media in the affected area (§164.408). Add the investigation, the credit-monitoring offer, the legal review, and the reputational cost, and a single toggle becomes a six-figure event before any regulatory penalty.

Now the same mistake with encryption at rest and the keys held in a separate vault. The files are encrypted to the NIST-validated standard, the keys were never in that bucket, so under the safe harbor (§164.402) the exposed files are not "unsecured PHI." The same human error becomes a configuration incident you fix and document — not a reportable breach of 5,000 records. One layer, the difference between a bad afternoon and a bad year. That is why "end to end" is not a slogan: the layer you skip is the one that turns a mistake into a disaster.

The security review your build should pass

Put the layers together and you have the review a telehealth build should pass before it sees a patient. The free security-review checklist below turns each layer into a yes/no question with the rule beside it.

Figure 4. Defense in depth: eleven controls, from the encrypted call on the outside to the secrets vault at the core. A reviewer walks every layer, not just the lobby.

A common mistake to avoid

The single most expensive pitfall in this whole article is treating the live call's strong encryption as if it secured the pipeline. It does not. DTLS-SRTP protects the media between two endpoints and nothing else — not the signaling, not the TURN credentials, not the database link, not the recording on disk, not the analytics SDK. Teams demo a working encrypted call, declare the product "secure," and ship a public recordings bucket and a static TURN password underneath it. The lobby's lock is real; the back doors are wide open. Security review failures cluster almost entirely in the layers behind the call, which is exactly why this article walks all seven.

Where Fora Soft fits in

Fora Soft has built real-time video for healthcare since 2005, and securing the pipeline end to end is the core of how we approach a telemedicine build: the requirement first — transmission security, encryption at rest, BAA-covered components inside the PHI boundary — then the capability. We design the media path so the SFU and recording store sit inside the boundary, signaling runs over WSS, recordings are reached only through short-lived signed URLs, and secrets live in a vault rather than a config file. Telemedicine is one of several real-time-video verticals we work in, alongside video conferencing, streaming, e-learning, and surveillance, and the compliance discipline transfers directly. We translate the rule into the architecture; the clinical and legal sign-off stays with your counsel.

What to read next

• HIPAA for telemedicine product teams
• Threat modeling a telemedicine platform
• End-to-end encryption in telehealth: when you need it and what it costs

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your securing telemedicine video pipeline plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Telemedicine Video Pipeline Security-Review Checklist — One page, two columns: encrypt-every-hop and guard-the-boundary, eleven controls from DTLS-SRTP to the secrets vault, each with its HIPAA anchor and a yes/no pass question your build should clear before launch.

References

1. 45 CFR §164.312 — Technical safeguards (access control, audit controls, integrity, person/entity authentication, transmission security). HHS / eCFR. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 — Tier 1. Required and addressable specifications, incl. (a)(2)(iv) and (e)(2)(ii) encryption.
2. 45 CFR §164.402 — Breach notification definitions (unsecured PHI / safe harbor). HHS / eCFR. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D/section-164.402 — Tier 1. Encryption to HHS-specified standard removes data from "unsecured PHI."
3. 45 CFR §164.404 & §164.408 — Notification to individuals; notification to HHS. HHS / eCFR. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D — Tier 1. 60-day clock; 500+ individuals triggers media notice.
4. 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. PHI disclosure to a business associate requires a BAA.
5. 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, mandate MFA + network segmentation + asset inventory.
6. HHS — Guidance to Render Unsecured PHI Unusable, Unreadable, or Indecipherable. HHS. https://www.hhs.gov/hipaa/for-professionals/breach-notification/guidance/index.html — Tier 1. Names NIST encryption standards (SP 800-111 at rest, SP 800-52 in transit) for safe harbor.
7. HHS HIPAA FAQ 2076 — Encrypted-only CSP with no key is still a business associate. HHS. https://www.hhs.gov/hipaa/for-professionals/faq/2076/if-a-csp-stores-only-encrypted-ephi-and-does-not-have-a-decryption-key-is-it-a-hipaa-business-associate/index.html — Tier 1. No "no-view" / conduit exemption for storage of encrypted PHI.
8. RFC 8827 — WebRTC Security Architecture. IETF, 2021. https://www.rfc-editor.org/rfc/rfc8827.html — Tier 1 (standard). DTLS-SRTP mandatory for WebRTC media; new key pair per call.
9. RFC 8826 — Security Considerations for WebRTC. IETF, 2021. https://www.rfc-editor.org/rfc/rfc8826.html — Tier 1 (standard). Threat model incl. signaling man-in-the-middle.
10. RFC 3711 — The Secure Real-time Transport Protocol (SRTP). IETF, 2004. https://www.rfc-editor.org/rfc/rfc3711 — Tier 1 (standard). Media-packet encryption.
11. RFC 5763 / RFC 5764 — DTLS-SRTP framework and key establishment. IETF, 2010. https://www.rfc-editor.org/rfc/rfc5763 — Tier 1 (standard). DTLS handshake establishing SRTP keys.
12. RFC 8656 — Traversal Using Relays around NAT (TURN). IETF, 2020. https://www.rfc-editor.org/rfc/rfc8656 — Tier 1 (standard). Relay protocol; credential mechanisms.
13. RFC 7635 — STUN Extension for Third-Party Authorization (ephemeral TURN credentials). IETF, 2015. https://www.rfc-editor.org/rfc/rfc7635 — Tier 1 (standard). Basis for time-limited TURN credentials.
14. RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3. IETF, 2018. https://www.rfc-editor.org/rfc/rfc8446 — Tier 1 (standard). Current TLS for transport encryption.
15. NIST SP 800-52 Rev 2 — Guidelines for the Selection, Configuration, and Use of TLS Implementations. NIST, 2019. https://csrc.nist.gov/pubs/sp/800/52/r2/final — Tier 1. TLS configuration for protecting data in transit.
16. NIST SP 800-111 — Guide to Storage Encryption Technologies for End User Devices. NIST. https://csrc.nist.gov/pubs/sp/800/111/final — Tier 1. Storage (at-rest) encryption guidance.
17. NIST SP 800-57 — Recommendation for Key Management. NIST. https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final — Tier 1. Key rotation, separation, and lifecycle.
18. NIST SP 800-66 Rev 2 — Implementing the HIPAA Security Rule. NIST, 2024. https://csrc.nist.gov/pubs/sp/800/66/r2/final — Tier 1. Maps Security Rule safeguards to technical controls.