How smart technology is changing the world of medicine, and what it does to a clinic’s attack surface

What actually changed on the clinic network

Ten years ago, a small practice network was a server in a closet, a handful of workstations and a fax line. Today a six-chair dental office might run intraoral sensors and a cone-beam CT scanner on dedicated Windows PCs, a cloud practice-management system, an imaging bridge, a VoIP system, a patient-intake tablet kiosk and a guest Wi-Fi network. A primary care clinic adds connected vital-signs monitors, a lab interface, an e-prescribing service and sometimes infusion pumps reporting to a dose-error reduction server.

Each of these is good medicine. Each is also a computer with an IP address, and most of them were designed by a vendor whose priority is clinical function, not your threat model. Smart technology changed medicine, and it changed what a clinic has to defend.

The device you are not allowed to patch

The hardest conversation in clinic security is about devices you are not allowed to touch. An imaging modality or a pump runs a validated configuration. Installing a Windows update yourself can void the vendor’s support or change behavior the manufacturer tested. Patches arrive when the vendor qualifies them, which can be months or years later.

So we stop trying to patch our way out and isolate instead. The question for every connected medical device becomes: what does it actually need to talk to, and can we make that the only thing it can reach? For most devices, the answer is one or two servers on two or three ports.

VLAN segmentation for IoMT and DICOM

Here is the layout we use for an outpatient practice. It fits on a single managed switch and a small business firewall, and it maps neatly to the containment map on our triage console.

Three practical notes. First, document which ports each vendor really uses. Their install guides often say “open all ports to the server,” and a packet capture during a normal clinic day usually shows two. Second, put the imaging PCs in operatories on the imaging VLAN, not the clinical one, and take email off them. A CBCT workstation does not need Outlook. Third, run vendor remote support through a jump host that you enable per ticket. Always-on vendor access tools are among the most common ways into a practice.

FIDO2 hardware keys for EHR portals

Most clinic breaches we triage start with a stolen login, not a clever exploit. Text-message codes and push approvals help, but they can be phished in real time or worn down with repeated prompts. FIDO2 security keys cannot, because the key signs a challenge bound to the real website’s origin. A lookalike login page gets nothing usable.

Clinics have a particular problem: shared workstations and staff who move between rooms. What works in practice:

• One key per person on their badge lanyard, plus a second enrolled key locked in the office safe for when one goes through the wash.
• FIDO2 for the EHR or practice-management portal, Microsoft 365 or Google Workspace, remote access and the backup console. Start with administrators and anyone who can e-prescribe.
• Fast user switching or tap-and-go badge readers on shared clinical PCs so nobody leaves a session open to save thirty seconds.
• Retire SMS once keys are in place, or attackers will just choose the weaker method.

The HIPAA Security Rule already requires person-or-entity authentication at 45 CFR 164.312(d), automatic logoff at 164.312(a)(2)(iii) and audit controls at 164.312(b). HHS’s January 2025 proposed update to the Security Rule would make multi-factor authentication an explicit requirement. Check its current status with your compliance counsel, but phishing-resistant MFA is clearly where the rule is heading.

A zero-trust endpoint baseline for outpatient clinics

“Zero trust” is overused, but the core idea is useful: no device gets access just because it is plugged into the clinic network. Each session is checked against who the user is and whether the device is healthy. For a practice, that becomes a short, enforceable baseline:

1. No local admin for clinical staff. Install requests go through IT. This one control blocks a large share of commodity malware.
2. Windows LAPS so every PC has a unique local administrator password.
3. BitLocker on every workstation and laptop, with recovery keys escrowed. A stolen laptop becomes a hardware loss, not a breach report.
4. Attack Surface Reduction rules in block mode, especially Office child processes and credential theft from LSASS.
5. Application allowlisting on imaging PCs and kiosks, where the software list barely changes.
6. Conditional access that only lets compliant, managed devices reach the EHR and email.
7. Five-minute screen lock on anything in a patient-facing room.
8. Sysmon and EDR feeding one log store, using the baseline rules on our homepage.

When it goes wrong anyway

Practices measure downtime in cancelled appointments. When we plan recovery with a clinic, we write the restore order down: identity first, then the practice-management database, then imaging, then everything else. The imaging archive is usually the largest dataset and the slowest to pull back from the cloud, which is why it should not be first.

Before you need it, run your own numbers through the 3-2-1-1-0 recovery calculator. If the answer is “four days to see patients,” you want to learn that on a quiet Tuesday, not during an incident.

Runbook takeaways

Segment

IoMT, imaging, clinical workstations, front desk and guest Wi-Fi on separate VLANs

Allow

Modality to PACS on DICOM 104 / 11112 or TLS 2762, nothing else

Authenticate

FIDO2 keys for EHR, email and remote access; SMS codes retired

Baseline

Windows LAPS, BitLocker, ASR rules, auto-logoff, no local admin for clinical staff

Recover

Practice-management database restored first; test it on a schedule