The short answer: what HIPAA requires from your network
If you searched for HIPAA network requirements, here is the short answer before the long one: HIPAA does not name any specific networking technology, product, or protocol, and the phrase network requirements never appears in the regulation. What the law requires is an outcome. Under the general rules of the Security Rule at 45 CFR 164.306(a), every covered entity and business associate must ensure the confidentiality, integrity, and availability of all electronic protected health information it creates, receives, maintains, or transmits, and must protect against reasonably anticipated threats and impermissible uses or disclosures. Your network is where most of that creating, receiving, and transmitting happens, so the network inherits the obligation. In practice, that translates into a specific set of duties: the network must be included in your risk analysis, access to it must be limited to authenticated, authorized users, ePHI moving across it must be protected in transit, activity on it must be recorded and reviewed, and every one of those decisions must be documented. An examiner from the Office for Civil Rights will not ask what router you bought. They will ask for your risk analysis, your network documentation, your encryption decisions, and your activity review records, and organizations that cannot produce them have paid settlements in the millions. This guide walks through each network-facing requirement in the regulation, the enforcement cases that show what failure costs, and the build order that gets a small practice or a large business associate to a defensible network.
The requirements live in the Security Rule, 45 CFR 164.302 through 164.318, which applies to electronic protected health information as defined at 45 CFR 160.103 and binds business associates directly, not just covered entities, so a billing company, a managed service provider, or a software vendor handling ePHI carries these duties in its own name. The rule is deliberately technology neutral. Under 164.306(b), you may use any security measures that reasonably and appropriately implement the standards, taking into account your size, complexity, technical infrastructure, and the cost of measures against the probability and criticality of the risks. That flexibility is why there is no such thing as a HIPAA-certified firewall or a HIPAA-compliant router, whatever a vendor's marketing sheet says. Equipment can support compliance; only an organization, with policies, configuration, and evidence, can be compliant. The rule also splits its implementation specifications into required and addressable under 164.306(d), and addressable is the most misread word in the regulation. It does not mean optional. It means you either implement the specification, or you document in writing why it is not reasonable and appropriate for your environment and what equivalent measure you adopted instead. The network-facing standards you will meet again and again in this guide are transmission security at 164.312(e), access control at 164.312(a), audit controls at 164.312(b), and person or entity authentication at 164.312(d) on the technical side, backed by the administrative machinery of risk analysis, risk management, security incident procedures, and workforce training at 164.308.
Transmission security: encrypting ePHI in motion
Transmission security at 45 CFR 164.312(e)(1) is the standard written most directly for the network. It requires technical security measures to guard against unauthorized access to ePHI being transmitted over an electronic communications network, and it carries two implementation specifications, both addressable: integrity controls at 164.312(e)(2)(i), meaning measures that ensure transmitted ePHI is not improperly modified without detection, and encryption at 164.312(e)(2)(ii), meaning a mechanism to encrypt ePHI whenever deemed appropriate. In 2026, deeming encryption in transit inappropriate is close to indefensible for ordinary traffic. Modern TLS is built into every operating system, browser, and cloud service, its cost is effectively zero, and OCR has repeatedly cited unencrypted transmissions in enforcement actions, so the documented risk assessment that addressable specifications allow will almost always conclude that transport encryption is reasonable and appropriate. There is also a powerful business reason that has nothing to do with penalties. The Breach Notification Rule at 45 CFR 164.402 only obligates you to report breaches of unsecured protected health information, and HHS guidance defines secured as encrypted to recognized standards with the keys protected. If a transmission is intercepted or a device is lost but the ePHI on it was properly encrypted and the key was not compromised, notification duties generally never trigger. Encryption is the only control in the entire rule that comes with that safe harbor, which makes it the single highest-value technical measure a network team can deploy.
Applying transmission security to a real environment means walking every path ePHI travels and asking what protects it there. Traffic between your practice and a clearinghouse or billing service, connections from your EHR to labs, e-prescribing networks, and health information exchanges, and site-to-site links between your own locations should all ride encrypted channels, whether that is TLS on the application connection or an encrypted tunnel between offices. Email deserves special care because ordinary email is not encrypted end to end: messages containing ePHI that leave your domain need an encryption gateway, a secure portal, or a patient's documented choice, since OCR recognizes that individuals may ask to receive their own information by unencrypted email after being warned of the risk, a choice you should record. Standard text messaging has no encryption at all, so ePHI belongs in secure messaging platforms instead. Online fax services that transmit or store your documents are business associates and need agreements in place, a point covered in depth in our copier and fax security guide. Do not stop at the perimeter, either. On a flat internal network, legacy protocols and unencrypted database connections expose ePHI to anyone who gains a foothold inside, which is exactly the scenario modern attacks create. The proposed Security Rule update published in January 2025 would remove the discretion entirely and make encryption of ePHI in transit mandatory with narrow exceptions, and while no final rule has been issued as of July 2026, new network designs should treat encrypted transit as a fixed requirement.
Segmentation, firewalls, and wireless: the architecture HIPAA expects
Nothing in the current Security Rule says the word segmentation, but the requirement is implied by the standards that are there. Risk management at 45 CFR 164.308(a)(1)(ii)(B) requires security measures sufficient to reduce identified risks to a reasonable and appropriate level, and on a flat network the identified risk is stark: one phished workstation, one infected personal device, one compromised vendor login can reach every system that stores ePHI. The access control standard at 164.312(a)(1) points the same direction, since a network where everything can talk to everything makes a mockery of allowing access only to authorized persons and programs. Segmentation is how the network itself enforces least privilege: clinical systems, business machines, guest devices, and building equipment live in separate zones, with firewall rules that deny traffic between zones by default and permit only the flows a documented business purpose requires. The lesson is written in enforcement history. In the Anthem breach, discussed fully below, attackers who compromised user workstations through phishing emails were able to move laterally through the environment until they reached an enterprise data warehouse holding tens of millions of records. Boundary firewalls still matter, but the modern threat model assumes the perimeter will eventually fail, and segmentation determines whether that failure costs you one machine or your entire patient database. The January 2025 proposed rule would make this explicit, requiring a written technology asset inventory and a network map showing how ePHI moves through your systems, and naming network segmentation as an expected control.
Wireless networks carry ePHI the moment a nurse's tablet or a front desk laptop touches the EHR over Wi-Fi, which makes the wireless layer part of your Security Rule scope, not a convenience to secure later. The baseline is current-generation encryption, WPA2 at minimum and WPA3 where your equipment supports it, and for staff access the enterprise mode of either protocol is meaningfully stronger than a shared passphrase, because per-user authentication ties network access to an individual identity the way unique user identification at 45 CFR 164.312(a)(2)(i) already requires for systems. A shared Wi-Fi password written on a whiteboard defeats attribution, survives every departure, and tends to leak to patients and vendors within weeks. Guest Wi-Fi should exist precisely so visitors never touch the clinical network, isolated from internal systems with no route between the zones. Tricks like hiding the network name or filtering hardware addresses are not security controls and should never appear in your documentation as such. The same hygiene extends to the network equipment itself. Routers, switches, access points, and network-attached printers ship with default administrative credentials that are published on the internet, and changing them is part of the risk management duty, as is applying firmware updates. The cost of ignoring patching is on the record: Anchorage Community Mental Health Services paid $150,000 in 2014 after malware compromised ePHI through systems running outdated, unpatched, and unsupported software, one of the earliest OCR settlements to say plainly that failing to update your technology is itself a HIPAA failure.
Remote access, cloud connections, and exposed services
Remote access is now a permanent feature of healthcare operations, from work-from-home billing staff to telehealth clinicians to on-call administrators, and every remote path into systems holding ePHI must satisfy the same standards as a badge through the front door. The access control standard at 45 CFR 164.312(a)(1) and the authentication standard at 164.312(d) require that remote users be individually identified and verified, and the practical bar for verification in 2026 is multi-factor authentication on every remote entry point. MFA is what OCR resolution agreements demand after credential-theft incidents, what cyber insurers require before they will write a policy, and what the proposed Security Rule update would make explicitly mandatory. The mechanism matters less than the coverage: a VPN with MFA, or a zero-trust access broker that authenticates each session, both work, while a remote desktop port exposed directly to the internet is how a large share of healthcare ransomware incidents begin and has no defensible place in a covered environment. Remote work policies should address the home side of the connection too, covering household member access, screen privacy, and the requirement that work happen on managed, encrypted devices rather than family computers. Vendor remote access deserves its own rules: support sessions should be enabled for the engagement, monitored while active, and disabled afterward, never left standing, and any vendor that touches ePHI through that access needs a business associate agreement under 45 CFR 164.308(b) and 164.502(e) before the connection exists.
Cloud services are fully compatible with HIPAA, but they extend your network boundary into someone else's data center and bring their own requirement: a cloud service provider that creates, receives, maintains, or transmits ePHI on your behalf is a business associate, and OCR's cloud computing guidance is explicit that this holds even for no-view services that store only encrypted data without holding the key. The business associate agreement must be signed before ePHI flows, full stop. Oregon Health and Science University learned the price of skipping that step, paying $2.7 million in 2016 in a settlement that included storing the health information of more than 3,000 patients on a consumer cloud storage service with no agreement in place, a shadow-IT pattern that repeats anywhere staff find official tools inconvenient. The agreement also does not configure your services for you. Under the shared responsibility model every major provider uses, the provider secures the infrastructure while you secure your configuration, meaning access rules, storage permissions, and what is reachable from the public internet remain your Security Rule problem. Exposed services are a recurring enforcement theme: Touchstone Medical Imaging paid $3 million in 2019 after a file transfer server allowed uncredentialed anonymous access to the protected health information of more than 300,000 patients, with search engines indexing the files, and OCR's findings emphasized that the exposure continued even after the FBI and OCR notified the company. Scanning your own perimeter for services you did not mean to publish is cheap; being told about them by federal agencies is not.
Network monitoring, audit logs, and the Anthem lesson
The Security Rule assumes some control will eventually fail, which is why it pairs every preventive measure with a duty to watch. The audit controls standard at 45 CFR 164.312(b) requires mechanisms that record and examine activity in information systems containing ePHI, and at the network level that means firewall and VPN logs, intrusion detection alerts, DNS and remote access records, and authentication events, retained long enough to reconstruct an incident. Recording is only half the duty. The information system activity review at 164.308(a)(1)(ii)(D) requires regularly reviewing records of system activity, and OCR reads regularly as a real cadence with a named owner, a written procedure, and evidence that anomalies were investigated, not a log archive that accumulates unread. The signals worth alerting on from network telemetry are consistent: logins from impossible locations or at impossible hours, remote access by accounts that should not have it, traffic from clinical segments to unfamiliar destinations, and any activity from credentials belonging to departed staff. When a review surfaces something real, the security incident procedures standard at 164.308(a)(6) requires documented processes to identify, respond to, mitigate, and record the outcome of security incidents, which is also where your breach assessment under 45 CFR 164.402 begins if ePHI was involved. Keep all of it, the procedures, the reviews, and the incident records, under the documentation standard at 164.316, which imposes a six-year retention period, a topic our audit log retention guide covers in detail. In an investigation, the review you cannot produce is treated as a review that never happened.
Every requirement in this guide converges in the Anthem case, still the largest HIPAA settlement on record. In October 2018, Anthem, one of the nation's largest health benefits companies, paid the Office for Civil Rights $16 million and entered a corrective action plan after a breach affecting 78.8 million individuals, and it separately agreed to a $115 million class action settlement over the same incident. The attack began with spear-phishing emails to a subsidiary's employees; at least one user opened one, and the attackers established a foothold in early 2014 that went undetected until January 2015. From that initial compromise they moved through the network to an enterprise data warehouse and extracted names, Social Security numbers, medical identification numbers, addresses, dates of birth, and employment information. OCR's findings track the network duties in this guide almost line by line: Anthem had failed to conduct an enterprise-wide risk analysis, had insufficient procedures to regularly review information system activity, failed to identify and respond to suspected or known security incidents, and failed to implement adequate minimum access controls to prevent attackers from accessing ePHI. Notice what the findings are not. OCR did not fault a firewall model or a missing product. It faulted the absence of the program: nobody had mapped the whole environment's risk, nobody was reviewing the activity records that would have shown a year of intrusion, and nothing limited how far a compromised workstation could reach. A phishing email will eventually land in any organization; the network requirements exist so that when it does, the blast radius is a contained segment and a same-week detection, not eleven months and the largest health data breach in history.
Building a HIPAA-compliant network you can prove
Building toward these requirements is a sequencing exercise, and the sequence starts where OCR always starts: the risk analysis required by 45 CFR 164.308(a)(1)(ii)(A). Inventory every network segment, device, connection, and cloud service that touches ePHI, diagram how the data flows, and rate the risks; you cannot secure, segment, or monitor what you have not mapped, and an analysis that skips the network is the enterprise-wide failure the Anthem findings describe. Remediate in risk order under 164.308(a)(1)(ii)(B), which usually means encryption in transit and MFA on remote access first, then segmentation of the highest-value systems, then monitoring coverage, rather than polishing low-risk items because they are easy. Document every decision under 164.316, including the written rationale for any addressable specification you met with an alternative measure, and re-run the evaluation required by 164.308(a)(8) whenever the environment changes, a new location, a new EHR, a move to the cloud. Build to where the rule is going, not just where it is: the January 2025 proposed update would require the asset inventory and network map outright, mandate encryption and multi-factor authentication, name segmentation as an expected control, and add recurring vulnerability scanning and annual penetration testing, and although no final rule has been issued as of July 2026, a network designed to those specifications today needs no retrofit tomorrow. If you want a structured starting point, our free HIPAA risk assessment tool walks the Security Rule standard by standard and produces a scored gap list you can hand to whoever manages your network.
The last network requirement has nothing to do with equipment. The Anthem attackers did not break the perimeter with an exploit; an employee opened an email, which is why the Security Rule makes security awareness and training at 45 CFR 164.308(a)(5) a standard for the entire workforce, explicitly including protection from malicious software, log-in monitoring, and password management, and why the Privacy Rule adds its own training duty at 164.530(b) covering the policies each role works under. Training is the control that patches the layer no firewall reaches. It belongs on the same footing as your technical work: everyone who touches systems that carry ePHI, from the front desk to the network engineer to the managed service provider's technicians, needs current, documented HIPAA training, and the IT staff who hold the most network privilege need it most. Remember that an MSP running your network is a business associate with training duties of its own, and asking for proof of its workforce training is a fair diligence question before you hand over the keys. USA HIPAA's online certification covers the Privacy Rule, the Security Rule safeguards this guide is built on, and breach response in about two hours per person, and it produces dated, verifiable certificates that satisfy the documentation side of the training requirement, so an auditor asking whether your workforce was trained gets an answer on paper instead of a shrug. Start with the free practice test if you want to gauge where your team stands. A well-built network keeps attackers out of your ePHI; a well-trained workforce keeps them out of your network.