Walk into most independent practices and you will find a workstation attached to a digital X-ray panel that has not been rebooted since the vendor installed it. Nobody knows the password. It runs an operating system that stopped receiving security updates years ago. It is on the same network as the front desk, the EHR server and the guest Wi-Fi.
That machine is a computer. It has an IP address, a file share and, very likely, a remote support tool. Attackers do not care that it is labeled "imaging." They see an unpatched Windows host with a path to everything else.
This article covers what actually counts as a medical device endpoint in a small practice, why these devices are riskier than your laptops, and the specific steps a practice can take without buying an enterprise medical device security platform it cannot afford.
What counts as a device endpoint in a small practice
The list is longer than most administrators expect. If it has a network cable or Wi-Fi radio and it touches patient care, patient data or physical security, it belongs on the list.
- Ultrasound systems, including portable carts, which are almost always Windows-based
- Digital X-ray and CBCT workstations and acquisition PCs in dental, orthopedic, pain and podiatry offices
- Dermatology imaging systems, dermoscopy cameras and total body photography stations
- EKG carts and stress testing systems that upload to the EHR
- Lab analyzers and LIS interfaces, including the middleware PC that translates analyzer output into HL7
- Infusion pumps and monitors in ambulatory surgery centers
- Dental intraoral sensors and the acquisition software on operatory PCs
- IP cameras, DVR/NVR recorders and badge access systems
- Smart TVs, digital signage and tablets in waiting rooms and exam rooms
- Networked printers and multifunction copiers that scan to email or store documents on internal drives
Most of these are not called "computers" in the practice, so nobody manages them like computers. That is the core problem.
Why these devices are riskier than your laptops
Vendor-certified but unsupported operating systems
Imaging and lab vendors validate their software against a specific operating system build. When that OS reaches end of life, the vendor often keeps certifying it because revalidation is expensive. The result is a machine on your network that receives no security patches and that the vendor tells you not to upgrade.
Default credentials
Service accounts, local admin passwords and web management logins on devices frequently ship with defaults that appear in vendor manuals available online. Nobody changes them because nobody thinks of the ultrasound cart as a login target.
Flat networks
In a typical small office, everything sits on one subnet. Front desk PC, EHR server, X-ray workstation, security cameras and the receptionist's phone can all reach each other. Ransomware that lands on one host has an open road to the rest.
Remote vendor access
Most device vendors install a remote support tool for troubleshooting. Some are always on. Some use shared credentials across every customer. Some route through a vendor cloud that your practice never evaluated. That is a persistent inbound path into your network that you did not design.
No EDR allowed
You cannot put an endpoint detection agent on many of these devices. Either the vendor forbids it under the support contract, or the OS is too old to run it. So the tool you rely on for your other workstations does not cover the riskiest machines you own. If you are not sure what that tool does, see our piece on EDR on your workstations.
What a practice can actually do
None of this requires an enterprise budget. It requires an inventory, a decent firewall, a managed switch and someone who owns the list.
1. Inventory every device
Walk the office. Record make, model, serial number, operating system and version, IP address, what it connects to, whether it stores PHI, who the vendor is and how the vendor gets remote access. This inventory feeds your HIPAA security risk assessment and it is the first thing an incident responder or insurer will ask for.
2. Segment the network with VLANs
Put clinical devices on their own VLAN. Put IP cameras and building systems on another. Put guest Wi-Fi on a third. Keep general workstations and servers on their own. A single managed switch and a business-class firewall support this. Once segmented, a compromised camera cannot reach the EHR server, and an infected front-desk PC cannot reach the imaging workstation.
3. Write firewall rules between zones
Segmentation only helps if the rules are restrictive. The imaging VLAN needs to reach the PACS or EHR on specific ports. It does not need to reach the internet at large, the guest network or the accounting PC. Default deny between zones, then allow only what the workflow requires and document each rule.
4. Disable unnecessary services
Turn off file sharing, remote desktop, unused web management interfaces and USB autorun where the vendor allows it. Every open service is a door.
5. Change default passwords
Every device, every service account, every web login. Store the new credentials in the practice password manager, not in a drawer or on a label under the cart.
6. Control vendor remote access
Ask each vendor how their remote tool works. Prefer access that is off by default and turned on per session by your staff. Require MFA on the vendor side. Log sessions. Restrict the vendor's tool to reaching only the device it supports, using firewall rules. Put the arrangement in writing.
7. Patch what the vendor certifies
Ask each vendor for their approved patch list and apply it on a schedule. Many vendors will certify newer OS versions if you ask. Some will sell an upgrade kit. Ask, and document the answer either way.
8. Compensating controls and documentation when you cannot patch
When a device cannot be updated, the Security Rule does not give you a pass. It expects you to reduce the risk another way and write it down: isolation on its own VLAN, strict firewall rules, no internet access, no email or browsing on the device, physical access limits, monitoring of network traffic to and from it, and a plan for replacement. Documented compensating controls are what separate "we knew and managed it" from "we ignored it" in an OCR investigation or an insurance claim.
9. Include devices in your risk analysis
Every device on the inventory should appear in your risk analysis with a threat, a likelihood, an impact and a control. If your last risk analysis only listed workstations and the server, it is incomplete.
10. Get BAAs with device vendors that access PHI
If a vendor stores images in their cloud, pulls logs that include patient identifiers, or connects remotely to a device holding PHI, you almost certainly need a business associate agreement. Review the vendor list against the device inventory and close the gaps. Whether a specific vendor qualifies is a legal question, so confirm with counsel.
A segmentation layout that works for a small practice
Picture the firewall at the center with five arms coming off it.
Arm one: Clinical devices. Ultrasound, X-ray workstation, EKG cart, lab analyzer PC. This zone can reach the EHR and PACS servers on defined ports and nothing else. No internet except for vendor patch sources you have whitelisted. Vendor remote access enters through the firewall to this zone only, when staff enable it.
Arm two: Servers and core systems. EHR or the connector to your cloud EHR, file server, domain controller, PACS. Reachable from staff workstations and clinical devices on specific ports.
Arm three: Staff workstations. Front desk, clinical PCs, admin laptops. Full EDR, patched, managed. Can reach servers and the internet through content filtering. Cannot reach the clinical device zone directly except through the applications that need to.
Arm four: Building and IoT. IP cameras, NVR, badge readers, smart TVs, thermostats. Internet only as required by each system, no path to any other zone.
Arm five: Guest Wi-Fi. Internet only. No path to anything internal.
That is five VLANs and a rule set you can print on one page. It is well within reach of a practice with three providers.
How insurers and OCR view this
Cyber insurance questionnaires have started asking directly about network segmentation, end-of-life systems and third-party remote access. Answering "no" or "unknown" is increasingly a coverage or pricing problem. Answering "yes" without being able to prove it is a claim-denial problem. The device inventory and the firewall rules are your proof.
On the regulatory side, HHS OCR has consistently treated an incomplete risk analysis as a foundational failure in enforcement actions. A risk analysis that omits networked medical devices is incomplete. Enforcement data over the past several years shows that OCR looks for whether the practice identified the risk and did something reasonable about it, not whether the practice achieved perfect patching. Documented compensating controls matter here.
Checklist
| Item | Done |
|---|---|
| Written inventory of every networked device, including OS version and vendor access method | |
| Clinical devices on their own VLAN | |
| Cameras, badge systems and smart TVs on a separate IoT VLAN | |
| Guest Wi-Fi isolated from everything internal | |
| Firewall rules default deny between zones, documented | |
| Default passwords changed on every device and stored in a password manager | |
| Unused services disabled (RDP, SMB, web admin, USB autorun) | |
| Vendor remote access off by default, MFA required, sessions logged | |
| Vendor-certified patches applied on a schedule, with the vendor's answer documented | |
| Compensating controls documented for every device that cannot be patched | |
| Every device listed in the current risk analysis | |
| BAA in place with each vendor that touches PHI | |
| Replacement plan and budget line for end-of-life devices |
Print it, walk the office with it, and date it. That dated checklist is a compliance artifact.
Frequently asked questions
Anything with a network connection or a computer inside it that touches patient care or PHI: ultrasound and X-ray workstations, CBCT scanners, dermatology imaging systems, EKG carts, lab analyzers, infusion pumps, dental sensors, plus IP cameras, badge readers, smart TVs and tablets in exam rooms.
Many device vendors certify a specific software image and forbid third-party agents, or the hardware runs an operating system the agent no longer supports. Installing it can void support or break the device. The answer is usually compensating controls around the device rather than software on it.
The HIPAA Security Rule requires you to identify and address risks to electronic PHI wherever it lives, and OCR guidance and enforcement have made clear that networked devices are in scope. If a device stores or transmits PHI, it belongs in your risk analysis and your inventory.
Segmentation means placing devices on separate network zones (VLANs) with firewall rules controlling what can talk to what. A single managed switch and a business-class firewall are enough for most small practices. It is the single most effective control for devices you cannot patch.
If the vendor can access, store or transmit PHI on your behalf, including through remote support sessions or cloud image storage, they are likely a business associate and a BAA is required. If they only ship hardware and never see PHI, probably not. Confirm the specifics with counsel.
Device inventory, VLAN design and vendor access controls are standard parts of our managed cybersecurity service for practices, and the inventory feeds directly into the IT risk assessment we run for new clients. If your imaging or lab vendor has told you the machine cannot be touched, we have almost certainly worked around that vendor before.
Ready for a straight answer about your IT? Call (972) 776-6366 or contact us.