The traditional cybersecurity model is built around a perimeter. There is a network boundary — defined by the corporate firewall, the managed switch, the office WiFi router — and everything inside that boundary is considered relatively trusted while everything outside is considered relatively untrusted. Security controls are concentrated at the boundary, and the resources inside it are protected by virtue of being inside it. This model works reasonably well for organisations where staff work from a fixed location on a managed network. It is fundamentally incompatible with home health care delivery.
A field nurse who visits eight patients in a day operates outside the perimeter for her entire clinical shift. Every EHR access event, every secure message to the clinical supervisor, every care plan update, and every OASIS submission she completes happens on a network the agency did not choose, cannot configure, and cannot monitor. The patient home WiFi router she connects to at 9am was installed by a cable company technician three years ago and has never received a firmware update. The one she connects to at 11am is shared across a twelve-unit apartment building. The one at 1pm is a router she noticed on her device's available networks list and connected to because it had "HOME" in the name and she assumed it was the right one.
Perimeter security has no answer to this environment. Zero-trust security was specifically designed for it. The core principle of zero-trust — "never trust, always verify" — means that access to clinical systems is not granted based on network location. It is granted based on verified identity, verified device health, and verified context for every session, regardless of what network the device is connected to. A field nurse on a compromised patient home WiFi router with a zero-trust architecture in place has the same access security posture as a clinical supervisor on the managed office network — because the security is in the identity and the device, not the network.
The Specific Threats That Patient Home WiFi Creates for Home Health ePHI
Threat 1: Man-in-the-Middle Attacks on Unencrypted or Weakly Encrypted Networks
A man-in-the-middle attack occurs when an attacker positions themselves between a device and the network it is communicating with, intercepting and potentially modifying the data in transit. Patient home WiFi networks are susceptible to this attack because they frequently run on outdated routers with weak encryption (WPA2 with known vulnerabilities or, in older installations, WPA or WEP which are trivially crackable), use factory default or easily guessable passwords that a knowledgeable attacker in the vicinity can obtain, and have no monitoring capability that would detect an unauthorised connection or a traffic interception event.
The practical question for home health administrators is not whether man-in-the-middle attacks are technically possible on patient home WiFi — they are. The question is what data is at risk if one occurs. A field nurse who accesses the EHR on a compromised network and whose traffic is being intercepted is potentially exposing patient records, care plan data, medication orders, and clinical notes to the attacker in real time. TLS encryption on the EHR connection protects the data in transit from the device to the EHR server — which is why confirming TLS 1.2 or higher is in use for all EHR connections is a baseline requirement, not optional. But TLS does not protect against an attacker who has compromised the device itself through the malicious network.
Threat 2: Rogue Access Points and WiFi Spoofing
A rogue access point attack involves an attacker setting up a WiFi network with a name (SSID) that a device has previously connected to, causing the device to connect automatically when it comes within range. A field nurse whose device has previously connected to a network named "NETGEAR" or "XFINITY" or any common default router name will automatically connect to any network broadcasting that SSID — including one that an attacker has set up in a vehicle parked outside the patient's home specifically to intercept that nurse's device traffic.
This attack is particularly effective against home health field staff because the diversity of networks they connect to across a working week means their devices accumulate a large list of remembered network names — many of them common default router names that are trivially spoofable. MDM policies that restrict automatic WiFi connection to approved networks, combined with cellular data as the preferred clinical access pathway, significantly reduce this attack surface.
Threat 3: Shared Network Lateral Movement
When a field nurse's device connects to a patient's home WiFi network, it joins a network that may also include smart home devices, personal computers, gaming consoles, and other devices with varying security postures. A smart device on the same network that has been compromised — through an unpatched firmware vulnerability, a default credential exposure, or a supply chain compromise — provides a potential lateral movement pathway to the nurse's clinical device if that device is not running behavioral EDR that detects and blocks unexpected inbound connection attempts.
This is not a theoretical edge case. IoT device compromise in residential environments has increased significantly since 2023, and home health nurses regularly connect to WiFi networks shared with compromised smart devices whose owners have no awareness of the compromise. The clinical device must be able to defend itself against threats originating from within the same network it is connected to — which requires endpoint-resident security, not network-level security.
Threat 4: Insecure Consumer Applications for Clinical Communication
When clinical staff cannot easily use approved, secure communication tools, they default to whatever is convenient — personal text messaging, WhatsApp, consumer email, or other applications that are not subject to HIPAA's technical safeguard requirements. The trigger for this shadow IT behaviour is almost always a secure communication tool that is cumbersome to use in the field environment, or a network situation where the approved tool is not functioning reliably.
A field nurse who cannot get the agency's secure messaging platform to connect reliably on a patient's weak WiFi signal will text the clinical supervisor from her personal phone rather than delay a time-sensitive care communication. That text message — which may contain the patient's name, condition status, or medication information — is PHI transmitted through an unencrypted, non-HIPAA-compliant channel. The zero-trust architecture addresses the root cause by ensuring that approved clinical communication tools function reliably across network environments rather than requiring field staff to choose between clinical urgency and security compliance.
What Zero-Trust Actually Means in Home Health Clinical Operations
Zero-trust is a security architecture philosophy, not a single product. In the home health context, implementing zero-trust means applying three verification requirements to every clinical system access event, regardless of network location.
Verification 1: Identity — Who Is This User?
Every access request to a clinical system must be authenticated by a verified identity — username and password plus MFA, every time, from every location. The conditional access policy that enforces this verification treats every authentication request as potentially untrusted, regardless of whether it originates from the office network or a patient's home WiFi. A field nurse who authenticates to the EHR at 9am from a patient's home is challenged for the same MFA factor as a clinical supervisor who authenticates at 9am from the managed office network. Identity is verified, not assumed.