500 Devices Already on Your Network With No Security Review. Here's the Tiered Path Out.

Medical device sprawl is not a future problem. It is happening right now, in your organization, on your network. The average health system manages thousands of connected devices, and that number grows every time a new monitoring system, infusion pump, or imaging unit comes online. The hard reality is that most of those devices arrived without a structured security review. Security, if it was considered at all, was bolted on afterward, and often not at all.

That approach no longer holds. The FDA’s updated cybersecurity guidance for medical devices has raised expectations for manufacturers and health delivery organizations alike. HIPAA enforcement has expanded its lens to include device-related vulnerabilities. And at the clinical level, an unsecured device is not just an IT risk. It is a patient safety issue. Ransomware that locks an infusion pump, a rogue device exfiltrating data over an unmonitored port, a default credential left unchanged on a ventilator interface: these are not theoretical scenarios anymore.

The fix is not a better firewall or a tighter patch cycle applied to existing infrastructure. The fix is building security into the device onboarding lifecycle itself, from the first conversation with a vendor to the moment a device is handed off to ongoing monitoring. This post walks through how to do exactly that.

Stage 1: Pre-Procurement and Vendor Vetting

Security does not start at the loading dock. It starts in the procurement conversation. Before any purchase order is signed, your team should be asking vendors a structured set of security questions. What operating system does the device run, and is it still supported? Does the device have a published Software Bill of Materials (SBOM)? What is the manufacturer’s documented patch and vulnerability disclosure process? Does the device support certificate-based authentication, or does it rely solely on default credentials?

These questions are not obstacles to procurement. They are inputs to a vendor security scorecard that your team should be building and maintaining. If a vendor cannot answer basic questions about how their device handles credential management or network communication, that is risk data. It belongs in the purchasing decision, not discovered six months after deployment.

The security checkpoint at this stage: No device moves forward without a completed vendor security questionnaire reviewed by both InfoSec and clinical engineering.

Stage 2: Network Segmentation and Provisioning

When a device physically arrives on-site, it should have a network home waiting for it, not be handed a generic guest VLAN or placed on the flat corporate network. Network segmentation is foundational to medical device security, and provisioning should be part of the onboarding workflow, not an afterthought.

Device-specific VLANs or microsegmentation policies should be defined during the procurement stage based on what the device needs to communicate with and what it does not. For example, an infusion pump has no business reason to reach the internet directly. An imaging workstation does not need access to HR systems. These communication boundaries should be codified before the device goes live, reviewed by InfoSec, and enforced through your Network Access Control (NAC) platform.

The security checkpoint at this stage: Every new device is provisioned into a defined network segment with documented, least-privilege communication rules before receiving an active IP address.

Stage 3: Identity and Credential Assignment

This is the most technically underserved stage in most onboarding programs, and arguably the most consequential. Every device on your network should have a unique, managed identity. Not a shared service account. Not a default vendor credential that is never changed. A verified, tracked identity that ties the device to a specific role, location, and access scope.

In practice, this means deploying X.509 certificates for device authentication where supported, enforcing MACsec or 802.1X policies at the port level for wired devices, and ensuring NAC policies reject any device that cannot present valid credentials. For devices that do not support certificate-based auth, the onboarding process should document the compensating controls that are in place: network isolation, enhanced monitoring, mandatory credential rotation, and access logging.

This is not about perfection. It is about having a consistent, documented answer to the question: how do we know this device is who it says it is? That answer needs to exist for every device, and it needs to be maintained as devices are updated, relocated, or decommissioned.

The security checkpoint at this stage: Device identity is established and recorded in your CMDB before clinical deployment, with credentials and certificates linked to a defined rotation or renewal policy.

Stage 4: Cross-Functional Ownership and Shared Accountability

One of the most common failure modes in device security is organizational, not technical. Onboarding gets siloed. Biomed handles the clinical side. IT handles the network side. Nobody owns the handoff. And in that gap, security steps get skipped or deferred indefinitely.

A mature onboarding program requires a cross-functional ownership model that is defined before any specific device arrives. The core team should include MDI, clinical engineering, InfoSec, clinical operations, and procurement. Each function owns specific stages and checkpoints, but the program itself belongs to everyone.

Procurement owns the vendor vetting scorecard. Clinical engineering owns device configuration and integration testing. InfoSec owns network provisioning and identity requirements. Clinical ops owns the deployment readiness review and post-go-live escalation path. This is not a committee. It is a RACI model with teeth, where no device advances to the next stage without sign-off from the responsible function.

The security checkpoint at this stage: A completed onboarding checklist with named sign-offs from each function is required before any device goes live in a clinical environment.

Stage 5: Vulnerability Baseline, Patching Policy, and Monitoring Handoff

Onboarding ends when the device transitions to ongoing operations, but that transition should not be a black hole. Before a device goes live, you need three things documented: a vulnerability baseline, a patching policy, and a monitoring handoff plan.

The vulnerability baseline is a snapshot of the device’s known CVEs at the time of deployment, pulled from the manufacturer’s SBOM or security disclosure portal. It establishes a starting point that your security team can track against as new vulnerabilities are published. The patching policy defines who is responsible for updates, the acceptable patching window, and what compensating controls apply when a patch cannot be deployed immediately.

The monitoring handoff ensures that your security operations team knows the device exists, knows what normal behavior looks like for that device type, and has alerting configured for anomalies. A device that no one is watching is a device that attackers can use indefinitely.

The security checkpoint at this stage: Device is registered in the vulnerability management program with a baseline scan, a documented patching owner, and active monitoring enrollment before clinical use begins.

The Reality of 500+ Devices Already Out There

If you read this and immediately thought about the hundreds of devices already deployed without any of these controls, you are not alone. Backfilling security on a live fleet is one of the most challenging problems in MDI, and there is no version of this that does not require sustained effort. But there is a tiered path forward.

For net-new devices, start the structured onboarding process immediately. Establish the cross-functional team, build the vendor scorecard, define your network provisioning standards, and begin tracking device identity from day one. The program does not have to be perfect to be better than nothing.

For legacy devices, begin with visibility. Get every device into your CMDB if it is not already there. Run a vulnerability scan across the fleet and prioritize remediation by device criticality and CVE severity. Apply network segmentation to the highest-risk device classes first, even if it is a rough segmentation that gets refined over time. Assign ownership to each device class so that someone is accountable for its security posture.

Process maturity is measured not by how polished your documentation looks, but by how consistently you can answer three questions: Do we know what devices are on our network? Do we know who is responsible for each one? And do we have a defined response when something goes wrong with one of them? When you can answer all three with confidence, you are ready for the next wave of connected devices.

Security Is a Clinical Responsibility

The organizations that get medical device security right are not the ones with the biggest InfoSec budgets. They are the ones that stopped treating security as something you add to a device and started treating it as something you build into the process of bringing a device into a clinical environment. That shift, from reactive to structural, is the whole game.

The onboarding lifecycle is your best leverage point. Use it.