Medical device security risks are critical for patient safety, and the International Medical Device Regulators Forum (IMDRF) provides key guidance to address these challenges globally. Here's what you need to know:
- IMDRF's Role: A coalition of regulators from 10 regions, including the U.S., EU, and Canada, works to standardize medical device cybersecurity practices across the lifecycle.
- Key Documents: IMDRF's N60, N70, and N73 documents outline principles for secure device design, managing older devices, and software transparency through Software Bills of Materials (SBOMs).
- U.S. Impact: IMDRF guidance shapes FDA cybersecurity regulations, such as mandatory SBOMs and lifecycle-wide security obligations for "cyber devices."
- Total Product Lifecycle (TPLC): Security is addressed from design to end-of-support, with shared responsibilities between manufacturers, healthcare providers, and regulators.
Recent Developments in IMDRF Standards including Cybersecurity | Lawson Cline
sbb-itb-535baee
Key IMDRF Cybersecurity Guidance Documents
The International Medical Device Regulators Forum (IMDRF) has developed three key technical documents that together create a cybersecurity framework tailored for medical devices. Each document tackles a specific aspect of cybersecurity - general practices, managing older devices, and ensuring software transparency. These documents are designed to complement one another, forming a cohesive strategy for addressing security challenges in the medical device industry.
IMDRF N60: Principles and Practices for Medical Device Cybersecurity
Released on April 20, 2020, N60 serves as the cornerstone of IMDRF's cybersecurity guidance. It introduces standardized terms, defines the roles of stakeholders, and establishes cybersecurity risk management expectations across the Total Product Lifecycle (TPLC) [4]. This document aligns with the TPLC framework, covering security considerations from the development phase through post-market support.
N60 aims to unify expectations among global regulators, including the U.S. FDA, Health Canada, the European Commission, Japan's PMDA, Australia's TGA, and Brazil's ANVISA. While technically non-binding, many regulators build their own specific requirements on top of N60's guidelines. For U.S. manufacturers, this document sets the baseline for meeting cybersecurity compliance.
Although N60 lays the groundwork, it is complemented by N70, which focuses on the unique challenges posed by legacy devices.
IMDRF N70: Cybersecurity for Legacy Medical Devices
Finalized on April 11, 2023 [1], N70 addresses the complexities of securing legacy medical devices that can no longer be fully updated or patched. It introduces lifecycle concepts like "limited support" and "end-of-support" (EOS), offering a shared vocabulary for discussing a device's security status as it approaches the end of its operational life.
IMDRF highlights the risks:
"Cybersecurity incidents have rendered medical devices and hospital networks inoperable, disrupting the delivery of patient care across healthcare facilities worldwide." [1]
The guidance emphasizes shared accountability. Manufacturers are expected to clearly communicate support timelines, while healthcare delivery organizations must plan for compensatory measures when devices can no longer receive security updates. This shared responsibility model aligns with U.S. post-market requirements and supports global efforts to harmonize regulatory approaches.
IMDRF N73: Software Bill of Materials (SBOM) and Transparency
N73 shifts the focus to software transparency, addressing the challenges posed by medical device software that relies on external components like open-source libraries and third-party modules [5]. Without a clear inventory of these components, identifying vulnerabilities - especially after incidents like the Log4Shell disclosure - becomes a daunting task.
The document outlines best practices for creating, managing, and sharing Software Bills of Materials (SBOMs) throughout a device’s lifecycle. IMDRF explains:
"The SBOM is a resource which can be leveraged to improve cybersecurity risk management processes in both pre-market and post-market activities (i.e., the Total Product Lifecycle or TPLC)." [2]
An SBOM allows healthcare organizations to quickly determine whether a device in their inventory contains a newly disclosed vulnerability. This is becoming increasingly critical: by 2026, 35% of hospitals are expected to refuse medical devices that lack an SBOM, and 56% of hospitals already reject devices during procurement due to cybersecurity concerns [5]. The guidance also recommends pairing SBOMs with Vulnerability Exploitability eXchange (VEX) files to identify which vulnerabilities are exploitable in a specific device configuration. This reduces unnecessary triage efforts and enhances compliance with U.S. security standards.
Applying IMDRF Cybersecurity Principles Across the Device Lifecycle
IMDRF Medical Device Cybersecurity: Total Product Lifecycle (TPLC) Framework
Ensuring cybersecurity throughout a device's lifecycle is essential. The IMDRF emphasizes this through the Total Product Lifecycle (TPLC) framework, which addresses security from the design phase all the way to decommissioning.
Total Product Lifecycle (TPLC) Framework
The TPLC framework, based on IMDRF N60 guidelines, divides the lifecycle into four key phases: Development, Support, Limited Support, and End of Support (EOS). Each phase outlines specific roles for manufacturers and healthcare delivery organizations (HDOs). Christian Espinosa, Founder & CEO of Blue Goat Cyber, highlights the importance of this approach:
"The FDA and IMDRF both treat cybersecurity as a total product lifecycle obligation. It begins at design conception and does not end at clearance." [6]
This approach is especially critical given that 53% of networked medical devices have at least one known critical vulnerability [6]. Viewing cybersecurity as an ongoing responsibility rather than a one-time task is crucial for reducing risks.
Cybersecurity by Design During Development
During the development phase, manufacturers are required to follow a Secure Product Development Framework (SPDF). This structured process incorporates threat modeling, risk mitigation, and security testing from the outset. Threat modeling should address the device's specific vulnerabilities, like Bluetooth or Wi-Fi interfaces, and consider the clinical environments where the device will be used.
Development security must adhere to standards such as IEC 62443-4-1 (secure product development lifecycle) and IEC 81001-5-1 (health software security). Penetration testing should be conducted on production-equivalent builds rather than prototypes to ensure realistic results. Starting February 2026, the FDA will require cybersecurity to be integrated into the Quality Management System Regulation (QMSR), making security testing a mandatory part of design validation under ISO 13485:2016 Clause 7.3.7 [6].
Once the device hits the market, ongoing support and active monitoring are needed to maintain security.
Maintenance, Legacy Support, and EOS Planning
After launch, the Support phase focuses on monitoring for new vulnerabilities. Manufacturers must utilize resources like ICS-CERT and H-ISAC to identify threats and maintain a Coordinated Vulnerability Disclosure (CVD) process. Critical vulnerabilities should be addressed within 60 days, with customers notified within 30 days [6].
As devices age, challenges increase. When a critical software or firmware component reaches end-of-life, the device may enter a Limited Support phase. Manufacturers must notify HDOs 2–3 years before this transition and document any residual risks. They should also suggest compensating controls, such as network segmentation or firewall policies, to minimize exposure.
At EOS, the primary responsibility for security shifts to the HDOs. However, manufacturers may still need to fulfill certain post-market surveillance duties [7]. IMDRF N60 acknowledges the complexities of this stage:
"Clinical life may extend beyond EOS, where decommissioning could occur sometime after EOS if an HCP decides to continue using the device beyond EOS. It is known that in many cases, the clinical utility of a device exceeds its supportability." [7]
This phased approach ensures that cybersecurity remains a priority throughout the device's lifecycle, aligning with regulatory standards and safeguarding patient safety.
The table below outlines how responsibilities evolve across the TPLC phases:
| TPLC Phase | Manufacturer Tasks | HDO Tasks |
|---|---|---|
| Development | Implement SPDF, SBOM, and threat modeling | Provide feedback on clinical environment needs |
| Support | Monitor vulnerabilities; issue patches within 60 days | Apply patches; follow recommended safeguards |
| Limited Support | Notify HDOs 2–3 years in advance; document residual risks | Evaluate risks; plan for device replacement |
| End of Support | Provide lifecycle documentation; maintain CVD if needed | Assume primary security responsibility; apply compensating controls |
Stakeholder Roles and Responsibilities
The Total Product Lifecycle framework emphasizes that ensuring device cybersecurity is a shared undertaking. According to the IMDRF framework, this responsibility is divided among manufacturers, healthcare organizations, and regulators, with each group playing a specific but interconnected role.
Medical Device Manufacturers (MDMs)
MDMs hold the primary responsibility for cybersecurity, starting at the design phase and continuing throughout the device's lifecycle. Under Section 524B of the FD&C Act, manufacturers of "cyber devices" are required to establish and maintain processes that ensure their devices and associated systems are secure through vendor risk assessment solutions [3]. This includes submitting a formal postmarket monitoring plan, which must feature a Coordinated Vulnerability Disclosure (CVD) process, and providing a detailed Software Bill of Materials (SBOM). The SBOM must account for all commercial, open-source, and off-the-shelf software components [3].
"Section 524B(b)[4] of the FD&C Act requires that manufacturers of cyber devices provide a software bill of materials (SBOM) for the commercial, open-source, and off-the-shelf software components contained within the device." - FDA [3]
Failing to include complete cybersecurity documentation in 510(k) eSTAR submissions can result in a Technical Screening hold [3]. Once devices are in use, the responsibility for operational security shifts to healthcare delivery organizations.
Healthcare Delivery Organizations (HDOs)
After a device is deployed, HDOs take on a critical role in maintaining its operational security. Using information provided by manufacturers - especially SBOMs - they must actively monitor vulnerabilities within their device inventory and apply patches as they become available [3].
HDOs that implement centralized systems for managing SBOMs , such as on-demand cyber risk management platforms, are better equipped to respond quickly to emerging vulnerabilities. These systems enable near real-time cross-referencing of their inventory against known vulnerabilities. This proactive approach is increasingly expected, especially as HDOs assume the primary responsibility for security during the End of Support (EOS) phase. While manufacturers and HDOs focus on design and operational risks, regulators oversee compliance at all stages.
Regulators' Role in Cybersecurity Oversight
Regulators enforce cybersecurity standards by requiring specific documentation during the premarket review process. In the U.S., the FDA implements IMDRF-aligned principles through its statutory authority, while equivalent bodies such as the EU's MDCG and Korea's MFDS enforce similar standards within their regions [8].
The regulatory landscape is evolving toward continuous, lifecycle-wide accountability rather than a one-time premarket review [8]. According to an analysis of global regulatory practices:
"Regulatory approaches show definitional alignment but operational fragmentation at the interface between patient-safety vigilance and vulnerability-centric cybersecurity practice." - Saera Jung and Kihong Son [8]
The table below highlights how each stakeholder's responsibilities align with the IMDRF framework:
| Stakeholder | Primary Responsibility | Key Deliverable |
|---|---|---|
| MDM | Security by design and postmarket support | SBOM, patches, CVD plans |
| HDO | Operational security and risk management | Vulnerability tracking, patch application |
| Regulator | Standards alignment and enforcement | Premarket review, guidance issuance |
Putting IMDRF Cybersecurity Principles into Practice in U.S. Healthcare
Understanding the principles outlined by the International Medical Device Regulators Forum (IMDRF) is one thing; applying them to the complex world of U.S. healthcare is another. Bridging this gap requires translating IMDRF guidelines into actionable cybersecurity measures tailored to the healthcare environment.
Aligning Cybersecurity with Governance and Risk Management
For healthcare organizations in the U.S., the first step is to weave cybersecurity into their existing governance and risk management frameworks. A critical aspect of this involves treating security risk management as a distinct but interconnected process alongside clinical safety. According to the FDA, these two areas must operate in parallel but remain separate. Security risk management aligns with AAMI TIR57, while safety risk management follows ISO 14971 [10]. Mixing these processes can lead to compliance issues and unclear accountability.
"Security risk management for medical devices is described in the AAMI TIR57... which the FDA has recognized as a consensus standard." - J. David Giese, Partner at Innolitics [10]
Threat modeling is another essential tool in this process. Frameworks like STRIDE help organizations identify potential threats, map out attack vectors, and evaluate the impact of breaches, particularly for networked medical devices. These devices pose unique risks since a single vulnerability could potentially harm multiple patients simultaneously [10].
Once cybersecurity is embedded into governance, maintaining and updating a Software Bill of Materials (SBOM) becomes vital for tracking vulnerabilities in real-time.
Using SBOM for Vulnerability Management
IMDRF guidance emphasizes the importance of SBOMs in managing software vulnerabilities throughout a device's lifecycle. To stay ahead of threats, healthcare organizations must treat SBOMs as living documents, updated regularly to reflect the latest vulnerabilities.
Software Composition Analysis (SCA) plays a key role here. By analyzing software binaries, SCA identifies all third-party and open-source components within a device's software. This information feeds back into the SBOM, enabling cross-referencing with vulnerability databases in near real-time [9].
"FDA expects cybersecurity to be embedded within manufacturers' quality systems and reflected in premarket submissions when applicable." - Exponent [9]
The FDA has also reinforced the importance of SBOMs through its Compliance Program Manual (#7382.850), which took effect on February 2, 2026. This manual includes dedicated sections on cybersecurity, signaling a shift from SBOMs being merely documentation to becoming enforceable requirements during quality management inspections [9].
Centralizing Risk Assessments with Censinet RiskOps™
Fragmented inventories and dispersed risk data make consistent cybersecurity management a challenge for healthcare organizations. With devices from multiple vendors, intricate clinical interconnections, and siloed data, maintaining a unified cybersecurity strategy becomes increasingly difficult [9].
Centralized risk assessment tools, like Censinet RiskOps™, offer a solution. This platform aligns with IMDRF principles (N60, N70, and N73) to streamline compliance and improve patient safety. Censinet RiskOps™ consolidates third-party and enterprise risk assessments, SBOM-based vulnerability tracking, and cybersecurity benchmarking into a single platform. Its Censinet AI™ feature speeds up security assessments, allowing vendors to complete questionnaires in seconds while automatically summarizing evidence and identifying fourth-party risks.
For legacy devices covered under IMDRF N70, Censinet RiskOps™ provides a unified view of devices that may no longer receive manufacturer support. This capability enables organizations to implement and document compensatory controls consistently, ensuring ongoing security for older devices across their networks.
Conclusion
Medical device cybersecurity directly impacts patient safety. As the IMDRF highlights, "Cybersecurity incidents have rendered medical devices and hospital networks inoperable, disrupting the delivery of patient care across healthcare facilities worldwide." [1] This underscores the need for a structured and principled approach to managing these risks.
The IMDRF framework, which includes N60, N70, and N73, offers U.S. healthcare organizations a globally aligned foundation. These guidelines address the entire lifecycle of medical devices, from design to postmarket use, and clearly define the roles of manufacturers, healthcare providers, and regulators. This comprehensive approach ensures that both new and legacy devices are managed with cybersecurity in mind.
A key focus of the IMDRF guidance is shared responsibility and transparency. Practical steps, such as requiring SBOMs during procurement, implementing compensating controls for older devices, and maintaining separate yet interconnected safety and security processes, can significantly enhance device security. Tools like Censinet RiskOps™ simplify these efforts, helping organizations align their practices with IMDRF standards.
These principles also align cybersecurity with broader governance and risk management strategies, reinforcing their importance in safeguarding patient care. With resources like the FDA's eSTAR templates and expanded Congressional authority, these guidelines are poised to shape U.S. regulations for years to come. Healthcare organizations that integrate IMDRF principles into their governance structures will not only meet compliance requirements but also strengthen their overall resilience.
FAQs
How do N60, N70, and N73 fit together?
The IMDRF/CYBER WG/N60, N70, and N73 documents work together to create a cohesive approach to medical device cybersecurity.
- N60 lays out broad principles for managing cybersecurity throughout a product's life cycle. It also introduces concepts like legacy devices and the Software Bill of Materials (SBOM).
- N70 offers actionable strategies for handling legacy devices, ensuring they remain secure as technology evolves.
- N73 dives into the practicalities of implementing the SBOM, a key tool for transparency in software components and potential vulnerabilities.
These documents aim to standardize security measures across the industry. Tools like Censinet RiskOps further support this framework by streamlining risk management and providing benchmarking capabilities. Together, they help establish a more secure environment for medical devices.
What should an HDO do when a device reaches end of support?
When a medical device reaches its End of Support (EOS), the responsibility for its cybersecurity shifts entirely to the healthcare delivery organization (HDO). This change means manufacturers no longer provide updates or patches, leaving HDOs to take proactive steps to manage the risks. Here's what they should do:
- Perform regular risk assessments: Continuously evaluate whether the device can be safely used despite its unsupported status.
- Apply compensating controls: Introduce additional security measures or seek assistance from third-party experts to mitigate potential vulnerabilities.
- Evaluate decommissioning or replacement: If the risks outweigh the benefits, retiring or replacing the device might be the safest option.
Platforms like the Censinet RiskOps can help streamline these tasks, making it easier for HDOs to manage risks effectively.
What’s the fastest way to use an SBOM to find affected devices?
Keeping an up-to-date, searchable Software Bill of Materials (SBOM) is the fastest way to stay on top of vulnerabilities. When integrated with your asset inventory and vulnerability monitoring, this tool becomes incredibly powerful. By using machine-readable formats like CycloneDX, automated systems can instantly cross-check component identifiers (like pURLs) against vulnerability databases. This means you can pinpoint affected devices within minutes of a new CVE being announced. Tools like Censinet RiskOps™ make this even easier by streamlining the entire risk management process.
