Telehealth Security

What is telehealth security?

Telehealth security is the set of controls that protect a virtual care service: who can join a visit, how audio, video and chat are encrypted, where recordings and files are stored, and how activity is logged. It covers the platform, the clinician's workstation and the patient's device, and it is tested against a written threat model.

Security and compliance overlap but are not the same task. A platform can have every agreement signed and still let an uninvited person join a visit through a reused link. The work below is about preventing that kind of failure in the software itself.

What does a telehealth threat model cover?

A telehealth threat model lists what an attacker could reach in each part of a visit and what the platform does to stop it. Write it before the design is final, and update it when a feature adds a new data path.

• Uninvited joiners: Someone with a forwarded or guessed meeting link enters a visit or a waiting room.
• Clinician account takeover: A phished password gives an attacker the clinician's schedule and patient list.
• Signaling interception: A compromised signaling path swaps media keys and listens in.
• Recording leakage: Stored recordings sit in a bucket with broad access or a public link.
• Malicious uploads: A file sent through visit chat carries malware to the clinician's workstation.
• Data scraping: An appointment API returns other patients' names or times when an ID is changed.
• Support impersonation: A caller persuades the help desk to reset a patient or clinician account.
• Third-party scripts: Analytics or chat widgets on visit pages send identifiers or page content to outside services.

Rank each threat by impact and likelihood, assign a control and an owner, and link it to a test. The ranked list then drives the security backlog instead of a generic checklist.

How should patients and clinicians sign in?

Patients and clinicians need different sign-in designs because they carry different risk. A clinician account reaches many patients, so it gets the strongest authentication; a patient account reaches one record, so it balances security with ease of joining.

The HIPAA Security Rule at 45 CFR 164.312 makes unique user identification, an emergency access procedure, audit controls and person or entity authentication required implementation specifications. It does not name a method, which leaves the design choice to the platform team.

NIST SP 800-63-4, the Digital Identity Guidelines published in final form in July 2025, superseded SP 800-63-3. It gives a structured way to choose identity proofing and authentication levels, and it gives the team a documented basis to show hospital security reviewers.

• Clinicians: Single sign-on with the employer's identity provider where possible, and phishing-resistant multi-factor authentication such as passkeys or security keys as good practice.
• Patients: Verified email or phone, optional passkeys, and identity proofing at registration rather than at every visit.
• Visit access: A one-time join token bound to the appointment and the patient, valid only near the scheduled time.
• Proxies: Separate accounts for caregivers with their own credentials, never a shared patient login.
• Sessions: Short sessions on shared devices, automatic sign-out after inactivity, and revocation when a password changes.

Plan the emergency access path at the same time. A covering clinician who must join a visit when the scheduled one cannot needs a break-glass route that grants access quickly, records the reason and alerts a reviewer, rather than a shared account kept for emergencies.

How is the video stream protected?

Browser-based video uses WebRTC, which encrypts media by design. The IETF's WebRTC Security Architecture, RFC 8827, says all media channels must be secured with SRTP and SRTCP, media must not be sent over plain RTP, and DTLS-SRTP must be offered for every media channel.

That protects media in transit between endpoints and media servers. The open question is what happens at the server. Group calls route through a media server such as a selective forwarding unit, and with standard WebRTC encryption the server can technically access the decrypted streams it forwards.

Teams that need the media server to stay blind add end-to-end media encryption on top, with keys held by the participants. That choice affects features: server-side recording, live captions and transcription need decrypted media, so each one must either run on a participant device or be dropped.

• Signaling: Run signaling over TLS with authenticated sessions, and bind each media session to the appointment token.
• Waiting room: Hold every patient until the clinician admits them, and show the clinician the patient's verified name.
• Relays: Issue short-lived TURN credentials per session so relay servers cannot be used by anyone else.
• Join links: Expire links after the visit and never reuse a room identifier across patients.

Third-party video SDKs need the same scrutiny as your own code. Confirm where the vendor's media and signaling servers run, whether the vendor can access media or recordings, and how its keys are managed, then record the answers in the threat model.

Which data stores carry the most risk?

The stores created by virtual visits carry the most risk because they are new and often outside the main record. Inventory them early, since each one needs access control, encryption, retention and audit.

• Recordings: Encrypt at rest, restrict access by role, and set a retention period the client approves.
• Chat and files: Scan uploads for malware, block executable types, and store files with the encounter rather than in a shared folder.
• Screenshots and screen shares: Disable capture of shared screens by default and log any capture that is allowed.
• Application logs: Strip names, notes and tokens from logs, and keep audit events in a separate store with its own access rules.
• Analytics: Keep third-party scripts off authenticated visit pages, or route events through a server that removes identifiers.
• Notifications: Keep push and text messages generic, such as a visit reminder with no diagnosis or clinician specialty.

Devices the platform does not control

Patients join from personal phones, family laptops and home networks, so the platform must assume the device may be shared or outdated. Design controls that reduce exposure without blocking care.

Treat device checks as signals rather than gates. An outdated operating system or a rooted phone can trigger a warning or step-up verification, while still letting a patient join a scheduled visit by browser.

Clear cached visit data when the session ends, avoid storing documents on the device unless the patient downloads them, and hide visit content in the app switcher preview. For clinicians, require managed devices or a hardened browser profile for access to patient lists.

Clinicians working from home add another layer. Their screens can be seen by others in the room, their headsets may connect to shared speakers, and their devices may hold downloaded files. Provide a short home-working standard covering screen position, headsets, locked screens and no local downloads, and check managed devices against it.

What happens when something goes wrong?

A telehealth incident needs fast containment tools that are built in advance. When an account or link is compromised, the response team should be able to act in minutes from an admin console, not through database scripts.

• Session kill: End all active sessions for a user or a visit and force a fresh sign-in.
• Token revocation: Invalidate every outstanding join token for a clinician, a patient or a date range.
• Recording lockdown: Remove all access to a recording while the incident is reviewed.
• Audit export: Pull every join, admit and file access for the affected visits in one report for the privacy officer.

Rehearse these steps once before launch. A drill shows whether the console works and who is authorized to use it.

A telehealth security test plan

Each threat in the model should have a test that runs before launch and after major changes. These tests catch the defects that reviews of policy documents miss.

• 1. Link reuse: Try to join a finished visit and another patient's visit with a valid but wrong token.
• 2. Waiting room bypass: Attempt to enter a visit before the clinician admits the patient.
• 3. Object access: Change appointment, recording and file IDs in API calls and confirm each returns an error.
• 4. Account recovery: Run a social engineering script against the help desk reset process.
• 5. Media inspection: Capture traffic and confirm no unencrypted RTP leaves any endpoint.
• 6. Upload handling: Send test malware samples and oversized files through visit chat.
• 7. Logging: Search logs and analytics payloads for names, notes and tokens after a scripted visit.
• 8. Audit trail: Confirm every join, admit, recording access and file download appears in the audit store.

Automate tests 1, 2, 3 and 7 in the delivery pipeline. Run the rest in a scheduled penetration test and record results against the threat model.

How Agnotic can help

Telehealth security has to be designed into the visit flow, not added after a hospital security review fails. Agnotic Technologies builds it for the client: a written threat model, clinician and patient sign-in designed against NIST SP 800-63-4, appointment-bound join tokens, encrypted media with the right server design, controlled stores for recordings and files, and automated security tests.

For existing platforms, Agnotic can run the test plan above, report the gaps by risk and fix them in the client's codebase.

Sources

• 45 CFR 164.312: HIPAA Security Rule technical safeguards
• IETF RFC 8827: WebRTC Security Architecture
• NIST SP 800-63-4: Digital Identity Guidelines