IoMT (Internet of Medical Things) devices like wearables, ventilators, and infusion pumps are transforming healthcare by enabling real-time data sharing and decision-making. But these devices face critical medical device security risks, especially at the firmware level. Weak encryption, outdated software, and poor authentication expose patient safety and hospital networks to serious risks.
Key challenges include:
- Unencrypted firmware and data: Patient data and device designs can be intercepted or tampered with.
- Outdated firmware: Slow update cycles leave devices open to known vulnerabilities.
- Weak authentication: Hardcoded credentials and shared passwords make devices easy targets.
To improve security:
- Encrypt firmware and use hardware-based key storage (e.g., TPM or HSM).
- Implement a structured patch management program to prioritize updates.
- Secure boot processes with digital signatures and authenticated updates.
- Centralize risk data and require vendors to provide SBOMs and MDS2 forms.
With regulatory frameworks like the FDA's Section 524B, healthcare organizations must address these risks to ensure compliance and protect patient safety.
Biggest Firmware Vulnerabilities & How to Fix Them | NetRise's Thomas Pace
sbb-itb-535baee
Common IoMT Firmware Security Problems
Securing IoMT (Internet of Medical Things) devices is no small task. These devices come with unique challenges, especially when it comes to firmware security. Unlike standard IT systems, IoMT devices often operate on specialized or outdated firmware managed by external vendors. This leaves healthcare organizations with limited control over third-party risk and security measures. Among the many issues, three stand out as particularly damaging.
Unencrypted Firmware and Data Risks
Many IoMT devices transmit and store sensitive patient data without encryption. This lack of protection makes patient health information (PHI) vulnerable to interception, tampering, or theft by attackers with network access. Beyond data, unencrypted firmware images can be reverse-engineered, exposing the device's design and potential vulnerabilities.
A major hurdle is the lack of visibility into these devices. Without granular monitoring, it’s difficult to detect unencrypted transmissions or unusual activity. As Scott Christensen, Security and Systems Engineer at MarinHealth Medical Center, explained:
"We knew that in order to secure the devices, we needed to segment the network. And to effectively segment the network, we had to be able to see what was happening." [1]
This lack of visibility doesn’t just affect encryption - it complicates efforts to address other firmware-related security gaps as well.
Outdated Firmware and Slow Update Cycles
Another critical vulnerability lies in outdated firmware. Over time, older firmware accumulates known vulnerabilities, often cataloged as CVEs (Common Vulnerabilities and Exposures). Since these flaws are publicly documented, they provide attackers with a roadmap for exploitation.
The problem is worsened by the "validation gap" - the delay in rolling out firmware updates. These delays, which can stretch over months, leave devices exposed to known risks. Additionally, limited visibility into device inventories makes it harder to prioritize updates for the most vulnerable devices. Tonya Fredrickson, IT Security Manager at NLG, highlighted this challenge:
"Axonius provides us with an unprecedented level of detail and understanding of our otherwise relatively unknown estate of IoT and medical devices, profiling risks that we would have otherwise not known about and their potential impact on our hospitals." [1]
Weak Authentication and Hardcoded Credentials
One of the most preventable yet common firmware issues is the use of hardcoded credentials. Many IoMT devices come with default usernames and passwords embedded in their firmware. These credentials are often shared across entire product lines and are sometimes even listed in vendor documentation, making them an easy target for attackers.
Weak authentication mechanisms further exacerbate the problem. The absence of multi-factor authentication, reliance on shared passwords, or storing credentials without encryption leaves devices even more exposed. This also makes it harder for organizations to demonstrate compliance with FDA requirements or accurately assess their security posture. To address these risks, correlating device behavior with MDS2 (Manufacturer Disclosure Statement for Medical Device Security) and FDA data is crucial [1].
How to Fix IoMT Firmware Security Gaps
The risks tied to IoMT devices - like unencrypted data, outdated firmware, and weak credentials - are serious but manageable. Healthcare delivery organizations (HDOs) have access to practical tools and methods to address these vulnerabilities. The challenge lies in identifying the right starting point.
Using Encryption and Key Management
Start by encrypting firmware with AES-256 to prevent reverse-engineering and unauthorized data access.
Equally important is how cryptographic keys are handled. Storing keys in software can leave them vulnerable. Instead, opt for hardware-based solutions such as Trusted Platform Modules (TPM) or Hardware Security Modules (HSM). These tools store keys in tamper-resistant environments, adding an extra layer of security. Pair these efforts with Public Key Infrastructure (PKI) to digitally sign firmware updates. This ensures devices can verify the authenticity of updates before installation, reducing the risk of malicious interference.
These encryption practices lay the groundwork for a safer firmware patch management process.
Building a Firmware Patch Management Program
Outdated firmware is a major security risk, making a formal patch management program a must-have. A solid program begins with a complete inventory of all assets. As Tala Secure aptly points out:
"Hospitals cannot protect what they cannot identify. Providing UDI information, MDS2 data, and discovery profiles enables better inventory, faster patching, and fewer blind spots." [2]
By requiring vendors to supply MDS2 documentation and Unique Device Identification (UDI) data, HDOs gain the metadata needed to track firmware versions, spot vulnerabilities, and prioritize updates based on risk levels rather than convenience.
When rolling out patches, focus on vulnerabilities with the highest risk and greatest clinical impact. Schedule updates during planned maintenance windows, document rollback strategies in case of issues, and use a phased rollout approach to minimize disruptions.
Securing Boot Processes and Firmware Updates
Even the best patch management program can fail if the update process itself isn't secure. A secure boot process is critical - devices should verify the integrity and authenticity of firmware before loading it. As MITRE EMB3D emphasizes:
"The device should validate that the firmware update has not been tampered with before installing it on the device." [3]
This validation involves digital signatures. Vendors sign the firmware image with a private key, and devices use the corresponding public key to confirm its authenticity. It's crucial that the digital signature covers the entire firmware image to prevent tampering.
For over-the-air (OTA) updates, use encrypted and authenticated protocols. Add rollback protection to block the installation of outdated or insecure firmware versions. Finally, restrict manual updates to authenticated administrators to maintain control over the process.
Adding Risk Management to IoMT Security
Technical measures like encryption and secure boot processes are essential for protecting IoMT devices. However, they work best when paired with a structured risk management framework. While encryption and patch management handle immediate threats, risk management ensures long-term oversight and helps prioritize actions strategically. By combining these technical tools with centralized risk insights, healthcare delivery organizations (HDOs) can secure IoMT devices throughout their entire lifecycle.
Centralizing IoMT Firmware Risk Data
One of the main challenges for HDOs is managing data scattered across multiple sources. To address this, organizations should integrate information from clinical engineering, IT security, and procurement into a single system. This unified approach allows for cross-referencing device inventories with trusted resources like the National Vulnerability Database (NVD) and manufacturer security advisories. The result? Real-time identification of vulnerable firmware versions, eliminating the delays caused by periodic reviews.
A centralized system also enables risk-based prioritization. For example, critical devices such as infusion pumps and ventilators can be patched before less essential equipment. This helps decision-makers allocate resources more effectively and address the most pressing vulnerabilities first.
To make this possible, connect your Computerized Maintenance Management System (CMMS) to your security risk platform. This ensures that any changes in device status or firmware versions are updated in real time. Additionally, during the procurement process, require vendors to provide Software Bills of Materials (SBOMs) and MDS2 forms upfront. This approach offers immediate visibility into potential risks associated with new devices.
How Censinet Supports IoMT Firmware Risk Management
To tackle fragmented risk data, Censinet RiskOps™ provides a centralized and continuous risk management solution. Unlike static, annual assessments, the RiskOps model monitors firmware health and vendor compliance throughout a device’s lifecycle.
The platform automates third-party vendor risk management and centralizes risk management tasks in one dashboard. This streamlines remediation efforts, assigns clear ownership, and reduces evaluation time. By consolidating security certifications, SBOMs, and patch histories in one place, Censinet RiskOps simplifies compliance audits under standards like HIPAA and Joint Commission guidelines.
Censinet’s efforts have earned recognition from KLAS Research, including the "Best in KLAS" award for Cybersecurity Advisory Services. Many healthcare CISOs appreciate how the platform replaces manual, spreadsheet-heavy third-party risk processes with automated, standardized digital assessments.
This shift is especially timely given evolving regulatory expectations. For instance, the FDA's Compliance Program Manual (#7382.850), effective February 2, 2026, introduces specific cybersecurity enforcement sections during inspections. It also requires manufacturers to embed security into their quality management systems throughout a device’s lifecycle. As Exponent notes, "FDA expects cybersecurity to be embedded within manufacturers' quality systems and reflected in premarket submissions when applicable." [4]
For HDOs, investing in a strong risk management framework for IoMT firmware security isn’t just good practice - it’s becoming a compliance necessity.
A Practical Roadmap for IoMT Firmware Security
IoMT Firmware Security Roadmap: 5 Steps to Protect Medical Devices
Understanding the challenges and potential fixes is just the beginning - turning that knowledge into action is where the real work begins. Here's how to build a functional program that addresses IoMT firmware security.
Assessing Your Current IoMT Firmware Risk
Start by taking stock of your IoMT devices. This begins with creating a comprehensive inventory of every connected IoMT device in your environment. Use passive network monitoring tools to identify these devices without risking disruptions to clinical operations. Active scanning, while useful in other contexts, can cause older medical devices with legacy firmware to crash - something you definitely want to avoid.
Once your inventory is complete, dig deeper into each device's details, such as its make, model, and firmware version. Compare this information against the National Vulnerability Database (NVD) and MDS2 forms. Go a step further by requesting Software Bills of Materials (SBOMs) from manufacturers. These documents can reveal hidden risks, like vulnerabilities in third-party components or open-source libraries embedded in the firmware. Thanks to Section 524B of the FD&C Act, the FDA now requires manufacturers to provide SBOMs and a post-market vulnerability plan, making this request more feasible than ever.
Next, assign risk tiers based on each device's clinical function. For instance, devices like ventilators, which are critical to patient care, should be flagged as high priority. Combine CVSS severity scores with clinical importance to create a remediation plan that focuses on devices posing the greatest risks to patient safety.
With risks mapped out, you can now structure a remediation strategy that prioritizes safety and establishes strong governance.
Prioritizing Fixes and Governance
Once you've assessed your risks, rank them with patient safety as the top priority. Ensure that firmware security requirements are baked into vendor contracts. Manufacturers should commit to providing security patches for the entire clinical lifespan of their devices - often 10 to 15 years. When rolling out firmware updates, use a staged approach and include documented rollback procedures to avoid interruptions in care. For vendor remote access, move away from open-ended connections. Instead, require time-limited, auditable sessions secured with strong authentication.
"Predictable, secure, and easy-to-deploy updates protect patient safety, reduce downstream issues, and preserve trust." - Tala Secure [2]
These measures create a foundation for ongoing risk reduction and better third-party risk management.
The table below outlines the core steps in a practical IoMT firmware security roadmap:
| Step | Action | Goal |
|---|---|---|
| 1. Inventory | Passive network discovery | Identify all connected IoMT assets and firmware versions |
| 2. Vulnerability Analysis | Cross-reference NVD, MDS2, and SBOMs | Map known CVEs to specific devices |
| 3. Clinical Impact Mapping | Assign risk tiers by device function | Prioritize life-critical devices for remediation |
| 4. Remediation | Staged firmware rollouts with rollback plans | Reduce risk without disrupting care |
| 5. Governance | Embed security into contracts and procurement | Hold vendors accountable across the device lifecycle |
FAQs
How can we find every IoMT device and its firmware version without breaking anything?
To pinpoint all IoMT devices and their firmware versions without interrupting clinical workflows, steer clear of active scanning methods, as they can disrupt delicate medical equipment. Instead, rely on passive network monitoring to observe traffic patterns such as DICOM and HL7 protocols. Combine this with information from sources like CMMS, biomedical databases, and DHCP logs. Additionally, conduct physical audits to uncover shadow devices that might otherwise go unnoticed. Be sure to document each device's details thoroughly to maintain a complete and traceable inventory.
Which devices should we patch first when updates take months to validate and deploy?
When patching delays occur, it's crucial to focus on addressing high-severity vulnerabilities, especially on devices critical to patient safety. A risk-based strategy can help classify vulnerabilities into two categories: uncontrolled (posing significant risks to patient safety or sensitive data) and controlled. For devices with lower risk, consider using network-based defenses like segmentation or virtual patching to reduce threats until maintenance can be performed.
Tools like Censinet RiskOps can help streamline this process. They allow you to document mitigation plans, keep an eye on evolving risks, and ensure your strategies align with clinical leadership. This balance ensures both robust security and uninterrupted patient care.
What should we require from vendors (SBOM, MDS2, UDI) before buying or renewing a device?
Before buying or renewing a medical device, make sure to ask vendors for a machine-readable Software Bill of Materials (SBOM) that aligns with NTIA's minimum elements. This SBOM should list all components, including proprietary, commercial, open-source, and off-the-shelf software. Additionally, request documentation covering secure development practices, processes for monitoring vulnerabilities after the product is released, and detailed instructions on how to securely configure, manage, and update the device within your network.
