The safest answer is not “buy a HIPAA-compliant VPN.” The better answer is to build HIPAA-compliant remote access, then decide whether a VPN, ZTNA, or another secure access model fits the job. A VPN can support HIPAA compliance, but it is not compliant by magic, and it often gives users more network access than they need.
TLDR: HIPAA does not certify VPNs, so a “HIPAA-compliant VPN” really means a VPN configured with encryption, identity controls, audit logs, access limits, and proper policies. For example, a 150-person clinic may cut remote access risk by replacing broad VPN access with ZTNA rules that allow billing staff into one EHR portal, not the whole internal network. If a stolen password is used, MFA and device checks can block the login or limit the blast radius. VPNs still work well for some use cases, but ZTNA and secure access service edge tools often give sharper control.
What HIPAA Actually Requires
HIPAA does not name a specific VPN product. It does not say, “Use vendor X.” The Security Rule requires covered entities and business associates to protect electronic protected health information, or ePHI. That includes confidentiality, integrity, and availability.
For remote access, the key safeguards usually include:
- Access control: users get only the systems they need.
- Unique user IDs: no shared logins for nurses, coders, or contractors.
- Encryption: ePHI is protected in transit and, where needed, at rest.
- Audit controls: access must be logged and reviewable.
- Authentication: users must prove who they are, ideally with MFA.
- Transmission security: data must be protected across public networks.
A VPN can help with transmission security. That is only one slice of the work. If the VPN connects a remote laptop to an entire subnet full of file shares, imaging systems, and admin panels, the risk can get ugly fast.
So, What Is a HIPAA-Compliant VPN?
A HIPAA-compliant VPN is not a special legal category. It is a VPN service or appliance used in a way that supports HIPAA requirements. The configuration matters more than the label on the website.
At minimum, the setup should include AES 256 encryption or similarly strong encryption, secure protocols such as IPsec, IKEv2, or WireGuard, and multi-factor authentication. It should also log sessions, restrict access by role, and integrate with identity tools such as Active Directory, Entra ID, Okta, or another identity provider.
Healthcare teams should also ask whether the vendor will sign a Business Associate Agreement, often called a BAA, if the vendor may create, receive, maintain, or transmit ePHI. Some VPN vendors avoid touching customer traffic content and may argue a BAA is not needed. Maybe. Maybe not. Ask counsel and document the decision. Guessing here is how audits become painful.
Where Traditional VPNs Still Make Sense
VPNs are not dead. They are useful for specific cases, especially when a device needs network-level access to internal systems. A radiology workstation, an IT admin laptop, or a legacy practice management server may still require a VPN.
VPNs are also familiar. IT teams know how to deploy them. Users know the routine: open client, enter code, connect. That simplicity has value, especially for small clinics with tight budgets.
The catch is that many VPNs were built for trust once users get inside. That model feels dated. A user connects, and suddenly their laptop may see far more than the appointment system or claims portal. If that laptop is infected, the VPN can become a private road into sensitive systems.
The Problems with VPNs in Healthcare
Traditional VPNs can create daily friction. Honestly, it feels like some clients exist to waste 45 extra seconds every time a nurse practitioner needs to check a chart from home. Updates break profiles. Split tunneling gets misconfigured. Help desks get flooded after password resets.
Security issues are more serious:
- Broad access: users may reach entire network segments.
- Weak device checks: personal laptops may connect without proper posture review.
- Poor visibility: logs may show a connection, but not which application actions occurred.
- Credential risk: stolen passwords can lead to wide access if MFA is weak or missing.
- Legacy exposure: old VPN appliances are frequent targets when patches lag.
Healthcare is full of legacy systems that cannot be rebuilt overnight. That makes narrow access even more valuable. If an attacker compromises one account, they should not get a guided tour of the network.
ZTNA: A Better Fit for Many Remote Access Needs
Zero Trust Network Access, or ZTNA, flips the old VPN idea. Instead of placing the user “on the network,” ZTNA grants access to specific applications based on identity, device health, location, risk level, and policy.
A billing contractor may get access to a claims application. A physician may get access to the EHR and secure messaging. An IT admin may get privileged access, but only from a managed device with MFA and session recording. That is a cleaner model.
ZTNA also reduces exposure. Internal applications do not need to be visible to the open internet. Users authenticate first, then receive access only to approved resources. If a user fails a device check, access can be denied or limited.
For HIPAA programs, this helps with minimum necessary access, auditability, and consistent enforcement. It also supports remote work without pretending every home Wi Fi network is safe.
Secure Remote Access Alternatives to VPN
ZTNA is one option, but not the only one. Many healthcare groups combine several tools.
- VDI or virtual desktops: clinicians use a remote desktop while ePHI stays in the data center or cloud environment.
- Secure browser isolation: contractors use web apps without downloading data to unmanaged devices.
- Privileged access management: admins use approved workflows, session recording, and just-in-time access.
- SASE platforms: networking and security controls are delivered through cloud-based access points.
- MDM and endpoint detection: devices are checked, patched, encrypted, and monitored before access is granted.
These tools can pair with VPNs. A hospital does not need to rip everything out at once. A practical move is to keep VPN access for systems that truly need it, then move EHR portals, billing tools, and vendor access to ZTNA or app-level controls.
How to Choose the Right Model
Start with the use case, not the product pitch. Ask these questions:
- Who needs access? Employees, contractors, vendors, clinicians, or IT admins?
- What do they need? One app, several apps, or full network access?
- What device are they using? Managed laptop, personal tablet, or shared workstation?
- Will ePHI be downloaded? If yes, endpoint controls matter a lot.
- Can activity be logged? You need records that help during investigations.
A small therapy practice may be fine with a business-grade VPN, MFA, managed devices, and strong logging. A regional hospital with hundreds of vendors will likely need ZTNA, privileged access controls, and segmentation. A telehealth company may prefer browser-based access where possible, with no local data storage.
HIPAA Checklist for VPN or ZTNA
Whether you choose VPN, ZTNA, or a blended model, the control list should be firm:
- Require MFA for all remote access.
- Use role-based access and review permissions often.
- Encrypt traffic with modern protocols.
- Log access and retain logs according to policy.
- Check device health before connection.
- Disable dormant accounts quickly.
- Patch VPN gateways and access brokers without delay.
- Segment systems that store or process ePHI.
- Get BAAs when vendors handle ePHI.
- Test incident response before an actual breach.
The Practical Recommendation
Use a VPN when network-level access is truly needed. Lock it down with MFA, segmentation, logging, and managed devices. Do not treat it as a blanket pass into the internal network.
Use ZTNA when users only need specific applications. It usually gives better control, better logs, and less exposure. For vendors and contractors, it is often the cleaner choice.
The best HIPAA remote access strategy is usually mixed. Keep what works, reduce broad access, and move sensitive workflows toward identity-based, application-specific controls. That approach is less flashy than buying a tool with a compliance claim, but it is far safer and easier to defend during an audit.
