Building a Secure Remote Work Stack: Beyond VPN and Hope | The Digital Strategikon

Remote Work Is Not Going Away

When remote and hybrid work arrangements scaled rapidly in 2020, most healthcare practices improvised their approach: set up a VPN, tell staff to use it, and hope for the best. Several years later, many practices are still running those improvised architectures. Staff have adapted to them — sometimes by working around them when the VPN is slow or causes problems with the clinical systems they need to access.

Working around security controls is the part that should concern practice administrators.

Remote work in healthcare presents specific challenges that don’t apply in the same way to other industries. Clinical staff accessing patient records from home, billing staff processing insurance claims from a home office, and practice managers reviewing financial data over a residential internet connection — all of these involve ePHI flowing outside the physical perimeter of the clinic. HIPAA doesn’t stop at the front door. The Security Rule’s requirements for access controls, transmission security, and audit logging apply regardless of where the access occurs.

Building a remote work stack that is actually secure — not just technically compliant on paper — requires thinking through the full stack: identity, devices, network access, applications, and monitoring. This article walks through each layer.

Start With Identity: Multi-Factor Authentication Is Non-Negotiable

Every component of a secure remote work architecture depends on being able to trust that the person accessing a system is who they claim to be. Passwords alone do not provide this assurance. Passwords are stolen in phishing attacks, reused across accounts, guessed through credential stuffing, or purchased on dark web marketplaces from prior breaches. The frequency with which attackers gain initial access to healthcare organizations through compromised credentials is well-documented.

Multi-factor authentication (MFA) — requiring a second verification factor beyond the password — dramatically raises the cost of credential-based attacks. An attacker who has obtained a valid username and password but cannot satisfy the MFA requirement cannot complete the login.

For healthcare remote work, MFA should be required for:

VPN or remote access gateway login
Email access from outside the office network
EHR and practice management system access (where the application supports it)
Any administrative portal — cloud management consoles, backup administration, network management
Single Sign-On (SSO) platforms if in use

The method of the second factor matters. SMS-based MFA (a code texted to a phone) is better than no MFA but is vulnerable to SIM-swapping attacks. Authenticator app-based TOTP (Time-based One-Time Password) is more secure. Hardware security keys provide the strongest phishing resistance available. For most small healthcare practices, an authenticator app is the right balance of security and usability.

“Compromised credentials are the most common initial access vector in healthcare cyberattacks. MFA doesn’t solve every problem, but it closes the gap that stolen passwords create — and that gap is wide.”

Device Trust: Know What’s Connecting

A VPN that accepts connections from any device — including a staff member’s personal computer running outdated software with no EDR, shared with family members — is not providing meaningful security. The network connection may be encrypted, but the endpoint itself is an uncontrolled risk.

A Zero Trust approach to device access changes the question from “is this the right user?” to “is this the right user on a trusted device in an acceptable context?” Device trust enforcement means that remote access requires not just valid credentials and MFA, but a device that meets defined security standards.

Managed Devices

The cleanest implementation of device trust is limiting remote access to practice-managed devices. A managed device has:

EDR installed and reporting to the practice’s security platform
Current patches applied (enforced, not optional)
Full-disk encryption enabled
A documented user (not shared or personal)
Configured access controls that prevent unauthorized users from logging into the device

For staff who work remotely regularly, providing a practice-managed device for that purpose is the most defensible approach. The cost is modest relative to the compliance exposure of unmanaged personal devices accessing ePHI.

Device Health Checks

Modern remote access platforms support conditional access policies that check device health at the time of connection: Is the device compliant with MDM policies? Is the EDR agent running? Has the device been recently patched? If the device fails the health check, access is blocked until the condition is remediated. This automates enforcement of device standards that would otherwise depend on staff self-reporting.

Network Access: Beyond the Traditional VPN

Traditional VPN architecture is a blunt instrument: once a device connects to the VPN, it typically has access to everything on the internal network, because the VPN grants network-layer access. This is a significant problem if a connected device is compromised — the attacker has the same broad network access that the legitimate user does.

Zero Trust Network Access (ZTNA)

Zero Trust Network Access replaces broad network access with application-level access. Rather than putting a device on the internal network, ZTNA grants access to specific applications and services based on user identity, device trust posture, and defined policy. A billing staff member working remotely can access the practice management system and email — and nothing else. The internal network is never exposed.

ZTNA implementations are available at price points appropriate for small and mid-sized practices, and they eliminate the “once inside, inside everywhere” risk of traditional VPN.

Split Tunneling: A Risk to Understand

Many VPN configurations use split tunneling — only routing traffic destined for internal resources through the VPN, while allowing internet-bound traffic to go directly through the user’s local internet connection. This improves VPN performance (less traffic to route through the tunnel) but means that internet activity on the remote device is not subject to the same filtering and monitoring as office traffic.

If split tunneling is in use, DNS filtering should be deployed at the device level so that malicious domains are blocked regardless of whether traffic goes through the VPN. Endpoint-level DNS filtering is lightweight to deploy and provides meaningful protection against malware callbacks and phishing redirects for remote workers.

Securing the Applications Themselves

Remote access architecture is only part of the picture. The applications that remote workers access need to be secured appropriately as well.

Session Timeouts and Automatic Lockout

EHR systems and other clinical applications accessed remotely should be configured to time out after periods of inactivity, requiring re-authentication. A staff member who opens an EHR session, walks away from a home office computer, and leaves the session running for hours is creating unnecessary exposure.

Audit Logging

HIPAA’s Security Rule requires covered entities to implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Remote access activity should be captured in these logs: who connected, when, from what IP address, to what systems, and what actions were taken.

Logs that exist but are never reviewed provide compliance documentation without security value. Alert rules that flag unusual access patterns — a user connecting at an unusual time, accessing an unusually large number of records, or connecting from an unexpected geographic location — turn logs into actionable intelligence.

Cloud Application Access Controls

If the practice uses cloud-based applications — a cloud EHR, cloud-based communication tools, a cloud practice management system — those applications have their own access controls independent of the VPN or ZTNA. Conditional access policies in cloud identity platforms can enforce MFA, limit access to approved devices, and block access from geographic locations inconsistent with normal usage. These controls are often underutilized.

Handling the Human Side of Remote Work Security

Secure technology architecture is necessary but not sufficient. Staff working from home face a different threat environment than staff in the office:

Home network security varies enormously. A home router that hasn’t been updated in four years, shared with IoT devices and personal computers, is a less controlled environment than a managed office network.
Physical security is harder to guarantee. A clinical discussion on a video call that can be overheard by a household member is a potential HIPAA exposure.
Social engineering pressure may actually be higher for remote workers, who have fewer opportunities to quickly verify an unusual request with a colleague in the next room.

Remote work policies should address these realities: requirements around physical privacy for calls involving PHI, acceptable home network configurations (or VPN requirements that compensate for them), and guidance on handling unusual requests that can’t be immediately verified in person.

Putting It Together: A Practical Checklist

A well-engineered remote work stack for a healthcare practice includes:

MFA required on all remote access pathways and cloud applications
Managed devices with EDR, current patches, and full-disk encryption for staff with regular remote access
ZTNA or VPN with network segmentation limiting access to required applications only
Device health checks enforced at connection time
DNS filtering at the endpoint for internet-bound traffic
Session timeouts on clinical applications
Audit logging for remote access sessions with alert rules for anomalies
Documented remote work policy covering physical privacy, home network standards, and incident reporting
BAAs in place for all cloud platforms handling ePHI

The Byzantine Takeaway

Remote work is a permanent feature of healthcare operations, not a pandemic-era exception. The improvised approach — a VPN and hope — was understandable as an emergency measure. As a sustained architecture, it is inadequate. Building a real remote work security stack means addressing identity, device trust, network access, application controls, and the human elements together. Each layer reinforces the others. None of them alone is sufficient.

Start with MFA if it isn’t already deployed everywhere. It is the highest-impact single control for remote work security and the one that addresses the most common initial access vector. Build from there.