Remote access to the EMR used to be an exception granted to a few physicians. Now it is the norm: on-call providers review results from home, telehealth visits are conducted from a spare bedroom, billing staff work remotely, and locum clinicians connect from wherever they are. Each of those connections is an entry point to the system that holds every patient's record, and the credentials behind them are the most common target in healthcare intrusions. This article lays out a practical architecture for securing EMR remote access, from the VPN most practices already have to the conditional access and device checks that close the gaps a VPN leaves open.
The remote access paths you probably have
Start by enumerating how the EMR can be reached from outside the building. Common paths include a VPN into the office network followed by a remote desktop session, a published remote desktop or application gateway, a browser-based cloud EMR reachable from anywhere, a vendor-provided mobile app, and vendor support access through a separate remote-support tool. Many practices discover during this exercise that a legacy path (an old remote desktop port, a retired VPN profile still on a former employee's laptop) is still open. Close what you do not use before hardening what you do.
For each remaining path, record what authenticates it, whether multi-factor authentication is enforced, what device is required, and what is logged. That table becomes the baseline for everything below.
VPN: still useful, no longer sufficient
A VPN encrypts traffic between a remote device and the office network and, in the traditional model, places the device on the internal network as if it were in the building. That is its weakness: once connected, the device can reach everything the network allows, and a compromised laptop becomes an insider. VPN concentrators have also been a frequent target of exploitation when left unpatched.
If you keep a VPN, apply these minimums: enforce multi-factor authentication on the VPN itself, not just on the EMR behind it; restrict what a VPN client can reach to the EMR servers and the services it needs (split the network rather than granting full access); keep the concentrator firmware current on a defined schedule; disable split tunneling for clinical devices so traffic is inspected; and review VPN logs for logins from unexpected countries or at unusual hours as part of your information system activity review.
Zero-trust access in plain terms
Zero trust is a set of design principles, not a product. The core idea, described in NIST's guidance on zero trust architecture, is that no user or device is trusted because of where it is on the network. Every request to a resource is authenticated, authorized, and evaluated against policy, and access is granted to the specific application rather than to the network.
For EMR remote access, that translates into a few concrete changes. Users connect to the EMR application through an identity-aware gateway or the cloud EMR's own front door, not to a network. The gateway checks who the user is, what device they are on, and whether the request fits policy before it forwards anything. Access is granted per application, so a compromised account that can reach the EMR cannot also browse the file server. And the checks continue during the session rather than only at login.
Practical translation: replace the VPN-then-remote-desktop chain with an identity-aware application gateway (or the cloud EMR's native access with conditional policies), keep a tightly scoped VPN only for administrators, and treat every device as untrusted until it proves otherwise.
Conditional access policies that matter
Conditional access is the mechanism in modern identity platforms that lets you say who may access what, from where, on which devices, and under what conditions. A small set of policies covers most of the EMR risk:
- Require phishing-resistant or at least app-based MFA for all remote EMR access; block SMS-only methods where the platform allows it.
- Block or step up access from countries where you have no users, and alert on impossible-travel patterns.
- Require a managed or compliant device for full EMR access; allow limited, browser-only access with no download or print from unmanaged devices, or block them entirely.
- Block legacy authentication protocols that bypass MFA.
- Apply stricter rules to privileged roles such as EMR administrators, interface engineers, and vendor support accounts: managed device required, shorter sessions, and re-authentication for sensitive actions.
- Set sign-in frequency and session lifetime so a stolen session token expires quickly.
Test each policy in report-only mode first. Conditional access is the fastest way to lock out an on-call physician at 2 a.m., and the exceptions you did not anticipate (a locum on a personal tablet, a provider traveling abroad) will show up in the report-only logs before they become an emergency.
Device posture and BYOD
The device is half of the security decision. A managed laptop with full-disk encryption, current patches, endpoint protection, and a screen lock is a reasonable place to open a patient record. A personal computer shared with family members is not, no matter how strong the password. Device posture checks let the access gateway verify encryption, patch level, and endpoint protection before granting a session.
For clinicians who insist on personal devices, the workable middle ground is a virtual desktop or browser-isolated session where the record is displayed but never stored on the device, with copy, download, and print disabled. Mobile EMR apps should require device enrollment in a mobile device management tool that can enforce a passcode, encryption, and remote wipe of the app container. Document the acceptable-use rules for personal devices and have users acknowledge them.
Session controls and monitoring
Remote sessions need the same automatic logoff the Security Rule expects on in-office workstations, and arguably shorter timeouts, because the environment is uncontrolled. Set idle timeouts at the gateway and in the EMR, require re-authentication after a fixed session length, and make sure a closed laptop lid ends the session rather than suspending it indefinitely.
Log remote sessions distinctly from on-site access so reviews can focus on them. Useful signals include logins from new devices, first-time logins from a new location, sessions that overlap from two locations, and high-volume record access during a remote session. Feed these into the same activity review routine you use for the rest of the EMR.
A rollout order that does not break on-call
- Inventory and close unused access paths.
- Enforce MFA everywhere remote access is possible, including the VPN and vendor support tools.
- Deploy conditional access in report-only mode for two to four weeks; review what would have been blocked.
- Enroll clinician devices in management and turn on posture checks.
- Move EMR access behind an identity-aware gateway or native cloud access; narrow the VPN to administrators.
- Enable the policies in enforce mode, one at a time, starting with the least disruptive.
- Publish a one-page guide for clinicians and a documented break-glass path for the help desk when a legitimate user is blocked.
- Record the design and the decisions in the risk analysis and revisit them annually.
None of this is exotic. The identity platforms bundled with common productivity suites include conditional access and device compliance features, and most cloud EMR vendors support single sign-on that lets those policies apply. The work is in the configuration and the testing, not in buying something new.
Common questions
Is a VPN required by HIPAA for remote EMR access?
No. The Security Rule requires transmission security and access controls but does not mandate a specific technology. A VPN is one way to meet those requirements; an identity-aware gateway with encrypted application access and MFA is another, and often a stronger one.
Can clinicians use personal laptops to access the EMR?
They can if the practice decides the risk is acceptable and puts controls in place: at minimum MFA, a browser-isolated or virtual desktop session that stores nothing locally, and a signed acceptable-use agreement. Many practices instead require a managed device for full access.
What is conditional access?
A capability in modern identity platforms that evaluates each sign-in against policies about the user, device, location, and risk signals, and then allows, blocks, or requires additional verification. It is the practical tool for implementing zero-trust principles for EMR access.
How do we avoid locking out on-call providers?
Run new policies in report-only mode first, review what they would have blocked, communicate changes before enforcing them, and maintain a documented help-desk break-glass procedure that can grant temporary access after identity verification.