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

Why this matters

If you are building or buying a telemedicine platform, you are taking responsibility for the most sensitive data a person has: their health. Attackers know this, which is why healthcare is the most-targeted industry for ransomware. Threat modeling is how a non-security team gets ahead of that risk on purpose instead of discovering it in a breach-notification letter. It is also the cheapest security work you will ever do — a whiteboard session that prevents a redesign. This article is for founders, product managers, and engineering leads who need to run that session, talk to auditors with confidence, and know which threats actually materialize in telehealth.

What threat modeling actually is

Threat modeling is a structured conversation about how your system could be attacked. You draw a picture of how data moves through your product, then you walk through that picture asking "what could go wrong here?" at every step. The output is a prioritized list of threats and a decision for each one: fix it, reduce it, accept it, or watch it.

A useful way to hold the idea: a threat model is a fire-safety walkthrough for a building you are still designing. You don't wait for a fire to learn the exits are blocked. You walk the floor plan with someone whose job is to imagine fires — where would one start, how would it spread, what is flammable, where are the people — and you fix the problems on paper. Threat modeling is that walkthrough for data instead of flames.

Three terms recur, so define them once. A threat is something bad that could happen — patient video intercepted, records altered, the service knocked offline. A vulnerability is the weakness that lets the threat happen — an unencrypted link, a missing login check. A risk is the combination: how likely the threat is, multiplied by how much damage it would do. You model threats; you find vulnerabilities; you rank risks.

One more distinction matters in healthcare. Most security writing focuses on security threats — someone breaking in. Telemedicine also has privacy threats — data that is technically secure but still over-collected, over-shared, or linkable back to a patient who expected anonymity. A behavioral-health app that logs which articles a user reads has a privacy problem even if every byte is encrypted. Good telehealth threat modeling looks at both.

Why a telehealth team cannot skip it

Here is the part that turns a nice-to-have into a requirement. The HIPAA Security Rule (the federal rule that governs electronic health data) requires every covered entity and business associate to conduct "an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability" of electronic protected health information — electronic Protected Health Information, or ePHI, meaning any health data tied to a person and held in digital form. That sentence lives at 45 CFR §164.308(a)(1)(ii)(A), and it is called the risk analysis.

A threat model is the engineering half of that risk analysis. The risk analysis is the formal, documented assessment auditors ask to see; the threat model is how you actually produce its content for a software product. Run a real threat model and you have most of what the rule demands. Skip it and you are exposed twice — to the attacker and to the regulator.

The second exposure is not theoretical. The U.S. Department of Health and Human Services' Office for Civil Rights (OCR), which enforces HIPAA, has made risk analysis the centerpiece of enforcement. Its Risk Analysis Initiative, running since late 2024, has produced a string of ransomware settlements, and a finding under §164.308(a)(1)(ii)(A) — failure to conduct an accurate, thorough risk analysis — appears in essentially every one of them. After a breach, "you never did a proper risk analysis" is the first thing regulators look for, and the easiest thing to penalize.

It is about to get more specific. A proposed update to the Security Rule (the NPRM "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information," 90 FR 898, published 2025-01-06, RIN 0945-AA22) would harden the requirement: a written risk analysis with a technology asset inventory and a network map, threats and vulnerabilities paired and rated, plus mandatory multi-factor authentication, encryption, vulnerability scanning at least every six months, and penetration testing at least every twelve. As of 2026-06-14 this is still a proposal, not final law — the comment period closed 2025-03-07 — so treat its specifics as a strong signal of direction rather than a current obligation, and confirm status with counsel before relying on it. The direction is unmistakable: the asset inventory, network map, and rated threat list that a threat model produces are exactly what the rule is moving toward mandating.

Step 1 — Model the system: draw the data-flow diagram

You cannot defend a system you cannot see. The first step is a data-flow diagram (DFD): a simple picture of how patient data moves through your product. It has four kinds of element, and only four. External entities are the people and outside systems that touch your platform — the patient, the clinician, the electronic health record (EHR) you integrate with. Processes are the parts of your system that do work — the signaling server, the API, the media server. Data stores are where data rests — the patient database, the recordings bucket, the audit log. Data flows are the arrows between them, each labeled with what travels and how it is protected.

Then draw the most important line of all: the trust boundary. This is the border between what you control and protect and what you do not. In telemedicine, the trust boundary is almost the same line as the HIPAA PHI boundary — everything inside must be either built by you or covered by a signed Business Associate Agreement (BAA), the contract a vendor must sign before it is allowed to handle patient data. Every arrow that crosses the trust boundary is a place an attacker can stand. Mark them; they are where most of your threats will be.

Keep the diagram coarse. Boxes and arrows on a whiteboard beat a 200-component architecture map nobody finishes. The goal is a picture a non-engineer can follow and an attacker would recognize.

Step 2 — The telemedicine attack surface: what is worth stealing, and the ways in

Before you hunt threats, name the prize. In a telemedicine platform attackers want three things: PHI (records, identities, insurance details — directly sellable and the raw material for fraud), recordings and transcripts of clinical sessions (uniquely sensitive, especially in behavioral health), and credentials (a clinician login is a master key to many patients' data). Knowing the prize tells you which paths to worry about most.

The attack surface is the set of all those paths — every place data enters, rests, or leaves. For a clinical video platform it has six recurring zones.

Diagram of the telemedicine attack surface: patient device, the live call, signaling and API, recordings store, EHR and third-party integrations, each with what attackers want and how they get in. Figure 1. The six zones of a telemedicine attack surface, with the prize and the common way in for each.

The patient and clinician devices. Phones and laptops you do not own and cannot fully secure. Threats: stolen or shared devices, malware, screen-recording, a session left open on a shared family computer. You mitigate with short sessions, automatic logout, and never caching PHI you do not need on the device.

The live call (WebRTC). The real-time audio and video. WebRTC encrypts the media itself end-to-end-of-transport with DTLS-SRTP (the standard that scrambles the stream between endpoints), so the wire is well protected by default. The exposed parts are around it: the signaling channel that sets up the call, and the TURN/SFU servers that relay and route media. A common, documented attack is signaling man-in-the-middle — an attacker who can read an unprotected signaling channel captures the temporary TURN credentials and relays traffic as your user. Mitigations are concrete: encrypted signaling (WSS, not plain WebSockets), TURN credentials that expire within about an hour, and logging every credential request. The media server (SFU) is special: to route a multi-party call it decrypts the streams, so it sees plaintext clinical video and must sit inside the PHI boundary under a BAA. We cover the protocol internals in WebRTC for telemedicine and the defenses in securing the video pipeline end to end; for the transport-security mechanics see Video Streaming's WebRTC security: DTLS-SRTP.

The signaling and application API. The brains: login, scheduling, the endpoints that issue call tokens and read records. This is the classic web attack surface — broken authentication, broken access control (a patient fetching another patient's record by changing an ID in a URL), injection. It is also where most real breaches happen, because an API that leaks records needs no exotic attack.

The recordings and data store. Where PHI rests: the patient database, the bucket holding session recordings, transcripts, uploaded photos. Threats: a misconfigured cloud bucket left public, backups copied somewhere without encryption, an over-broad access role. The recordings store is the highest-value, highest-sensitivity target in the whole system — treat it accordingly.

The EHR and partner integrations. The connections to electronic health records, e-prescribing, labs, and payment. Each integration is an arrow crossing your trust boundary into someone else's system, and each is only as safe as the contract and the credentials behind it. A leaked API key to an EHR is a breach of every record it can reach.

The third-party code inside your app. Analytics, crash reporting, chat widgets, advertising SDKs, AI features. This is the quietest and most common telehealth failure: a tracking script or analytics tag that quietly ships PHI to a vendor with no BAA. It is encrypted in transit and still a violation, because encrypted is not the same as compliant — data sent to a company that never signed a BAA is impermissibly disclosed regardless of the lock on the pipe. We catalog these in common HIPAA mistakes in telemedicine builds.

Step 3 — Find threats with STRIDE

Staring at a diagram and asking "what could go wrong?" works for experts and fails for everyone else, because you only find the threats you already know. STRIDE fixes that by giving you six prompts to apply to every element. It was created at Microsoft in 1999 and is the most widely used method precisely because it is a checklist a non-specialist can run. STRIDE stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. The letters are the inverse of the security properties you want, which is why the list is complete: each threat is a named way one guarantee can fail.

Walk each STRIDE category against each part of your data-flow diagram. Here is the mapping made concrete for telemedicine.

STRIDE threat What it means The property it breaks Telemedicine example
Spoofing Pretending to be someone else Authentication An attacker logs in as a clinician with a phished password and opens patient charts
Tampering Changing data in transit or at rest Integrity A lab result or prescription dose is altered on its way to the EHR
Repudiation Denying an action with no proof Non-repudiation A user accesses a record, then claims they never did, and no audit log can disprove it
Information disclosure Exposing data to the wrong party Confidentiality A misconfigured bucket leaks session recordings; an analytics SDK ships PHI without a BAA
Denial of service Making the system unavailable Availability A flood attack takes the platform down during scheduled consults — and availability is itself a HIPAA requirement
Elevation of privilege Gaining rights you should not have Authorization A patient account changes a parameter and reaches an admin endpoint

Notice that the same six properties — confidentiality, integrity, availability, plus authentication, authorization, and non-repudiation — are exactly what the HIPAA Security Rule tells you to protect (45 CFR §164.306(a) names confidentiality, integrity, and availability outright). STRIDE is not a parallel framework you bolt on for compliance; it is a structured way to produce the risk analysis HIPAA already requires.

Data-flow diagram of a telemedicine platform with a trust boundary, showing where each STRIDE threat applies along the path from patient app to EHR. Figure 2. STRIDE applied along a telemedicine data flow, with the trust boundary marked. Each crossing is a threat location.

For the privacy side, a sister checklist called LINDDUN runs the same way but asks privacy questions — is this data linkable across sessions, is the patient identifiable, is it detectable that they used the service at all, are we collecting more than they're aware of. You do not need it on day one, but for behavioral health, reproductive health, or any service where the fact of a visit is itself sensitive, run LINDDUN alongside STRIDE.

Step 4 — Rank the risks so you fix the right things first

A threat model that lists fifty threats with no order is a to-do list nobody finishes. You rank, so the team spends its limited time on the threats that matter. The simplest durable method is a two-factor judgment: how likely is this threat, and how big is the impact if it lands? Plot each threat on a likelihood-by-impact grid and the top-right corner — likely and damaging — is your work for this quarter.

Risk ranking matrix plotting telemedicine threats by likelihood and impact, with fix-now, plan, and accept zones. Figure 3. A likelihood-by-impact matrix turns a flat threat list into a priority order.

Let us show the arithmetic once, because ranking should be explainable, not a vibe. A common scheme scores likelihood and impact each from 1 (low) to 5 (high) and multiplies them for a risk score from 1 to 25.

Take "analytics SDK leaks PHI to a vendor with no BAA." Likelihood is high — it is one of the most common telehealth findings and easy to introduce by accident: call it 5. Impact is high — it is a reportable breach of potentially every user, with OCR penalties and notification costs: call it 5. Risk score = 5 × 5 = 25. That is a fix-now, top-of-the-list item.

Now "attacker physically steals a clinician's locked, encrypted laptop." Impact is moderate — the disk is encrypted, so exposure is limited: say 2. Likelihood is low: say 2. Risk score = 2 × 2 = 4. Real, but it waits behind the 25. The numbers are not science; their value is that they force a conversation and make the priority order defensible to an auditor.

Microsoft's older DREAD model adds more dimensions (damage, reproducibility, exploitability, affected users, discoverability) if you want finer granularity, but for most telehealth teams likelihood-by-impact is enough to start and easy to keep current.

Step 5 — Mitigate, then verify

For every high risk, choose one of four responses and write it down. Mitigate — add a control that reduces the risk (encrypt the bucket, add MFA, sign the BAA). Transfer — push the risk to someone contractually equipped to hold it (use a BAA-covered CPaaS instead of running your own media servers). Accept — for a low risk, document that you are knowingly living with it and why. Avoid — drop the feature that creates the risk (do not record sessions you do not need).

Then verify the mitigation actually works — a control you assumed but never tested is not a mitigation. This is where penetration testing, security code review, and the audit logging that lets you detect and reconstruct an incident come in. Audit logs deserve special mention: they are your only defense against the "R" in STRIDE, repudiation, and they are required by HIPAA's audit-controls standard (45 CFR §164.312(b)). We cover them in audit logging and access controls for clinical video.

The whole thing is a loop, not a one-time event. The proposed 2026 Security Rule update would require reviewing the analysis at least annually and after any major change. That is good engineering regardless of the rule: every new integration, every new AI feature, every new data store reopens the diagram. Re-run the model when the system changes, not when the auditor calls.

Common mistake: treating the threat model as a document, not a habit. The most frequent failure is not a missing control — it is a threat model written once before launch, filed, and never opened again. Six months later the product has an AI scribe, two new EHR integrations, and a mobile app, none of which were in the original diagram. A stale threat model gives false comfort and, after a breach, reads to a regulator like negligence. Tie the model to your change process: no major feature ships without a five-minute "does this touch the diagram?" check.

A worked walkthrough

Put it together on one flow: a patient joins a video visit. Draw it — patient app → signaling server → SFU (media) → recording pipeline → recordings store; and patient app → API → patient database → EHR bridge → EHR. Mark the trust boundary around everything you host plus your BAA-covered vendors.

Now run STRIDE on the recording path. Spoofing: can someone join the call as the clinician? Mitigation: MFA and per-session tokens. Tampering: can the recording be altered after the fact? Mitigation: write-once storage and integrity hashes. Information disclosure: is the recordings bucket private, encrypted, and BAA-covered? This is the 25-score risk — verify it first. Denial of service: if the recorder fails, does the consult still happen? Design it so recording failure never blocks care. Elevation of privilege: can a support engineer reach raw recordings? Mitigation: least-privilege roles and access logged. In ten minutes you have produced a ranked, defensible slice of your HIPAA risk analysis — and you can hand the same exercise to every other flow.

Where Fora Soft fits in

Fora Soft has built real-time video products since 2005 — telemedicine, video conferencing, streaming, surveillance, e-learning — and in healthcare the threat model comes before the architecture, not after. We start a clinical build by drawing the PHI boundary and walking STRIDE across every data flow, so that encryption, BAA coverage, access control, and audit logging are designed in rather than retrofitted under audit pressure. The requirement comes first; the capability follows. If you are scoping a telehealth product, a threat-model session is the cheapest hour you will spend and the one that shapes everything after it.

What to read next

Call to action

References

  1. HHS, HIPAA Security Rule, 45 CFR §164.308(a)(1)(ii)(A) — Risk analysis (required implementation specification of the Security Management Process). Tier 1. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308
  2. HHS, HIPAA Security Rule, 45 CFR §164.306(a)–(b) — General requirements (confidentiality, integrity, availability; flexibility of approach). Tier 1. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.306
  3. HHS, HIPAA Security Rule, 45 CFR §164.312 — Technical safeguards (access control, audit controls §164.312(b), integrity, person/entity authentication, transmission security). Tier 1. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312
  4. HHS / OCR, NPRM "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information," 90 FR 898, published 2025-01-06, RIN 0945-AA22 — proposes mandatory written risk analysis with asset inventory and network map, MFA, encryption, 6-month vulnerability scanning, 12-month penetration testing, annual compliance audit. Proposed, not final as of 2026-06-14; comment period closed 2025-03-07. Tier 1. https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information
  5. NIST, SP 800-30 Rev. 1, Guide for Conducting Risk Assessments (threat sources, threat events, vulnerabilities, likelihood, impact). Tier 1. https://csrc.nist.gov/pubs/sp/800/30/r1/final
  6. NIST, SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide (Feb 2024). Tier 1. https://csrc.nist.gov/pubs/sp/800/66/r2/final
  7. FDA, FD&C Act §524B and "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" (final guidance issued 2025-06-27) — threat model required in premarket submissions for cyber devices, STRIDE or PASTA acceptable. Tier 1. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-management-system-considerations-and-content-premarket
  8. Microsoft / Kohnfelder & Garg, STRIDE threat modeling (1999); Microsoft Threat Modeling methodology and DREAD risk rating. Tier 3. https://en.wikipedia.org/wiki/STRIDE_model
  9. LINDDUN privacy threat modeling framework (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Noncompliance). Tier 3. https://www.linddun.org/
  10. OWASP, Threat Modeling Process and Threat Dragon (data-flow diagrams, trust boundaries). Tier 6. https://owasp.org/www-community/Threat_Modeling_Process
  11. HIPAA Journal, 2025 Healthcare Data Breach Report — ~61.5M individuals affected in 2025; healthcare the top ransomware target; OCR Risk Analysis Initiative enforcement pattern. Tier 5 (re-verify at publication). https://www.hipaajournal.com/2025-healthcare-data-breach-report/
  12. Sidley / Data Matters, "Risk Analysis in the Crosshairs: Four Recent Ransomware Resolutions Preview the HIPAA Security Rule Amendments" (2026-06-01) — §164.308(a)(1)(ii)(A) findings across OCR ransomware settlements. Tier 5. https://datamatters.sidley.com/2026/06/01/risk-analysis-in-the-crosshairs-four-recent-ransomware-resolutions-preview-the-hipaa-security-rule-amendments/
  13. WebRTC.ventures, "WebRTC Security in 2025" — signaling MitM, TURN credential hijacking, ephemeral-credential mitigations. Tier 4. https://webrtc.ventures/2025/07/webrtc-security-in-2025-protocols-vulnerabilities-and-best-practices/

Where lower-tier sources (breach statistics, vendor security blogs) touched a compliance claim, the article follows the rule text and named guidance (refs 1–7) and uses the lower-tier sources only for context and current numbers. Specifically, the "risk analysis is the most-cited enforcement finding" framing is anchored to the rule (ref 1) and the law-firm analysis (ref 12), not to a vendor blog.