HIPAA Encryption Rules for Telehealth Platforms

If your telehealth platform handles ePHI over the internet, encryption is not something you can skip. Under HIPAA, encryption is “addressable,” which means you either use it or document why you do not and put another safeguard in place. In telehealth, that applies to video visits, chat, file uploads, APIs, remote monitoring data, logs, backups, and recordings.

Here’s the short version:

• Internet-based telehealth traffic counts as electronic transmission. That means HIPAA Security Rule safeguards apply.
• TLS 1.2 or 1.3 should protect web, app, and API traffic.
• WebRTC with DTLS-SRTP should protect live audio and video.
• AES-256 or a NIST-approved equivalent should protect stored ePHI, including recordings and backups.
• Keys should stay in a KMS or HSM, not with the data.
• A BAA alone is not enough. You should verify vendor encryption, logging, retention, and breach response controls.
• HIPAA records should be kept for at least 6 years.

A few points trip teams up. A PSTN landline call is treated differently from a VoIP or app-based call. And many platforms protect traffic in transit but miss stored items like chat histories, transcripts, session metadata, and exported files.

HIPAA at Home | Securing ePHI in a Remote and Telehealth World | Webinar on HIPAA Compliance

Quick comparison

So if I had to reduce the article to one idea, it would be this: telehealth encryption is not just about the video call. It covers the full data path before, during, and after the visit.

Encryption in Transit: What Telehealth Platforms Must Protect

When ePHI moves between a patient's browser and a portal, through a mobile app, across an API call to an EHR, or during a live video visit, it needs protection from unauthorized access. HIPAA's Transmission Security standard (45 CFR §164.312(e)(1)) calls for technical safeguards for ePHI in transit. In telehealth, encryption is the standard move^[19][21].

Transport and Media Protocols That Support HIPAA-Aligned Telehealth

Telehealth traffic flows through several channels, so the encryption method needs to match the type of transport.

Use TLS 1.2 or TLS 1.3 for web portals, APIs, messaging, and file transfers^[16][15]. TLS 1.3 is the better pick because it has a simpler design and drops many older weak points. TLS 1.2 is still acceptable for vetted legacy systems. For service-to-service connections, like a telehealth platform linking to an EHR or billing system, mutual TLS (mTLS) adds another check by making both sides prove who they are^[15][20].

For live audio and video, use WebRTC with DTLS-SRTP. DTLS handles key exchange, and SRTP encrypts the media stream^[2][14]. Signaling channels should still run over TLS 1.2 or 1.3. TURN servers should sit in a controlled, private environment, not on public relay services^[2][14].

Once traffic is locked down in motion, stored copies, recordings, and logs need that same level of care.

End-to-End Encryption: When It Matters and What HIPAA Actually Requires

HIPAA says ePHI in transit must stay unreadable to unauthorized parties. It does not require one specific encryption design^[9][11][2].

A lot of telehealth platforms use server-side encryption. In that setup, media is encrypted between each client and the server, but the server, often an SFU, can still access the media for mixing, recording, or processing. That can still fit HIPAA if the server environment is secured, access is limited, and activity is logged. End-to-end encryption, or E2EE, goes further. Only the patient's and clinician's devices hold the decryption keys, which cuts down what a compromised server could expose^[9][10][2].

That makes E2EE a strong fit for high-sensitivity care or BYOD telehealth. The tradeoff is pretty plain: it helps privacy, but it can get in the way of recording, analytics, and supervision.

Configuration Mistakes That Weaken Data in Transit

Some mistakes can undercut encryption fast.

• Allowing SSL, TLS 1.0, or TLS 1.1 opens downgrade paths that attackers can abuse through known issues like POODLE and BEAST^{[8][11][12][13][15]}.
• Weak cipher suites, especially CBC-mode ciphers and any setup without perfect forward secrecy (PFS), lower protection if a long-term key is exposed^{[3][16][17][15][20]}.
• Expired, untrusted, or unrevoked certificates increase man-in-the-middle risk.
• In WebRTC, letting peers negotiate SDES keying or plain RTP instead of forcing DTLS-SRTP strips away the encryption that protects live sessions^[2][14].

The same bar applies once data lands in storage, because recordings, chat logs, and attachments also become ePHI.

sbb-itb-535baee

Encryption at Rest: Storage, Recordings, and Key Management

If data in motion needs encryption, data at rest needs the same level of care. That means databases, object storage, backups, logs, and endpoints all need protection.

Where Telehealth Data Is Stored and How It Should Be Encrypted

Use AES-256 or a NIST-approved equivalent with FIPS 140-2/140-3 validated modules. For databases, apply TDE. For object storage, use server-side encryption. For clinician laptops and mobile devices, use full-disk encryption through MDM.

TDE can protect data files, logs, and backups. Backups, replicas, and archives should also be encrypted, and restore testing should happen on a regular basis. Encryption only helps if you can still recover the data when you need it.

These storage locations also show where keys, retention rules, and access controls need to be enforced. In plain terms, if data lives there, protection rules need to live there too.

Recordings, Chat Histories, and Attachments as Stored ePHI

Every stored telehealth artifact - recording, message, or attachment - is ePHI.^[26] That includes the files people often overlook after a visit ends.

Access should be restricted with RBAC. Patient access should use time-bound signed URLs. Retention and secure deletion rules should be set in advance, not figured out later. And every access, export, and deletion needs to be logged.

That logging matters because it creates audit evidence. If someone asks who opened a file, when it was shared, or when it was deleted, the record should already be there.

Key Management Controls Auditors and Security Teams Expect

Keys should be stored in a KMS or HSM, never alongside the data they protect, and they should be rotated on a defined schedule.^[3][22][23] This is one of those areas where small mistakes can turn into big problems fast.

Separation of duties matters. The people who manage servers should not have direct access to decryption keys. Break-glass procedures should cover rare access events and require multi-party approval. Dual control should also be required for key export or rotation actions.

Auditors usually expect clear documentation showing who or what can decrypt each data type - service accounts, named roles, or security officers. They also look for KMS configuration exports, key rotation logs, and completed access reviews as standard audit evidence.^[3][23][25]

That documentation then feeds into the risk review that follows.

Risk Analysis, Vendor Due Diligence, and Telehealth Oversight

Encryption docs should do more than sit in a folder. They should guide risk analysis and vendor review. A control on paper doesn't mean much unless it's documented, checked, and applied across every vendor that touches ePHI.

How to Document Encryption Decisions Under the HIPAA Security Rule

The HIPAA Security Rule calls for a thorough risk analysis of ePHI confidentiality, integrity, and availability. That analysis should support your encryption decisions.^[28][1] Because encryption is an addressable implementation specification, organizations need to document whether it is reasonable and appropriate for the telehealth environment or whether an equivalent alternative is being used.^[1][30][18]

In practice, that means mapping the full telehealth workflow and keeping a clear asset inventory. Include telehealth apps, endpoints, networks, cloud services, EHR links, devices, and third-party systems that handle ePHI.^[32][33] For each system, document the scope, assets, data flows, encryption risks, the control in place, the owner, the review date, and any exception, along with its compensating control and remediation deadline.^[28][1][34]

That same inventory can double as your vendor review checklist. For data in transit, note which channels are encrypted, where encryption ends, and whether any legacy or nonencrypted flows still exist and what risk they add.^[29][5][23] For data at rest, list each storage location, the encryption method, and how keys are generated, stored, rotated, and audited.^[29][23][8] Also document whether recordings and chat histories are encrypted, who can reach them, and how retention and deletion work.^[29][23] Put simply, these transit and at-rest records become your audit trail for what was deployed, where it was deployed, and who signed off on it.

Keep these records for at least six years, and update them whenever telehealth workflows, vendors, or threat conditions change.^[28][30][31]

What to Ask Telehealth Vendors About Encryption Controls

Every telehealth vendor that handles ePHI should go through business associate due diligence. Don't settle for a vague HIPAA attestation. Ask for proof of specific controls, and use the same encryption requirements in each review.

Ask for evidence, not assurances.^[6] That means requesting supporting documents, including configuration details and key management records, as part of your standard vendor review.

How Censinet Supports Telehealth Encryption Assurance at Scale

Once you're dealing with a large vendor portfolio, keeping all of this organized gets harder fast. Censinet RiskOps™ helps healthcare organizations standardize third-party risk reviews for telehealth vendors, including encryption, key management, logging, and incident response.

Conclusion: Applying HIPAA Encryption Rules Across Telehealth Use Cases

Telehealth creates more ePHI touchpoints than many teams expect at first. Live video is just one path. Recordings, messages, remote monitoring data, and device data all carry ePHI too. And each of those paths needs the same level of protection: encryption in transit, encryption at rest, plus access controls, audit trails, and vendor agreements that match the rules for clinical data.

That’s the bigger issue here. Encryption can’t be treated like a nice add-on in a telehealth platform. It has to be part of day-to-day operations.

HHS's proposed Security Rule would push encryption closer to a required baseline for ePHI at rest and in transit.^[30][7] That also puts vendor verification in the same bucket of controls.

A BAA matters, but it doesn’t prove everything on its own. The controls behind that agreement - encryption standards, access controls, breach notification timelines, and subcontractor duties - need to be checked, not taken for granted.

Key Takeaways for Healthcare IT and Compliance Leaders

For healthcare IT and compliance leaders, the checklist is pretty direct:

• Map every ePHI flow across the full telehealth setup, including portals, APIs, media streams, RPM devices, logs, backups, and third-party integrations.^[36][37][41]
• Use modern encryption standards: TLS 1.2/1.3 for web and API traffic, SRTP/DTLS for audio and video, and AES-256 for data at rest. Turn off legacy protocols and enforce secure defaults across all telehealth features.^[8][45][37]
• Treat stored data with the same care. Recordings, transcripts, chat histories, and attachments are ePHI, so they need encryption, access controls, and BAA coverage.^[43][10][46]
• Execute and maintain BAAs with every telehealth vendor that touches ePHI.^{[4][40][27][41]} Use those agreements to spell out encryption standards, subcontractor duties, and breach notification timelines.^{[38][42][44][39]}
• Document risk analyses and encryption decisions, keep records for at least six years, and update them when platforms, vendors, or rule changes shift the picture.^[22][24][35]

Structured risk assessments, supported by Censinet RiskOps™, help teams keep telehealth encryption oversight in place across a growing vendor stack.

FAQs

Is encryption required for telehealth under HIPAA?

Yes. Under the January 2025 Security Rule update, HIPAA requires encryption for all electronic protected health information (ePHI) used in telehealth, both in transit and at rest.

For telehealth sessions, use TLS 1.3 or higher. If you need a fallback, TLS 1.2 is the minimum, and it must be strongly configured. For data at rest, HIPAA requires AES-256, along with NIST-validated cryptographic modules and strong key management.

What telehealth data counts as ePHI and must be encrypted?

Under HIPAA, any electronic Protected Health Information (ePHI) that a telehealth platform stores, sends, or accesses must be encrypted.

That covers more than just the obvious stuff. It includes video and audio streams, chat messages, file transfers, session metadata, clinical notes, and patient identifiers such as names or medical record numbers. And the rule applies in both places that matter most: at rest on servers and devices, and in transit across networks, APIs, portals, or email.

How do I verify a telehealth vendor’s encryption controls?

Don’t rely on a signed BAA alone. Check the vendor from time to time to make sure it still meets baseline encryption standards, including TLS 1.2 or higher - with TLS 1.3 preferred - and AES-256 for data at rest and in transit.

A simple signature doesn’t tell you much about day-to-day security. You need proof. Use standardized security questionnaires, ask for independent certifications like SOC 2 Type II or HITRUST CSF, and test public-facing endpoints with tools such as SSL Labs or OpenSSL.

Related Blog Posts

• HIPAA Encryption Rules for Data in Transit
• Encryption in Transit: Compliance for Healthcare IT
• Top Encryption Standards for PHI: Symmetric vs. Asymmetric
• HIPAA Encryption in Transit: Key Protocols