Why Telehealth Providers Need a Router-Level VPN, Not Just a VPN App
Telehealth Security / HIPAA Compliance
Why Telehealth Providers Need a Router-Level VPN, Not Just a VPN App
You've done the right things. You've subscribed to a reputable VPN service, you've got a HIPAA-compliant telehealth platform with a signed Business Associate Agreement, and you remind yourself to click "connect" before your first session of the day. Your patient data is protected. Right?
Not entirely. And the gap is smaller than you'd think, but consequential enough to show up in a security audit — or worse, a breach notification.
This post explains exactly where software VPNs fall short for telehealth providers, what a router-level VPN actually does differently at the network layer, and why the distinction matters under HIPAA's Transmission Security standard (45 CFR § 164.312(e)(1)).
What a VPN App Actually Does — and Doesn't Do
A VPN application installed on your laptop or phone creates an encrypted tunnel for traffic originating from that specific device, on that specific application instance, while it is running. That's a meaningful protection, but it comes with four structural weaknesses that matter in a healthcare context.
1. The app has to be running
Every telehealth provider who has ever clicked "start session" without first clicking "connect VPN" has transmitted Protected Health Information (PHI) over an unencrypted public network. This isn't a failure of discipline — it's a design problem. The VPN app is optional, and humans under cognitive load will skip optional steps. Audits that check VPN connection logs will find those gaps.
2. Other devices on your network are unprotected
Your laptop runs the VPN app. Your smart TV, your spouse's phone, your networked printer, your IoT thermostat — none of them are covered. In a home office or hotel setup, this is relevant: unsecured devices on the same local network can expose your traffic through ARP spoofing or DNS poisoning attacks even when your VPN is active on the target device.
3. Split tunneling can silently leak PHI
Many VPN providers enable split tunneling by default to preserve bandwidth. In this configuration, traffic is selectively routed — some goes through the encrypted tunnel, some goes directly to the internet. Unless you have explicitly audited which traffic goes where, there is a real possibility that metadata from your telehealth session is leaking outside the tunnel.
4. DNS queries may bypass the tunnel entirely
Even when a VPN tunnel is active, misconfigured DNS settings can result in DNS queries going to your ISP's resolver rather than through the VPN. This leaks information about which domains you're connecting to, including your telehealth platform's domain, timestamps, and session frequency — all of which can qualify as PHI identifiers under HIPAA's 18-identifier definition.
"The assumption that 'I have a VPN' equals 'I am encrypted' is the most common security misunderstanding in remote telehealth setups — and it's the one OCR is increasingly interested in."
What Router-Level VPN Does Differently
A VPN configured at the router level encrypts all outbound traffic from every device connected to that network before it leaves the local network. The VPN is always on, always enforced, and not dependent on any user remembering to activate an app. Here's what that changes in practice:
-
Always-on by default No user action required. Every session — whether it's your EHR, your video platform, or a file transfer — is encrypted from the moment the device connects to the network. There's no window of unprotected traffic between device startup and VPN app activation.
-
Covers every device on the network Your phone, your tablet, your smart speaker, any device a colleague brings into your home office. All traffic from all devices is routed through the VPN tunnel without per-device configuration.
-
Eliminates client-side split tunneling risk Traffic routing decisions are made at the router, not at the application layer. You control exactly what goes through the tunnel at the network level, with no per-app VPN client behavior to audit.
-
DNS resolution stays inside the tunnel DNS queries are handled by the router's DNS configuration, keeping domain lookups encrypted and preventing the DNS-leak class of HIPAA exposure.
-
Produces a cleaner audit trail Network-level VPN logs are centralized and consistent, not scattered across individual device VPN clients. During a risk assessment or breach investigation, this significantly simplifies demonstrating Transmission Security compliance.
The BAA Angle Most Providers Miss
Here's a detail that changes the compliance picture significantly: when a telehealth provider routes traffic through a commercial VPN service, that provider may qualify as a Business Associate under HIPAA, because they are transmitting PHI on your behalf. This means you need a signed BAA with your VPN provider before using it for telehealth — not just a privacy policy you've skimmed.
Most consumer VPN providers (NordVPN, ExpressVPN, Surfshark, and similar services) do not offer BAAs. Using them for telehealth without a BAA is, by default, a HIPAA violation regardless of how strong their encryption is.
There is a partial exception: the HIPAA "conduit exception" applies to vendors that transmit PHI without accessing or storing it. Some VPN providers argue they qualify. However, OCR guidance makes clear that any vendor with potential access to PHI must execute a BAA. If you're relying on the conduit exception, your legal and compliance team should confirm that position in writing before your next risk assessment.
The router-level VPN sidesteps this problem cleanly when the VPN tunnel terminates at your own home server or office network — because in that configuration, no third-party vendor is handling your PHI at all. The encrypted tunnel runs from your remote location back to infrastructure you control. No BAA required for the tunnel itself.
Software VPN vs. Router VPN: Side-by-Side
| Capability | VPN App (Software) | Router-Level VPN |
|---|---|---|
| Always-on enforcement | No — user must activate | Yes — active for all traffic |
| Covers all devices | No — per device only | Yes — entire network |
| DNS leak prevention | Partial — varies by app/config | Yes — router-controlled DNS |
| Split tunneling risk | Present — often on by default | Managed at network level |
| Requires BAA from VPN vendor | Yes — if using commercial service | No — if tunnel ends at own infrastructure |
| Centralized audit log | No — scattered across clients | Yes — at router level |
| Setup complexity | Low — app install | Moderate — router configuration |
| Works across all operating systems | Partial — per-OS clients needed | Yes — OS-agnostic |
Protocol Choice Matters: WireGuard vs. OpenVPN for Telehealth
If you're implementing a router-level VPN, the protocol you choose has direct implications for telehealth video quality. Telehealth video is latency-sensitive — even 100ms of added jitter noticeably degrades the experience.
OpenVPN is the established standard: battle-tested, audited, and widely supported. The tradeoff is performance — its codebase is large, which introduces latency overhead and higher CPU load, especially on lower-powered routers.
WireGuard is the better choice for telehealth specifically. Its codebase is dramatically smaller (~4,000 lines vs. OpenVPN's ~100,000+), which translates to lower latency, faster handshakes, and significantly better throughput on mobile and battery-constrained devices. Modern cryptography by default (ChaCha20, Curve25519, BLAKE2s), no legacy cipher negotiation, and faster reconnection when networks switch — all of which matter for a provider moving between WiFi and cellular during a shift.
For telehealth use on a router-level VPN: WireGuard over UDP, AES-256 or ChaCha20 encryption, with kill-switch behavior enforced at the firewall level so traffic stops completely if the tunnel drops rather than falling back to an unencrypted connection.
The Traveling Telehealth Provider Problem
This is where the gap between "I have a VPN app" and "my network is secure" is most visible in practice. Consider the scenario: a locum physician, traveling therapist, or remote psychiatrist conducting sessions from a hotel room. They connect to the hotel's WiFi, open their VPN app, and begin the session.
What they may not know:
The hotel network may be performing SSL inspection on its own router, meaning their device establishes a TLS connection to the hotel's proxy before any VPN app traffic is routed out. The time between connecting to the hotel WiFi and activating the VPN app — even ten seconds — may be enough for automatic background sync from their EHR app to transmit session metadata unencrypted. Their phone, which they use for two-factor authentication into the EHR, is on the same hotel WiFi with no VPN protection whatsoever.
A travel router pre-configured with a VPN tunnel back to a known-good network eliminates all three vectors. You plug into the hotel's ethernet port or connect to hotel WiFi through your travel router, and every device you connect to that router is encrypted immediately — no app activation, no per-device setup, no exposure window.
Pre-Flashed Routers Built for Exactly This
FlashedRouter offers routers pre-configured with OpenWrt and VPN firmware — including WireGuard and OpenVPN support — specifically for users who need reliable, always-on VPN tunneling without the configuration overhead. For telehealth providers who travel or work across multiple locations, a travel-sized flashed router running WireGuard eliminates the per-device, per-session VPN activation problem entirely. Every device on your network is covered from the moment you plug in.
Explore VPN Routers →What Your HIPAA Risk Assessment Should Ask About Your VPN Setup
OCR's Security Rule requires a documented risk analysis covering all systems that transmit ePHI. Most practices assess their telehealth platform but don't assess their VPN configuration specifically. Here are the questions your risk assessment should be able to answer:
-
Is VPN use mandatory or optional for telehealth sessions? Optional means non-compliant sessions are a certainty over time, not a possibility.
-
Does your VPN provider have a signed BAA, or do you tunnel to infrastructure you control? One of these is compliant without further paperwork. The other requires documentation.
-
What happens to traffic if the VPN connection drops mid-session? Does it fail-open (unencrypted traffic continues) or fail-closed (traffic stops until tunnel is restored)? HIPAA requires fail-closed behavior.
-
Are DNS queries routed through the VPN tunnel? DNS leak testing should be part of your annual risk assessment, not a one-time setup check.
-
Which devices transmit ePHI, and are all of them covered? If your risk assessment only lists your primary workstation, you have an incomplete picture.
Frequently Asked Questions
Does HIPAA explicitly require a VPN?
No. HIPAA's Security Rule requires Transmission Security safeguards (45 CFR § 164.312(e)(1)) but does not mandate specific technologies. However, transmitting ePHI over public networks without encryption is a clear violation, and VPN — particularly at the router level — is the most straightforward way to satisfy the requirement for all devices and sessions.
Can I use NordVPN or ExpressVPN for telehealth?
These services do not offer Business Associate Agreements. Without a BAA, using them to transmit PHI is technically a HIPAA violation. Some compliance attorneys argue the conduit exception applies; others disagree. The safest path is to use a VPN that terminates at infrastructure you control — which is exactly what a router-level WireGuard or OpenVPN tunnel to your own home or office network provides.
Will a router VPN slow down my telehealth video calls?
With WireGuard protocol, overhead is minimal — typically under 5% throughput reduction on modern routers. The performance impact of properly configured WireGuard on a current-generation router is far less than the packet loss and jitter introduced by a congested hotel WiFi network, which the VPN tunnel itself helps stabilize by providing a consistent endpoint.
What router hardware supports this setup?
Any router running OpenWrt or DD-WRT firmware supports WireGuard and OpenVPN at the router level. Hardware choice matters for throughput — routers with hardware AES acceleration handle encrypted traffic without CPU bottlenecks. For a traveling provider, compact travel routers running OpenWrt with a WireGuard tunnel are a practical, portable solution that works across hotel ethernet, hotel WiFi, and cellular hotspots.
My telehealth platform already uses TLS encryption. Isn't that enough?
TLS encrypts the application layer between your device and the platform's servers. It does not encrypt DNS queries, does not protect other devices on your network, does not prevent metadata leakage, and does not help with the dozens of other ePHI touchpoints (EHR sync, email, scheduling tools) that may be active during a session. Router-level VPN and application-layer TLS complement each other — neither replaces the other.
The Bottom Line
A VPN app is better than no VPN. But for telehealth providers operating under HIPAA, it's an incomplete solution: dependent on user behavior, limited to one device, and structurally exposed to DNS leaks, split tunneling, and connection-window gaps.
Router-level VPN closes all of those gaps. It's always on, covers every device, produces a clean audit trail, and — when it terminates at your own infrastructure — eliminates the BAA problem with commercial VPN services entirely.
If your current risk assessment doesn't explicitly address which layer your VPN operates at, and whether all PHI-transmitting devices are covered, it's worth revisiting before OCR does it for you.