5 Steps to Build an IoMT Security Program

Most hospitals can’t secure what they can’t see. If only 29% of organizations have a complete IoT/OT inventory, and a 1,000-bed hospital may run about 15,000 connected medical devices, then IoMT security needs a clear program, not one-off fixes.

If I had to boil this down, I’d say the article makes one point: treat IoMT security like patient care risk, not just IT work. That means I need to put five parts in place and connect them:

• Set scope and ownership so IT, security, biomed, compliance, and supply chain know who does what
• Build a device inventory with model, firmware, OS, location, network data, and ePHI handling
• Score risk based on cyber exposure and patient safety impact
• Apply controls like segmentation, access limits, patching, encryption, and exceptions tracking
• Watch devices and vendors over time through traffic monitoring, advisory review, procurement checks, and playbooks

A few numbers show why this matters:

• 67% of healthcare organizations were hit by ransomware in 2024
• 82% of healthcare organizations have had an IoT-focused cyberattack
• 21% of medical devices use weak or default credentials
• Only 13% of medical devices support endpoint protection agents
• More than 20% of organizations hit by cyberattacks reported higher mortality rates

Winning Strategies for Medical Device Lifecycle Management and Security

sbb-itb-535baee

Quick Comparison

So the short version is simple: inventory drives risk, risk drives controls, and controls need monitoring and governance to hold up.

Step 1: Build a Complete IoMT Asset Inventory

Start with the inventory. Every other IoMT security move depends on it.

Only 29% of organizations say they have a complete inventory of their IoT/OT devices, even though they average nearly 9,685 such devices per organization.^[4] That gap is a big deal. If you don’t know what’s connected, it’s hard to score risk, segment devices, monitor traffic, or review new purchases with any confidence.

Build the inventory first, then use it to guide those next steps.

Capture Device, Software, and Network Details

A useful inventory needs to do more than list device names.

For each asset, record make, model, serial number, firmware version, and OS version. Add network details like IP address, MAC address, hostname, and VLAN. Include how the device connects - wired Ethernet, Wi-Fi, cellular, or Bluetooth - plus its physical location down to the department or floor.

It also helps to mark whether the device stores or sends ePHI. On top of that, document enabled protocols such as HL7, DICOM, RDP, Telnet, and any remote access settings. Those details are what make vulnerability mapping and patching possible. Without them, teams are stuck guessing.

Classify Devices by Clinical Criticality and Lifecycle Risk

After you identify assets, sort them by clinical impact and lifecycle risk.

Classify devices based on patient safety impact and downtime tolerance. A ventilator or defibrillator belongs in the highest-criticality group. An administrative network printer is nowhere near that level. This is one place where IT can’t work alone. Clinicians and biomedical teams need a seat at the table, because a technical score by itself won’t tell you what a failure means for patient care.

Lifecycle risk matters just as much. Track EOL/EOS dates, patchability limits, and legacy operating systems for every device. Many IoMT assets in U.S. hospitals run old operating systems that can’t be updated because of manufacturer limits or FDA-related configuration constraints. When you know which devices fall into that bucket, you can put compensating controls in place instead of leaving a blind spot.

That often means:

• tighter segmentation
• more monitoring
• restricted outbound connectivity

This classification should also feed capital planning. If a device is high criticality, hard to patch, and close to EOL/EOS, it should move up the replacement list.

Connect Inventory Data to Security and Procurement Workflows

An inventory only matters if people use it.

Tie device records to network segmentation rules, vulnerability management tools, and incident response playbooks. That way, if a new CVE hits a specific infusion pump model, your team can pull the affected device list right away, find those assets by VLAN, and put temporary controls in place while a patch or vendor fix is in progress.

Procurement should use the same data. Before any new device goes live, the inventory should trigger a security review to check for known high-risk traits, like an unsupported OS or weak patch options. Censinet RiskOps™ centralizes device risk data, vendor documentation, and assessment workflows for shared security and procurement review.

To keep the inventory current, use automation. Daily or weekly network discovery scans should sync with biomedical CMMS and procurement records. Clear ownership across IT, security, and clinical engineering also matters, because data quality slips fast when nobody owns it.

Use the inventory to prioritize risk assessments in Step 2.

Step 2: Assess IoMT Risk and Map It to Controls

Once your inventory is in good shape, score each device based on two things: its technical exposure and its clinical impact. That gives every device a risk profile that reflects both the security side and the care-delivery side.

Evaluate Threats, Vulnerabilities, and Patient Safety Impact

Common IoMT threats include ransomware, unauthorized remote access, default credentials, outdated or unpatchable operating systems, insecure services like Telnet or SMBv1, and weak encryption. Problems like these can interrupt care, expose ePHI, or give attackers a way to change how a device behaves.

What sets IoMT risk apart from standard IT risk is the patient safety dimension. Score each finding for patient safety, device effectiveness, data security, likelihood, and residual risk.^[5][6] The same flaw can mean very different things depending on where it shows up. A weakness on an ICU infusion pump should not be treated the same way as that same weakness on an office workstation.

AAMI/IEC 80001-1 looks at networked medical device risk through three properties: patient safety, device effectiveness, and data/system security.^[2][3][7] Use all three when you score each finding.

Map Findings to Technical and Administrative Controls

After scoring each risk, connect it to a control response. The NIST Cybersecurity Framework gives you a clear structure: Identify, Protect, Detect, Respond, and Recover. When you map findings to those functions, your control choices are easier to trace and audit.

Map each scored risk to a specific control response.

FDA quality-management guidance says an adequate control set should include, at minimum, authentication, authorization, cryptography, code, data, and execution integrity, confidentiality, event detection and logging, resiliency and recovery, and updatability/patchability.^[8] Use that list as a control checklist. If a device falls short, document the compensating control and the residual risk decision.

Every material finding should go into an IoMT risk register. Each entry should include:

• An asset identifier
• A risk description
• A score
• Mapped controls
• A designated owner
• A remediation timeline

Also state the action: remediate, mitigate, or accept. Reassess entries whenever there is a new vulnerability disclosure, a software update, a network change, or a device relocation.^[7][9]

Use the register to prioritize the controls in Step 3.

Centralize Risk and Remediation Tracking

IoMT risk assessments can fall apart fast when security, HTM/biomed, compliance, and vendor management all run separate processes. Findings get duplicated. Remediation slows down because ownership is fuzzy. And nobody sees the full picture across the device fleet.

Bring device risk, vendor documentation, control status, and remediation tasks into one shared workflow so every team works from the same record.

Step 3: Put Core IoMT Security Controls in Place

Now that your risk register is built and your findings are scored, the next step is turning that work into safeguards you can actually use. The aim is simple: cut compromise risk without getting in the way of care. Use the risk register to rank controls based on patient impact and exposure.

Segment Networks and Restrict Access Paths

Network segmentation is a core IoMT control. Only 13% of medical devices support endpoint protection agents^[10], so old-school endpoint security won't cover enough ground. In practice, the network becomes your main line of defense.

Use macro-segmentation for broad zones, then add micro-segmentation to limit device-to-device traffic. Route vendor access through jump hosts with MFA, time limits, and session recording. Each access request should map to a specific change ticket, and sessions should be scheduled outside peak care hours. HHS 405(d) guidance says medical devices should sit on dedicated, highly restricted networks, with only the traffic needed for device operation allowed.^[11]

Once those traffic paths are locked down, shift to the devices themselves.

Harden Device Settings, Encryption, and Patch Processes

Start with manufacturer-approved settings as your baseline. Where the device supports it, remove default credentials and turn off unused services. A reported 21% of medical devices use weak or default credentials^[10], and that's one of the simplest attack paths to shut down.

For encryption, enforce TLS 1.2 or higher for data in transit. For patching, test updates in a non-production environment before deployment, then schedule maintenance windows with clinical engineering and department leadership. Legacy or unsupported devices need compensating controls. Isolate them, limit access through jump hosts, and record each decision in the risk register.

These settings shouldn't live in a spreadsheet no one checks. Assign ownership and track them over time.

Track Technical and Operational Controls in One View

Technical controls like segmentation, encryption, and access restrictions don't hold up on their own. They need operational support behind them. Patch governance, vendor risk processes, incident response playbooks, and clinician training are what keep those safeguards working over time.

Centralize control status so security, biomed, procurement, and compliance are all working from the same record. That view should show items like:

• Segmentation status
• Secure baseline compliance
• Patch status
• Open exceptions

That way, leaders can review status in one place instead of piecing it together across teams. Censinet RiskOps™ can centralize inventory, third-party risk, and control status in one record.

Step 4: Run Monitoring, Vendor Risk, and Program Governance

Controls set the starting point. Monitoring is what keeps that work current. Use the same asset inventory, risk register, and control status from the earlier steps.

Monitor Device Behavior and Respond to New Vulnerabilities

A 1,000-bed hospital may manage about 15,000 connected medical devices.^[13][14] At that scale, one-time hardening isn't enough. Things change too fast. Continuous monitoring closes that gap.

In practice, that means passively watching clinical network traffic so you can build a baseline for normal device behavior. Once you know what "normal" looks like for a device type, unusual activity gets easier to spot. That could be unexpected outbound connections, odd traffic after hours, or lateral movement from nearby systems. Those signals should flow straight into your SIEM so device alerts are tied to broader enterprise events instead of being reviewed on their own.

Monitoring shows that something is off. Advisory intake helps explain why it matters.

Assign one owner to track FDA communications, CISA advisories, and vendor bulletins. Log the affected models, severity, CVEs, and mitigation guidance. Then match each advisory to your asset inventory so you can see which departments and locations are exposed. Clinical engineering, IT security, and clinical leadership should review patient safety impact together before remediation is scheduled. Critical vulnerabilities should be patched out of cycle as soon as possible, while routine findings can follow a regular remediation schedule.^[1][15] Every decision - patch, compensating control, or accepted risk - should be documented with a timestamp for audit purposes.

IoMT playbooks also need to account for devices that can't be taken offline. A ventilator in active use is not the same as a noncritical system. Your playbooks should spell out when a device can be pulled and when compensating controls - such as isolation, blocked external destinations, or disabled vendor access - are the safer option. Tabletop exercises with clinical staff help test whether those plans hold up in real conditions.

Bring Third-Party Risk into Procurement and Lifecycle Management

Once the response process is set, bake vendor expectations into purchasing.

82% of healthcare organizations have experienced an IoT-focused cyberattack,^[12] so vendor security can't sit on the sidelines during procurement.

Before any IoMT device is approved for purchase, require vendors to complete a structured security questionnaire and provide their Manufacturer Disclosure Statement for Medical Device Security (MDS2) form. MDS2 forms show how a device handles encryption, authentication, logging, and network interaction. That information directly shapes segmentation design and incident response planning. When available, ask for a software bill of materials (SBOM) so your team can match CVEs against known components as soon as a new vulnerability is disclosed.

Contracts should spell out clear commitments, including:

• Minimum encryption standards
• Patch notification timelines
• Breach notification terms
• Remote access rules

For high-risk vendors, require added controls or executive sign-off. High-criticality vendors should be reassessed on a set schedule, with interim reviews triggered by public breaches, critical product vulnerabilities, or major changes in the vendor's role. Remote access sessions should be time-bound, logged, and reviewed on a regular basis, and unused vendor accounts should be removed on a set schedule. Updated risk ratings should then feed into renewal and renegotiation decisions.

Conclusion: A 5-Step Model for a Resilient IoMT Security Program

Taken together, these five steps turn IoMT security into a repeatable operating model. In this guide, the process works as one lifecycle: scope and governance, inventory, risk assessment, controls, and continuous monitoring. That lifecycle aligns with NIST CSF and ISO 27001.

The stakes are high. In 2024, 67% of healthcare organizations were hit by ransomware^[10][16], and more than 20% of organizations experiencing cyberattacks reported increased mortality rates^[17]. That’s why IoMT security needs to be handled as clinical risk management, not just a technical task. A formal IoMT security program helps cut exposure by making sure critical devices are inventoried, risk-scored, segmented, and monitored.

This only works when the steps operate as a connected system. Inventory sharpens risk. Risk drives controls. Controls shape monitoring. Vendor findings feed back into procurement and governance. Miss one link, and the whole process gets weaker.

Censinet RiskOps™ centralizes third-party and enterprise risk assessments and tracks control status across medical devices, clinical applications, PHI, and patient data. That visibility makes the program easier to govern and audit.

IoMT security is a clinical risk management responsibility, not just an IT function. It belongs in governance, procurement, and patient safety so teams can reduce harm and recover faster.

FAQs

Who should own an IoMT security program?

An effective IoMT security program works best with a federated governance model.

Here’s the idea: a central enterprise risk committee sets the direction under the CISO, while teams across IT security, network operations, clinical engineering, and compliance stay aligned and move in the same direction.

At the device level, ownership should be shared too. A business owner handles clinical use, while a technical owner from IT or Security manages technical and security requirements. Censinet RiskOps can help bring those teams together and keep everyone on the same page.

How do we prioritize high-risk medical devices?

Start with a full asset inventory. For each device, document its clinical function, PHI exposure, and connectivity.

Next, group devices by their role in patient care. Treat life-sustaining devices like ventilators and infusion pumps as high risk.

Use a multifactor risk score that combines:

• vulnerability severity
• clinical impact
• network exposure
• ease of exploit

Censinet RiskOps™ can help centralize asset and vulnerability data, so teams can focus remediation on the most critical risks first.

What should vendors provide before device approval?

Before device approval, vendors should provide the core security documents your team needs for risk management. That usually includes:

• MDS2 form
• SBOM
• security configuration guidance
• patch and update policies
• penetration test summaries

If the device falls into a category that requires it, verify FDA 510(k) clearance too.

The best time to set these requirements is during procurement. That gives you a clear security baseline before the device connects to the network.

Related Blog Posts

• IoT Medical Devices and Vendor Risk: Connected Healthcare Security Challenges
• IoMT Cybersecurity: Impact on Patient Safety
• Ultimate Guide to IoT Risk Assessment in Healthcare
• Best Practices for IoT Device Security