Somewhere in your practice, someone works from home. Maybe it is the biller who reconciles claims two days a week from her kitchen table, or the office manager who logs in on a Sunday to fix a scheduling snarl, or a clinician who needs to check a chart after hours. However it started, the question is the same one every small practice eventually asks: how do we let a trusted person reach the office network and the EHR from somewhere that is not the office, without leaving the door open for everyone else?
For twenty years the default answer was a VPN. You opened a port on the office firewall, handed staff a login, and their home laptop dropped onto the office network as if it were sitting at a desk. It worked, it was cheap, and it is now quietly falling out of favor, not because VPNs stopped encrypting traffic, but because the thing they were designed to do, place a remote device onto your network, is exactly the thing you do not want when a laptop gets stolen or a password gets phished.
This post walks through the two models plainly: how a VPN works, how the newer “zero-trust” approach differs, why the old “open a port and connect” pattern is aging badly, and how to choose for a small practice. There is a HIPAA angle too, because the moment patient information crosses that connection, encryption and access control stop being nice-to-haves and start being things an auditor asks about. No panic, no hype, just the honest shape of the problem.
What a VPN actually is¶
A VPN, or virtual private network, is an encrypted tunnel between a device and a network. The consumer VPNs advertised on podcasts are about privacy, hiding your browsing from the coffee-shop Wi-Fi. That is not what we are talking about. The VPN a business uses for remote access does something more consequential: it takes your employee’s home laptop and, over an encrypted connection, makes it a member of the office network. Once connected, that laptop can reach the same things a computer physically plugged in at the office can: the file server, the EHR, the practice-management software, the network printer, the whole neighborhood.
Mechanically, the office firewall listens for incoming VPN connections on a specific port, which is a numbered doorway on your public internet address. The remote user runs VPN client software, authenticates with a username and password (and, if you set it up well, a second factor), and the firewall builds the encrypted tunnel. From then on, traffic between the laptop and the office is scrambled, so anyone intercepting it on public Wi-Fi sees only noise.
The encryption part is genuinely good, and it is why VPNs are not going away entirely. The problem is not the tunnel. The problem is where the tunnel puts you: on the network, with the run of the place.
Where the classic VPN model breaks down¶
The weakness of the traditional VPN is not a bug. It is the design working as intended, in a world that changed underneath it.
A VPN grants access to a network, not to a specific application. Once a device connects, it is treated as trusted and generally allowed to reach everything on that network unless you have done the extra, tedious work of segmenting and firewalling the inside. Most small practices have not, because doing it well is hard and no vendor sets it up by default. So “connected to the VPN” means “can reach the EHR, the file share, the backup server, and the front-desk PC.” That broad reach has a name when an attacker gets hold of it: lateral movement, the ability to hop from one foothold to everything else nearby.
Here is why that matters now. The VPN’s security rests almost entirely on the login. If the credential is right and the device connects, the tunnel opens and the network is exposed to whatever is on the other end. But credentials are the single most stolen thing in security: phished, reused, and dumped by the billion. And a VPN cannot tell the difference between your biller logging in from her laptop and an attacker logging in from Belarus with her phished password. Both present a valid credential; both get dropped onto the network with the same broad access.
Three specific things have made the classic model age badly:
- The open port is a target. That doorway your firewall keeps listening on is visible to the entire internet, and attackers scan for exactly these VPN endpoints constantly. Over the last few years, several widely used business VPN products have shipped serious vulnerabilities in that internet-facing component, and criminals have used them to walk straight in before patches were applied. An exposed VPN gateway is a permanent thing you have to keep perfectly patched, forever.
- The device is trusted without being checked. A traditional VPN happily connects a laptop riddled with malware, or a personal device with no disk encryption, or a machine three months behind on updates. It authenticates the user, not the health of the machine, and then hands that machine the network.
- Flat networks turn a small breach into a big one. Because most small offices run one flat internal network, a single compromised VPN session does not stay contained. It becomes a launch pad. This is precisely the pattern behind a large share of small-business ransomware: get onto the VPN, then spread.
None of this means a VPN is negligent. It means the VPN’s core assumption, inside the tunnel equals trusted, no longer holds when the people, devices, and threats have all moved outside the building.
What zero-trust access actually is¶
Zero-trust is a reaction to exactly that assumption. The marketing around it is dreadful, so let me strip it to the one idea that matters: never trust a connection just because it got inside; verify every request, and grant the least access that gets the job done.
The formal term for the remote-access flavor of this is ZTNA, or zero-trust network access. Where a VPN says “prove who you are once, then here is the network,” a zero-trust setup says “prove who you are, prove your device is healthy, and here is access to this one application, nothing else.” The unit of access shrinks from the whole network down to a single app.
For a small practice, zero-trust access usually shows up as a lightweight overlay service. Products in this category include Tailscale, Twingate, and Cloudflare Access, among others. They differ in the details, but the shape is similar, and it changes several things at once:
- No open inbound port. Instead of your firewall listening for connections from the internet, a small piece of software inside your office makes an outbound connection to the provider, and remote users connect to the provider too. The two are stitched together in the middle. There is no public doorway for attackers to scan and hammer, because you never opened one. This alone removes an entire category of risk.
- Identity on every request. Access is tied to a verified identity, usually through the same login system you already use (Google Workspace, Microsoft 365) with multi-factor authentication. Every connection is checked against who you are and what you are allowed to reach, not just once at the door but continuously.
- Least privilege by default. This is the phrase for granting each person only the access their job requires, and no more. Your biller can be given access to the practice-management system and nothing else. A remote clinician gets the EHR. Neither one can “see” the backup server or the front-desk PC, because those were never in their grant. If a biller’s credential is stolen, the blast radius is one application, not the whole office.
- Device posture checks. Many zero-trust tools can refuse a connection unless the device meets a bar you set: disk encryption on, screen lock enabled, operating system updated, security software running. The health of the machine becomes part of the decision, not an afterthought.
The mental model is the difference between giving a contractor a key to your building versus escorting them to the one room they are working in and locking it behind them. The VPN hands over a key to the building. Zero-trust walks each person to their room, checks their badge at the door, and never lets them wander the halls.
A plausible Tuesday: the laptop in the coffee shop¶
A four-person family practice lets its biller work from home three days a week. Years ago their IT guy set up a VPN so she could reach the practice-management system and the EHR from her laptop. It has worked fine, so no one has touched it.
On a Tuesday, her laptop is stolen from a coffee-shop table while she refills her cup. Probably it was grabbed for the hardware. But the person who ends up with it opens the lid, and the machine is not encrypted. Windows was set to remember her, so it logs straight in. The VPN client is installed, and someone saved the credentials so she would not have to type them each time. One click, and the laptop dials into the office network exactly as it always has.
Now the thief is inside the practice’s network. Not looking at one app behind a login screen, but standing on the office LAN with a valid VPN session. From there they can reach the file server with scanned insurance cards, the shared drive of patient documents, the EHR, the backups. Nothing is broken into. No alarm sounds. The VPN did precisely what it was built to do: it put a device on the network and trusted it. The single missing safeguard, an encrypted disk, or a device-health check, or per-application access instead of whole-network access, is the difference between “we lost a laptop” and “we have a reportable breach of patient information.”
Run the same Tuesday with a zero-trust setup. The laptop is still stolen. But the connection requires the biller’s identity and a second factor she carries on her phone, so the saved login alone is not enough. Even if it were, the device-posture check refuses a laptop with no disk encryption. And even if everything failed, the biller’s access was scoped to the practice-management app, so the file server and backups were never reachable from that laptop in the first place. Same theft, dramatically smaller problem. That gap is the entire argument.
The honest trade-offs¶
Zero-trust is not automatically the right answer, and anyone who tells you a VPN is obsolete is selling something. Here is the fair comparison.
Where a VPN still makes sense. It is well understood, and most firewalls already include one, so the marginal cost can be near zero. If a remote user genuinely needs broad access to many systems, a VPN delivers that simply. And for occasional, low-stakes access that does not touch sensitive data, a properly locked-down VPN, patched, with mandatory MFA and ideally some internal segmentation, is a reasonable and defensible choice.
Where zero-trust wins. It removes the open inbound port entirely, erasing a large and permanent attack surface. It enforces least privilege, so a stolen credential or device does not hand over the whole network. It checks device health. And for a small practice it is often easier to run day to day, because the provider handles the hard networking and you manage access through a simple dashboard. The catch: you are introducing a new third-party service into the path to your data, and if that path carries patient information, that vendor relationship carries HIPAA weight (more below). You are also usually paying a per-user monthly fee, though for a handful of users it is modest.
The thing both share. Neither model is a substitute for the basics. Multi-factor authentication, encrypted laptops, prompt patching, and least-privilege access on the systems themselves still matter regardless of which door people come through. Remote access is one control, not a security program.
The HIPAA angle¶
If your remote connection ever carries protected health information, and for a practice reaching an EHR from home it certainly does, then a couple of HIPAA Security Rule concepts come into play. I will keep this careful and plain, because the details matter and I do not want to overstate them.
First, encryption in transit. The Security Rule treats encryption as an addressable implementation specification, a specific legal term that does not mean “optional.” It means you must implement encryption where it is reasonable and appropriate, or document a legitimate reason you did something equally protective instead. For PHI crossing the public internet, encrypting that traffic is squarely the expected, reasonable-and-appropriate choice, and both a properly configured VPN and a zero-trust overlay encrypt the connection. This is one place the two models are on equal footing.
Second, access controls. The Security Rule requires access controls and, as a general principle, that people get the minimum access necessary for their role. This is where the two models diverge sharply. A flat VPN that drops everyone onto the whole network sits awkwardly against a “minimum necessary” expectation, because it grants far more reach than most roles require. A least-privilege, per-application zero-trust setup maps much more naturally onto that principle. Neither is a magic compliance button, but one of them makes the access-control story easier to tell.
Third, and this is the one small practices most often miss: the Business Associate relationship. If you bring in a third party, an IT provider, a managed security firm, or in some cases the remote-access vendor itself, to set up or manage infrastructure that creates, receives, maintains, or transmits PHI on your behalf, that party is very likely a Business Associate under HIPAA, and you generally need a signed Business Associate Agreement (BAA) with them before PHI flows through their hands. The nuance is that not every vendor is automatically a BA, and the “conduit exception” is narrow and frequently misunderstood, so this is genuinely fact-specific. The practical takeaway: if a company is going to manage the pipe your patient data travels through, assume you need a BAA and confirm they will sign one before you commit.
This is general information, not legal advice. HIPAA obligations depend on your specific situation, and you should confirm your own compliance decisions with qualified counsel or a compliance professional.
How to choose: a decision guide¶
You do not need to agonize over this. For most small practices in 2026, the honest recommendation leans toward zero-trust access for anything touching patient data, with a VPN reserved for the narrower cases where it genuinely fits. Here is the short version.
Choose a VPN if:
- You already run one, it is patched, MFA is mandatory on it, and remote access does not touch PHI or other sensitive data.
- A remote user legitimately needs broad access to many systems on the internal network, and you have the ability to segment that network so the VPN is not a flat, go-anywhere connection.
- Cost is the binding constraint and you can commit to the discipline of keeping the internet-facing gateway perfectly patched.
Choose zero-trust access if:
- Remote users reach an EHR, patient documents, or anything else you would have to report if it leaked.
- You want to close the open inbound port and stop worrying about VPN-gateway vulnerabilities.
- Different people need different, limited access, and “everyone gets the whole network” is more than the job requires.
- You want the ability to refuse connections from unencrypted or out-of-date devices.
- You would rather manage access from a simple dashboard than maintain firewall and VPN configuration by hand.
Whichever you choose, do these regardless:
- Require multi-factor authentication on every remote login, no exceptions.
- Encrypt the disk on every device that connects, especially laptops that leave the building.
- Grant the least access each role actually needs, and revoke it the day someone leaves.
- Keep the remote-access software and the devices using it patched and current.
- If PHI is involved and a third party manages any of it, get a signed BAA before data flows.
If you can only do one thing this month, it is this: find out whether “connect from home” at your practice means “log into one application” or “get dropped onto the whole office network.” If it is the second, that is worth fixing before the laptop goes missing, not after.
Where this fits, and where we can help¶
Remote access looks like a technical choice and is really a risk-and-compliance choice wearing technical clothes. The tunnel is the easy part. What matters is who can reach what, whether a stolen device or password stays contained, and whether the arrangement holds up when a patient, a cyber-insurance form, or an auditor asks how the information is protected.
If you would like a hand, this is squarely the kind of thing Breach sets up and manages for small practices: choosing the right model for how your team actually works, standing up zero-trust access or hardening an existing VPN, wiring in MFA and device checks, and, where PHI is in the path, making sure the Business Associate paperwork is in place before anything goes live. Email support@breachsecurity.io with a quick note about how many people work remotely, what they need to reach, and what you use for email and identity, and we will reply with a plain recommendation on which door to use and how to lock it.