Security and Connectivity for IoT Devices


IoT Medical Device Security


Home / IoT Medical Device Security

Partnering with Experts in FIPS Validation

The Allegro Cryptography Engine (ACE™) provides FIPS validated cryptography that is engineered for the unique demands of resource-constrained IoT devices and related applications. Reach out to learn more about this solution and other FIPS validated solutions.


The integration of Internet of Things (IoT) medical devices into the healthcare ecosystem has revolutionized patient care, introducing efficiencies and capabilities previously unimaginable. However, this integration also brings to the forefront the significant risks associated with cyber threats. In a recent study looking at the average cost per data breach in the United States since 2006, Statista noted that ‘the global average cost per data breach was 4.45 million U.S. dollars in 2023.’ Additionally, IBM states that Cyberattacks will top USD 10.5 trillion by 2024.  Ultimately, the need for stringent IoMT security measures is paramount, not only to protect patient data and ensure device integrity but also to prevent detrimentally costly cyberattacks.

Why Secure Medical Devices?

The High Stakes of Medical Data Security

The value of medical data cannot be overstated, with personal health information (PHI) being a prime target for cybercriminals due to its rich content and long-term usability for fraudulent activities. The immutability of medical records makes them significantly more valuable than other types of data, such as credit card information, which can be easily changed if compromised. Med-Tech News outlines how health records are considered 40-50x more valuable than credit card data on the dark web.

Medical data, especially when linked to IoT devices, holds immense value, not only for healthcare delivery but also for malicious entities. The information contained within can be exploited for identity theft, fraud, and various other crimes. The HIPPA Journal states that criminals target medical records because ‘healthcare providers are attractive targets for hackers as they store huge amounts of valuable patient data.’ Information like social security numbers and date of birth, combined with demographic data enable identity theft for loans, credit card fraud, and can be used to impersonate patients to obtain expensive medical paid services, Medicare and Medcaid benefits, healthcare devices, and prescription drugs.

Given its sensitivity and the potential for long-term misuse, securing this data against threats like ransomware and breaches is crucial. Allegro Software recognizes the critical nature of this issue and provides solutions designed to protect against these vulnerabilities, ensuring compliance with standards like HIPAA and mitigating the risk of data breaches.

Visit our IoMT cybersecurity page to explore more information on IoT security in healthcare and related solutions from Allegro.

Regulatory Landscape and Standards for Securing Medical Devices

The landscape of medical device security is governed by a mix of domestic and international standards, including The NIST Cybersecurity Improvement Act and IR 8259 Series, FD&C Act sections 524B and 3305, IEC 62443, AAMI TIR57, and the EU Cyber Resilience Act. These guidelines, while essential, often lack harmonization and detail primarily on the “what” rather than the “how” of securing devices. The guidelines are often written from the Health Delivery Organizations (HDOs) perspective, which are large medical system integrators, who play a crucial role assembling devices from various manufacturers to deliver comprehensive healthcare services. This perspective underlines the fact that medical device security transcends technology, delving into the realm of structure, practices, processes, and procedures. The emphasis is on creating a secure environment that extends beyond mere technological solutions to include the entire ecosystem surrounding medical devices.

HDOs now adopt a broader ecosystem view, considering the security of not just medical devices but all ancillary devices and services that could pose risks, including networked elevators, refrigeration systems, point-of-sale (POS) systems, lighting, and more. This expanded view is crucial in a world where cyber threats are increasingly sophisticated and pervasive.

Omnibus, Medical IoT Devices, & FIPS

In response to the evolving cybersecurity threats, the FDA cybersecurity guidelines for medical devices have been updated, emphasizing a lifecycle approach to securing devices from premarket development to post market management. This includes the introduction of a Secure Product Development Framework (SPDF) to reduce vulnerabilities and a detailed risk management process. The guidance, which supersedes the 2014 premarket cybersecurity document, aims to ensure devices are designed with robust security measures to protect against current and emerging threats. This approach is crucial for maintaining the safety and effectiveness of medical devices throughout their lifecycle.

The Consolidated Appropriations Act of 2023 (Omnibus), was signed into in December 2022, introduces explicit cybersecurity requirements for medical devices. For the first time, the FDA has been granted statutory authority to enforce certain cybersecurity measures for specific devices. This landmark legislation mandates that premarket applications for medical devices include comprehensive cybersecurity plans, processes, and documentation, highlighting the increasing recognition of cybersecurity’s critical role in medical device safety and efficacy. Additionally, the FDA could now start refusing submissions based on cybersecurity concerns. Pre-market submissions must now include sections on cyber security as section 3305 of Omnibus requires a vendor to provide plans to “monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity issues.”

Section 3305 of the Act requires persons who submit premarket applications for medical devices (i.e., PMA, 510(k), or de novo submissions) to include additional information to ensure the device meets cybersecurity requirements that include:

    1. submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits.
    2. design, develop and maintain processes and procedures to provide a reasonable assurance that the device and related systems are “cybersecure,” and make available postmarket updates and patches to the device and related systems to address certain cybersecurity vulnerabilities.
    3. provide a software bill of materials, including commercial, open-source, and off-the-shelf software components.
    4. comply with other requirements the FDA may require through regulations to demonstrate a reasonable assurance that the device and related systems are cybersecure.

The requirements also create a new prohibited act stating “the failure to comply with any requirement under section 524B(b)(2) (relating to ensuring device cybersecurity.)” This new section comes with significant teeth and enables the government to prosecute violations of cybersecurity requirements criminally.

The updated security risk management section of the new guidance contains two new sub-sections, the first regarding “Cybersecurity Risk Assessments.” Cybersecurity risks are difficult to predict. The guidance recognizes that it is impossible to assess and quantify the likelihood of an incident occurring based on historical data or modeling. Accordingly, cybersecurity risk assessment should focus on the exploitability of vulnerabilities within a device or system, and any likely present in the deployed environment. FDA recommends that the cybersecurity risk assessment capture the risks and controls identified from the threat model. It should also include how risks are scored, pre- and post-mitigation, and associated acceptance criteria. It must also include the method for transferring security risks into the safety risk assessment.

The risk management section also contains a new section on “Interoperability Considerations,” addressing cybersecurity issues that may arise from interoperable functionality, including:

The guidance notes that properly implemented cybersecurity controls will help ensure the safe and effective exchange of information (see Design Considerations and Pre-market Submissions Recommendations for Interoperable Medical Devices).  Cryptography is a foundational security element and Appendix 1 Section C highlights the need to utilize NIST FIPS 140-3 validated implementations.

Appendix 4 provides a checklist of documents the FDA recommends be submitted in premarket submissions.

The final guidance also adds and defines new key cybersecurity terms in  Appendix 5. While many of the added terms are new to the guidance, they are adapted from existing definitions from recognized sources, including NIST, the Joint Security Plan, ISO/IEC and CNSSI 4009-2015.

Understanding SBOM and SOUP Analysis

Executive Order 14028 – Improving the Nation’s Cybersecurity

Executive Order 14028, issued by the U.S. government, aims to enhance national cybersecurity measures across federal departments and agencies. This directive emphasizes the importance of creating and managing secure software, including the development and utilization of Software Bill of Materials (SBOM) and analysis of Software of Unknown Pedigree (SOUP).

SBOM Formats

SBOMs provide a comprehensive inventory of software components within a device or application. Understanding and utilizing standardized formats for SBOMs is crucial for effective cybersecurity management.

  • SPDX (Software Package Data Exchange): This standard format for communicating the components, relationships, and licenses of software packages facilitates the sharing and analysis of software bill of materials.
  • CycloneDX: Designed for use in application security contexts and supply chain component analysis, CycloneDX offers a lightweight SBOM standard compatible with modern development tools and practices.
  • SWID (Software Identification Tags): SWID tags help manage and inventory software products, offering a standardized method for software identification that supports cybersecurity and asset management efforts.

Understanding Medical IoT Threats

Cybersecurity threats in the healthcare sector, including malware, data breaches, insider threats, ransomware, and phishing attacks, significantly disrupt patient care and financial operations by compromising the confidentiality, integrity, and availability of sensitive health information. These threats can delay critical treatments, leading to potential life-threatening situations for patients.

Compromised medical IoT devices can serve as entry points or “springboards” for broader network infiltration, allowing attackers to move laterally within healthcare IT systems to access sensitive data and systems.

Medical IoT Threat Modeling

Medical device cybersecurity is of utmost importance in today’s world. One way to ensure the safety of medical devices is through threat modeling. By using threat modeling, we can build secure devices, eliminate preventable errors, reduce development costs, speed up development, and implement proactive controls to eliminate, mitigate, accept or transfer threats. Additionally, the design artifacts created through threat modeling can be used throughout the total product life cycle.

It’s important to note that there is no one-size-fits-all approach when it comes to threat modeling. One common starting point is to consider the four key questions outlined in “Threat Modelling: Designing for Security” by Adam ShoStack, John Wiley & Sons in 2014. These questions are as follows: What are we working on? What could go wrong? What are we going to do about it? Did we do a good enough job? Additionally, it’s generally better to work in groups when conducting threat modeling, as unstructured discovery tends to be the most effective approach.

Question 1: What are we working on? 

The first step is to develop a common and concise representation of the medical device, its deployment environment(s), its true value proposition, the flow of data to and from the device, operating states, and general use cases.

When developing a threat model, data flow diagrams (DFD) can be used to break down the system into five key elements: External Entity, Process, Data Store, Data Flow, and Trust Boundary. Additionally, cross-functional diagrams and state diagrams can also be helpful.

Question 2: What could possibly go wrong?

Now, with a representative system view, it is time to identify potential threats based on the medical device functionality and the underlying architecture. Microsoft’s STRIDE structured threat modeling paradigm is a common approach and provides robust results.

Using the structure STRIDE method for enumerating and assigning threats to the following classes:

Attack Class Description Example
S – Spoofing Pretending to be someone else A hacker pretends to be an authorized user
T – Tampering Modifying data or code Code or data is changed without notice by malware
R- Repudiation Denial A user denies they have treated a patient with a device
I – Information Disclosure Confidential is disclosed to an unauthorized people A nurse can see the diagnosis of a “Special” patient she is not authorized to see
D – Denial of Service DOS attack A bot or botnet floods a network with unusable packets causing data services to fail
E – Elevation of Privilege Someone obtains privileges they should not have A user makes themselves an admin on the system.

The goal of using the STRIDE strategy while referencing the representative model of the medical device is to generate and classify a list of potential threats.

However, as the Software Engineering Institute points out in “Threat Modeling: A Summary of Available Methods, ” other threat modeling techniques could better fit your use case and overall focus.

The guiding principle is to select a threat modeling methodology and enumerate and categorize threats from multiple angles.

Question 3: What are we going to do about it (the threats)?

Once there is a list of potential threats against the medical device and a system representation of the medical device, the team next decides how to address each threat best. Adam Shostack provides the four common actions that can be taken with each risk:

  • Mitigate. Take action to reduce the likelihood that the threat will materialize.
  • Eliminate: Simply remove the feature or component that is causing the threat.
  • Transfer. Shift responsibility to another entity such as the customer.
  • Accept. Do not mitigate, eliminate, or transfer the risk because none of the above options are acceptable given business requirements or constraints.

When mitigating a threat, the strategies must be identified as a category or individual threats and adequately documented as system requirements. This provides a lasting design artifact to be continuously reviewed during the total product life cycle.

Depending on the complexity of the system, the nature of threats identified, and the process used for identifying threats (STRIDE or another method), mitigation responses may be applied at either the category or individual threat level. Mitigation strategies must be actionable and not hypothetical. They must reflect measures that can be built into a medical device under development.

Question 4: Did we do a good enough job (this time)?

At this point the threat model must be reviewed by all stakeholders and not just the development, quality, and security teams. Areas to focus on include:

  • Does the model accurately reflect the actual system (data flows, state diagram representations, etc.)?
  • Are there additional threats that can be identified?
  • What should trigger a specific re-evaluation of threats? How often should threat modeling be reviewed?
  • Is there a traceability matrix that identifies the source of threats, how the medical device team has chosen to address each threat, results from testing against identified threats, etc.?
  • Has the threat model been properly documented and stored for future use by ongoing maintenance and support teams? What are the artifacts, how are they stored, and who has access?

Secure Medical Device Lifecycle and Need for Security Across the Entire Deployment

Medical IoT device security extends beyond the deployment of the device in hospital settings. Comprehensive security measures must be integrated throughout the entire device lifecycle, from initial design and development through to decommissioning.

Secure Product Development Framework (SPDF)

The SPDF offers a structured approach to integrating security into the product development process. It encompasses practices and procedures designed to minimize vulnerabilities and ensure that medical devices are designed, developed, and maintained with cybersecurity as a central focus. Implementing an SPDF is essential for addressing the dynamic nature of cybersecurity threats and ensuring the ongoing protection of medical IoT devices and the data they handle.

By addressing these critical areas—SBOM and SOUP analysis, understanding medical IoT threats, and ensuring security throughout the device lifecycle—stakeholders in the healthcare and technology sectors can significantly enhance the cybersecurity posture of medical IoT devices, safeguarding sensitive data and ensuring the continuity of care.

A Lifecycle Perspective

Our approach to medical device security encompasses the entire lifecycle of a product, from design to decommissioning. This perspective is essential for understanding how to effectively secure devices at every stage of their existence. It involves a systems-level understanding of security, ensuring that protection measures are in place throughout the product’s life.

Securing medical devices requires a cyber-focused development strategy that incorporates a secure product development framework, attention to the supply chain, including product and software bill of materials (BOM/SBOM), and the creation of multiple chains of trust through documentation and artifacts.

Understanding Risks & Modeling Threats

Every company faces a unique risk profile influenced by regulatory requirements and risk tolerance. This profile guides the security measures implemented in the end product. Threat modeling, as recommended by the FDA, is a critical component of understanding and mitigating risks associated with medical devices.

The MITRE Corporation has developed a playbook for threat modeling medical devices, offering guidelines and best practices to identify, assess, and mitigate cybersecurity threats throughout the device lifecycle. This resource is instrumental for manufacturers and healthcare providers in understanding and addressing potential vulnerabilities.

Challenges in Securing Data

In the healthcare sector, the management of vendor-supplied systems, ranging from medical devices to infrastructure like elevators and HVAC, presents significant security challenges. Many hospitals lack a comprehensive understanding of their networked device inventory, with medical devices constituting the majority of connected assets but only a fraction being directly managed by IT departments. The disparity in device management and oversight, combined with the longevity of medical equipment and a lack of cybersecurity training among medical staff, exacerbates these challenges. Furthermore, the integration of AI and ML in healthcare necessitates human oversight to prevent data corruption or tampering.

Medical device manufacturers are increasingly required to focus on cybersecurity elements such as the Software Bill of Materials (SBOM) and vulnerability management in their premarket submissions. The FDA’s evolving stance emphasizes not just the inclusion of these elements but a comprehensive approach to ensuring devices and their ecosystems are secure against cyber threats. This involves a detailed examination of a device’s threat model, its capability for secure remote updates, and the integrity of its software supply chain.

The IEEE Medical Device Cybersecurity Certification Program, including IEEE 2621 standard represents a significant advancement in the cybersecurity certification of medical devices, initially focusing on devices critical to diabetes management such as blood glucose monitors and insulin pumps, with the potential for application across a broader range of medical devices. This initiative underscores the critical need for robust cybersecurity measures in medical technology, reflecting a growing awareness and response to the vulnerabilities these devices face.

On another front, the evolution of data processing from batch to real-time streams signifies a paradigm shift in how data is handled, particularly in the context of generating and utilizing large language models (LLMs) like GPT. This shift towards real-time processing and online machine learning emphasizes the importance of immediate, dynamic data analysis and application, highlighting the limitations of traditional batch processing methods.

Additional Resources:

IoMT Devices Security: Ensuring Patient Safety & Privacy

Dive into the critical aspect of securing Internet of Medical Things (IoMT) devices, a cornerstone of healthcare innovation, in our insightful article by Loren Shade on This article sheds light on the unique risks that IoMT devices face,...

Securing the Future of Healthcare: IoMT Device Protection

Explore the IoMT risks associated with medical devices and the countermeasures IoMT device manufacturers can take to ensure patient safety and privacy in our guest article written by Loren Shade on Read the Article Allegro highlights the...

Allegro Software Wishes You Happy Holidays

Allegro Software wishes you a Happy Holidays and a wonderful New Year. We appreciate your support and look forward to serving you in 2024. Our team will be monitoring emails and inquiries throughout the holidays, please reach out if you have questions or need...

Best Practices for Managing IoT Related Risks

Allegro’s “Best Practices” document addresses the topic of IoT security related risks by taking a closer look at Critical Requirements and Functional Implementation.

7 Key Elements of Proactive IoT Security

All types of Internet of Things (IoT) devices are under attack. They are routinely recruited as unwitting members of botnets used for Distributed Denial of Service (DDOS) attacks, hosting various malware, and extracting sensitive data. Why are hackers drawn to these...

Open Source Issues in Mergers and Acquisitions

Open Source Issues in Mergers & Acquisitions In a merger or acquisition in which a technology company is the target, the target company’s software is often a material – and perhaps even the principal – asset of the deal. Often, this software was developed using...
Our Resources
Allegro Software Wishes You Happy Holidays

Allegro Software Wishes You Happy Holidays

Allegro Software wishes you a Happy Holidays and a wonderful New Year. We appreciate your support and look forward to serving you in 2024. Our team will be monitoring emails and inquiries throughout the holidays, please reach out if you have questions or need...

read more

Let’s Talk IoT Security

Implementing IoT device security can be a challenge. Let us help you by sharing our proven framework for integrating a proactive security approach into your design. Click the button below to schedule a one-on-one web conference to discuss your security needs.

Download Allegro’s Playbook

  • This field is for validation purposes and should be left unchanged.

Contact Us Today

  • This field is for validation purposes and should be left unchanged.