Medical device cybersecurity sounds like a hospital problem, something for operating rooms and intensive care units. In reality, it is just as much a small practice problem, because the quiet devices in the exam rooms are now computers too, and most of them have never been reviewed by anyone in IT.
A medical assistant rolls the vitals station into exam room three and plugs it into the wall.
The cart holds a blood pressure cuff, a pulse oximeter, a thermometer, and a small screen. When she presses a button, the readings travel across the practice’s network and appear in the patient’s chart a few seconds later.
It is efficient. It saves her two minutes per patient, thirty times a day.
Nobody in the practice remembers who installed it. A vendor technician set up the connection three years ago, entered a password, and left a business card. The cart has not been updated since. It runs a version of an operating system that its manufacturer stopped supporting before the cart was even delivered, and it shares the same network as the front desk computers, the EHR server, and the guest Wi-Fi.
Nothing is wrong. Nothing has ever gone wrong.
That is exactly why nobody has looked.
Connected Devices Are Computers With a Medical Job
The category of connected medical equipment is broader than most practices realize.
Vitals stations and blood pressure monitors. Pulse oximeters and electrocardiogram machines. Spirometers and glucose meters that dock to a computer. Ultrasound machines and imaging equipment. Laboratory analyzers. Smart scales. Infusion pumps in practices that offer infusion services. Remote monitoring kits that patients take home and that report back over the internet.
Industry shorthand calls this the Internet of Medical Things. The label matters less than the underlying fact: almost every one of these devices runs software, connects to a network, stores or transmits patient information, and can in principle be misused.
They are also unlike a laptop in important ways. A laptop gets patched on a schedule. A medical device often does not, because the manufacturer controls the software, and updating it may require a service visit, a recertification, or simply does not happen at all. A laptop is replaced every few years. A medical device may stay in service for ten or fifteen years, long after the software inside it has stopped receiving security fixes.
Who Is Actually Responsible for Securing These Devices?
This is the question most practices have never had answered, and the honest answer has two parts.
Device manufacturers carry responsibility for designing security into their products. The FDA regulates medical devices, and in recent years it has strengthened its expectations for manufacturers. Its cybersecurity guidance addresses how devices are designed, documented, and supported across their lifecycle, and manufacturers of devices with network connectivity are expected to provide information such as a software bill of materials and a plan for monitoring and patching vulnerabilities.
That guidance, however, governs manufacturers. It does not tell a physician practice how to configure its own network. It does not mean an older device already sitting in an exam room has been brought up to current standards.
The practice carries the rest. Under the HIPAA Security Rule, a practice is responsible for protecting electronic protected health information wherever it lives, including on devices in its own exam rooms and on the network those devices use. That duty is not delegated to the device vendor by default. It stays with the practice.
In short, the manufacturer builds the device. The practice owns the risk of using it.
What Actually Goes Wrong With Connected Devices
The most common weaknesses are not exotic. They are ordinary, and they repeat across practices of every size.
Default or shared passwords. Devices often ship with a factory password that is documented publicly, and installers sometimes leave it unchanged because changing it would complicate service visits.
Unsupported or unpatchable software. Embedded operating systems that reached end of life years ago keep running because the device still works and replacing it is expensive.
A flat network. The device sits on the same network as everything else, so a compromise of the device can become a way into the EHR, the file server, and the rest of the practice.
Always-on vendor remote access. Many manufacturers and service providers maintain a permanent remote connection to support the equipment. That access is valuable, and it is also a door that has to be controlled, monitored, and closed when it is not needed.
Unencrypted data in motion. Some devices send readings and images using older protocols that do not encrypt what they carry, which exposes patient information to anyone able to observe the network.
No inventory. Few practices can produce a list of every connected device, who owns it, what software it runs, and when support ends. A device that is not on a list is a device nobody is protecting.
None of these require a skilled attacker to exploit. Many of them can be found by automated tools that scan networks continuously.
Why Patient Safety Is Part of the Conversation
When a laptop is compromised, the usual consequence is a data incident. When a clinical device is compromised or simply knocked offline, the consequence can touch patient care.
A device that cannot report readings delays a diagnosis. A monitor that fails during a ransomware event forces staff back to manual processes. An imaging system that is locked cannot produce studies a physician is waiting on. Even in a small practice, a loss of connected devices can slow or halt the visit.
This is one reason regulators and industry groups increasingly describe medical device security as a safety issue, not only a privacy one. The device exists to help care happen. Anything that interrupts it is a clinical concern as well as a technical one.
Segmentation, in Plain English
The single most useful concept for a practice to understand is network segmentation, and it is simpler than it sounds.
Segmentation means dividing a network into separate zones so that devices in one zone cannot freely talk to devices in another. Medical devices go in one zone. Office workstations go in another. Guest Wi-Fi goes in a third. Rules, enforced by the network equipment, decide exactly which conversations between zones are allowed.
The benefit is containment. If a vitals cart is compromised, it cannot wander into the EHR server because the network will not let it. The incident stays small.
An earlier article in this series made the same point about guest Wi-Fi and clinical systems. Medical devices belong on the protected side of that line, and they deserve their own zone with only the connections they genuinely need.
Segmentation is not magic, and it is not as simple as moving devices onto another VLAN and hoping. It has to be designed around how the devices actually communicate, so that clinical workflows continue to work. Done carefully, it is one of the most effective protections available for equipment that cannot be patched.
Start With an Inventory, Because You Cannot Protect What You Cannot List
Every serious guideline on this topic begins the same way: know what you have.
An inventory of connected devices should capture the device name and model, its location, what software it runs, how it connects, who services it, whether it holds or transmits patient information, and when manufacturer support ends.
This is also the foundation of the Security Risk Analysis the HIPAA Security Rule already requires. A risk analysis that does not account for a practice’s connected devices is incomplete by definition.
HHS has proposed an update to the Security Rule that would make a documented technology asset inventory and a network map explicit requirements. That update remains proposed and not final, and the existing rule continues to be enforced. But the direction is clear, and a practice that builds the inventory now is preparing for both the current rule and the likely future one.
NIST’s cybersecurity framework treats asset management as the first step for the same reason. Everything else, patching, monitoring, segmentation, response planning, depends on knowing what is actually there.
Ask Hard Questions Before You Buy Another Device
The best time to address device security is before a device is ever installed.
Practices buying or leasing new equipment can ask the manufacturer a short list of direct questions.
How long will you provide security updates for this device, and what happens when support ends?
Do you provide a software bill of materials, so we know what components are inside?
Can the default password be changed, and does each device have unique credentials?
Is patient data encrypted in transit and at rest?
How does your remote support access work, and can we control when it is active?
Will you sign a Business Associate Agreement if you will have access to patient information?
A manufacturer with strong answers will welcome the questions. A manufacturer who cannot answer is telling you something important about the product.
When You Cannot Patch It, Compensate
Most practices will own at least some devices that cannot be updated. Replacing every one immediately is rarely realistic, so the practical goal is to reduce risk while the device remains in service.
Compensating controls typically include placing the device in an isolated network zone, restricting its connections to the specific systems it needs, disabling unused services and ports, changing default credentials wherever possible, controlling vendor remote access so it is enabled only when needed, and monitoring the device’s network traffic for anything unusual.
Alongside these, the practice should keep a replacement plan. A device with no security support and no realistic path to updates is a liability with an expiration date, and the plan should say when it leaves service.
Vendor Remote Access Deserves Its Own Policy
Of all the weaknesses listed above, vendor remote access is the one most often overlooked, because it feels like a service rather than a risk.
A manufacturer or service company connects to a device to troubleshoot, update software, or pull logs. That connection may use a remote access tool installed years ago, a shared account, or a permanent tunnel into the practice’s network. If the vendor is ever compromised, that connection becomes a way into every practice the vendor serves.
A sensible policy is short. Vendor access should be tied to named individuals, not shared logins. It should require multifactor authentication. It should be enabled only for a defined maintenance window and turned off afterward. And every session should be logged so the practice can see who connected and when. Our managed IT services team can help negotiate and enforce those terms with the vendors you already use.
Monitoring matters here too. Devices that cannot run security software can still be watched at the network level, where unusual traffic, new destinations, or after-hours connections stand out. Our cybersecurity services include exactly this kind of visibility for equipment that cannot protect itself.
Include Devices in Your Incident Planning
A practice’s incident response plan should address what happens when connected devices are affected.
Who is told first? How does the practice continue seeing patients if monitoring equipment is offline? How are readings captured manually in the meantime? Which vendor must be contacted, and do staff have that contact information on paper?
An earlier article in this series described how a single inexpensive printer can stop an entire practice. Connected clinical devices can do the same, with higher stakes. A short tabletop exercise that walks through a device outage is one of the least expensive ways to find out whether the plan works.
What This Means for Miami and South Florida Practices
South Florida practices face several local factors that raise the stakes on this issue.
The region has a large, older population, and with it a high concentration of cardiology, primary care, endocrinology, and other specialties that rely on connected monitoring and diagnostic equipment. Remote patient monitoring programs, where patients take devices home and readings flow back to the practice, are growing here, which means the practice’s security extends to equipment it does not physically control.
Many practices operate in dense, multi-tenant medical buildings with shared network infrastructure, which makes careful segmentation and clear ownership of the network more important.
Hurricane season brings power events that affect connected devices in ways ordinary computers do not. Equipment that loses power and restarts may come back with changed settings, reopened remote access, or reset credentials, and a practice rarely has a checklist for confirming everything returned correctly.
And because many practices here lease equipment, the lifecycle question matters. When a leased device returns, its stored data and credentials must be handled properly, a point that echoes the copier and old computer issues discussed elsewhere in this series.
Ask Your IT Provider These Questions
Do we have a complete inventory of every connected medical device in the practice, including the software it runs and when manufacturer support ends?
Are any of our devices running unsupported operating systems, and what compensating controls protect them?
Are our medical devices on a segmented network, separate from front desk systems and guest Wi-Fi?
Who controls vendor remote access to our devices, and is it enabled only when needed?
Have the default passwords on our devices been changed?
Is our Security Risk Analysis current and does it explicitly include our connected devices?
If your IT provider cannot answer these clearly, the vitals cart in exam room three may be the least examined computer in your practice.
Quiet Does Not Mean Safe
Connected medical devices rarely cause trouble. They take readings, send them along, and go back to waiting. That reliability is what makes them easy to forget.
The goal is not to fear the equipment. It is to treat it with the same discipline given to every other system that touches patient information: know what you have, know who is responsible, and limit what each device is allowed to reach.
ITva Technologies provides managed IT and cybersecurity services for medical practices across Miami-Dade and Broward, with specific experience reviewing the connected clinical equipment that rarely appears on any inventory.
Our managed IT services include building and maintaining a device inventory, designing network segmentation around real clinical workflows, and managing vendor access so exam room equipment stays on a short, controlled leash.
Our cybersecurity services include risk analyses that explicitly account for connected devices, along with monitoring that can spot unusual behavior from equipment that cannot run its own protection.
If your practice has never listed every connected device it owns, that is worth doing before an assessor, an insurer, or an attacker does it for you.
Schedule a free connected device assessment with ITva.
We will inventory your devices, review how they connect, and show you where the biggest exposures sit.
Because the cuff was never going to raise its hand.
Someone has to ask whether it is safe.
Frequently Asked Questions
Are connected medical devices really a risk for a small practice?
Yes. Vitals stations, ECG machines, imaging equipment, and remote monitoring kits run software, connect to the network, and handle patient information. Small practices often have fewer controls around them than hospitals, and these devices are frequently left unpatched.
Who is responsible for securing these devices, the manufacturer or the practice?
Both, in different ways. Manufacturers are responsible for designing security into their products, and the FDA’s guidance addresses that. The practice remains responsible under the HIPAA Security Rule for protecting patient information on its devices and network, including how those devices are configured and connected.
What is network segmentation and why does it matter?
Segmentation divides a network into zones so devices in one zone cannot freely communicate with devices in another. If a medical device is compromised, segmentation helps keep the incident from spreading to the EHR and other systems.
What can a practice do about devices that cannot be patched?
Use compensating controls: isolate the device in its own network zone, restrict its connections to only what it needs, change default credentials, control vendor remote access, monitor its traffic, and keep a replacement plan for when it leaves service.
Is the proposed HIPAA Security Rule update final?
No. HHS proposed an update in 2025 that would require a technology asset inventory, a network map, network segmentation, and other measures. As of this writing it remains a proposed rule, and the existing Security Rule continues to be enforced.
What should we ask a manufacturer before buying a connected device?
Ask how long security updates will be provided, whether a software bill of materials is available, whether default credentials can be changed, whether patient data is encrypted in transit and at rest, how remote support access works, and whether the vendor will sign a Business Associate Agreement.