If you run a telehealth startup, your first big hospital contract will almost certainly come with a security questionnaire. Somewhere on that questionnaire, usually near the top, is a question about your most recent third-party penetration test. Hospital procurement teams, health system CISOs, and payer partners want proof that your video platform, patient portal, and mobile apps have been tested by someone who knows what to look for. Without a recent report, deals stall for months.
Telemedicine penetration testing is different from testing a standard SaaS product. A telehealth platform combines real-time video, secure messaging, file sharing, e-prescribing workflows, scheduling, mobile apps, and cloud storage, and nearly every one of those components touches protected health information (PHI). That creates a wide attack surface, and the same weaknesses show up again and again.
This guide walks through the 15 vulnerabilities Redfox Cybersecurity finds most often during telehealth security testing, explains why each one matters for HIPAA and SOC 2, and gives you a practical checklist you can use before your next audit or hospital security review.
During the COVID-19 public health emergency, HHS Office for Civil Rights relaxed enforcement for telehealth tools used in good faith. That enforcement discretion ended on August 9, 2023. Today, telehealth vendors that handle PHI are expected to meet the full HIPAA Security Rule, sign Business Associate Agreements (BAAs) with covered entities, and demonstrate that their safeguards actually work.
For a growing telehealth company, two documents open doors: a SOC 2 Type II report and a recent penetration test report. SOC 2 auditors look for evidence of vulnerability identification and remediation under the Common Criteria, while hospital security teams want to see that your application has been tested manually against realistic attack scenarios. A scanner report rarely satisfies either group.
The current HIPAA Security Rule requires a risk analysis and periodic technical evaluation of safeguards. In January 2025, HHS proposed updates to the Security Rule that would require penetration testing at least once every 12 months. Whether or not the final rule lands exactly as proposed, hospital partners are already asking for annual testing in their vendor contracts.
A typical telemedicine platform includes:
Each layer needs to be tested on its own and as part of the whole. If you are preparing for a hospital security review, Redfox Cybersecurity can scope a telehealth penetration test that covers every one of these components in a single engagement.
The issues below are grouped by the part of the platform they affect. For each one, we explain the risk and what a fix looks like.
WebRTC establishes peer-to-peer connections by exchanging ICE candidates, which can include the local and public IP addresses of both participants. In a telehealth call, that can expose a patient's home IP address or a provider's internal network address to the other party. For behavioral health platforms or services where patient privacy is especially sensitive, this is a serious concern.
Fix: Route media through a TURN relay when privacy requires it, restrict which ICE candidate types are shared, and avoid exposing internal network addresses from provider workstations.
TURN servers relay media when direct connections fail. We regularly find TURN servers with static, long-lived credentials embedded in client code, or servers that allow relaying to internal network ranges. Either problem can turn your media infrastructure into a pivot point into your cloud environment.
Fix: Issue short-lived, per-session TURN credentials from your backend, block relaying to private and cloud metadata address ranges, and keep TURN software patched.
Some platforms generate consultation room links with short or predictable identifiers, or allow anyone with the link to join without verifying identity. Others have waiting room logic that is enforced only in the user interface, not on the server. The result is a risk that an unauthorized person could join or observe a consultation.
Fix: Use long, random room identifiers, bind room access to authenticated users and scheduled appointments, and enforce waiting room and admission logic on the server side.
Many telehealth platforms record consultations for quality, training, or clinical documentation. Those recordings often end up in Amazon S3 or similar object storage. We frequently find buckets with overly permissive policies, public access settings left enabled, or recordings stored without server-side encryption using customer-managed keys. A recorded consultation is about as sensitive as PHI gets.
Fix: Enable S3 Block Public Access at the account level, enforce encryption with KMS, restrict bucket policies to specific service roles, and enable access logging on every bucket that holds PHI.
Pre-signed URLs are a good way to give temporary access to recordings and documents, but only if they expire quickly. We often see URLs valid for days or weeks, shared through chat or email, and never tied back to the requesting user. If one leaks, anyone can open the file until it expires.
Fix: Keep expiry windows short, generate URLs only after an authorization check, and log every URL issuance against the user who requested it.
Cloud storage misconfigurations are among the most common causes of PHI exposure. A cloud penetration test from Redfox Cybersecurity reviews your bucket policies, IAM roles, and encryption settings alongside your application.
Insecure direct object references (IDOR) are the single most common high-severity issue we find in telehealth platforms. An API endpoint returns a consultation, prescription, lab result, or chat history based on an ID in the request, but does not confirm that the logged-in user is allowed to see that record. A patient who changes one value in a request could potentially view another patient's consultation notes.
Automated scanners almost never catch IDOR because they cannot tell which records belong to which user. Finding it requires manual testing with multiple accounts across patient, provider, and administrator roles.
Fix: Enforce object-level authorization on every endpoint that returns or modifies PHI, use non-sequential identifiers as a secondary control, and write automated tests that confirm users cannot access each other's data.
Related to IDOR, this occurs when a patient account can call endpoints intended for providers or administrators. Examples include viewing a provider's full patient list, changing appointment assignments, or accessing reporting features. These endpoints are often hidden from the patient interface but still reachable through the API.
Fix: Apply role checks at the API layer, not just in the frontend, and maintain a clear authorization matrix that maps every endpoint to the roles allowed to use it.
APIs frequently return more data than the interface displays. A provider search endpoint might return full date of birth, phone numbers, and insurance details when the app only shows a name. Anyone inspecting the network traffic can see the extra fields.
Fix: Define response schemas explicitly, return only the fields each role needs, and review GraphQL schemas for fields that should not be queryable by patients.
When an API accepts an entire object and saves it without filtering, users may be able to set fields they should not control, such as their role, account status, assigned provider, or billing flags.
Fix: Use allowlists of editable fields for every update endpoint and reject requests that include unexpected properties.
Authorization flaws like these are the reason manual testing matters. Redfox Cybersecurity's web application and API penetration testing covers every role in your platform with dedicated test accounts.
Many platforms implement MFA correctly at login but leave gaps in password reset, email change, or phone number change flows. Common issues include one-time codes without rate limiting, reset tokens that do not expire, and recovery flows that skip MFA entirely.
Fix: Apply rate limiting and lockout to every code entry point, expire reset tokens quickly, require re-authentication for sensitive account changes, and notify users when recovery details change.
We often find JWTs with long lifetimes and no server-side revocation, so logging out does not actually end the session. On shared clinic devices or family tablets, this means the next user may inherit an active session with full PHI access.
Fix: Use short-lived access tokens with refresh token rotation, support server-side revocation on logout and password change, and set idle timeouts appropriate for clinical use.
Telehealth mobile apps often cache consultation summaries, chat messages, images, or authentication tokens on the device in unencrypted storage. If a phone is lost, shared, or backed up to an unprotected location, that PHI goes with it.
Fix: Store tokens in the iOS Keychain or Android Keystore, encrypt any cached PHI, exclude sensitive data from device backups, and clear caches on logout.
Patient-provider messaging features that render rich text or file names without proper output encoding can allow stored cross-site scripting. Because providers read messages from many patients, a single malicious message could affect a provider session with broad access.
Fix: Apply context-aware output encoding, sanitize any rich text with a vetted library, and deploy a strict Content Security Policy on the provider dashboard.
Patients upload photos, lab results, insurance cards, and referral documents. We regularly find upload features that accept any file type, store files with user-controlled names, or serve uploads from the same domain as the application without content-type protections.
Fix: Validate file types on the server, rename files on upload, scan for malware, and serve user content from a separate, sandboxed domain.
The HIPAA Security Rule requires audit controls that record and examine activity in systems containing PHI (45 CFR 164.312(b)). In practice, we find two opposite problems. Some platforms do not log who viewed which patient record, so there is no way to investigate a suspected privacy incident. Others log too much, writing PHI such as names, diagnoses, or message contents into application logs, error trackers, and third-party analytics tools that are not covered by a BAA.
Fix: Log every access to PHI with user, patient, action, and timestamp; store audit logs in a tamper-evident location with restricted access; scrub PHI from debug logs and error reports; and review every analytics and tracking tool for PHI exposure.
Logging gaps often surface during SOC 2 audits and breach investigations at the worst possible time. If you are unsure whether your audit trail would hold up, talk to Redfox Cybersecurity about including logging and monitoring review in your next engagement.
Use this checklist to review your platform before a hospital security review, SOC 2 audit, or formal penetration test. Each item maps to one of the vulnerabilities above.
A well-scoped penetration test does more than produce a list of findings. It gives your compliance team evidence it can use across multiple frameworks.
SOC 2 auditors look for evidence that you identify vulnerabilities, assess their risk, and remediate them on a defined timeline. A penetration test report with risk-rated findings, followed by a retest showing fixes, provides clean evidence for logical access and system operations controls under the Common Criteria.
Hospital vendor risk teams typically ask for an executive summary they can share internally, confirmation that testing was manual and covered authenticated roles, the date of the test, and proof that critical and high findings were fixed. An attestation letter is often enough to move a deal forward without sharing the full technical report.
At minimum, test annually. You should also test after significant changes, including:
Plan for at least six weeks between the start of testing and any audit or contract deadline. That window allows time for testing, remediation, and a retest that confirms fixes.
The more prepared you are, the more value you get from the engagement. Before testing begins, have the following ready:
Redfox Cybersecurity scopes every engagement before testing starts and provides a fixed quote. Schedule a scoping call with Redfox Cybersecurity to get a test plan built around your platform.
Winning hospital clients takes more than a strong product. It takes proof that your platform protects patient data under real-world attack conditions. If you want a manual, healthcare-focused assessment that covers video, APIs, mobile apps, and cloud storage in one report, get in touch with Redfox Cybersecurity and start your telehealth security testing today.
Redfox Cyber Security Inc.
8 The Green, Ste. A,
Dover, Delaware 19901,
United States.
.avif)
