IMDRF Principles and Practices for Medical-device Cybersecurity

The guidance establishes a common international foundation

IMDRF N60 provides recommendations for medical-device cybersecurity before and after market release. It addresses manufacturers, healthcare providers, users, regulators, vulnerability finders and other stakeholders. N70 extends the principles to legacy devices, while N73 explains software bills of materials.

The documents support regulatory convergence but do not create a global approval or replace national and regional requirements. Their practical value is a shared vocabulary and lifecycle model that teams can map to the laws and guidance applicable in each market.

Cybersecurity is a shared responsibility with defined ownership

Manufacturers control product design, security capabilities, documentation, updates and support commitments. Healthcare delivery organisations control networks, access, asset management, local configuration and operational response. Users follow security instructions. Regulators set jurisdictional expectations, and researchers may identify vulnerabilities.

Shared responsibility must not become diluted responsibility. Define what each party owns, what information it needs, how concerns are reported, who coordinates action and what happens when another stakeholder cannot implement the preferred control.

Manage security through the total product lifecycle

Security begins with product concept and continues through architecture, implementation, verification, deployment, maintenance and retirement. Early decisions about connectivity, trust boundaries, update mechanisms, identity and third-party components determine what can be controlled later.

• Define security responsibilities, competence, policy and escalation paths.
• Translate intended use and operating environment into security requirements.
• Perform threat modelling and security risk analysis alongside safety risk management.
• Use secure development, review, configuration and supply-chain controls.
• Verify security controls and test realistic misuse and attack conditions.
• Monitor vulnerabilities, threats, exploitation, incidents and field performance.
• Provide authenticated updates, coordinated communications and recovery methods.
• Plan support periods, end of support and secure decommissioning.

The engineering foundation is covered in MTL-108 — Medical-device Cybersecurity and the role-specific responsibilities in MTL-213 — Cybersecurity Engineers in Medical-device Development.

Security risk and safety risk are connected but not identical

A vulnerability can affect confidentiality, integrity or availability and may create hazardous situations, compromise diagnosis or treatment, expose sensitive information or disrupt healthcare operations. Analyse the security exploit path and then determine its possible safety and performance consequences.

Traditional safety probability estimates may not fit an intelligent adversary whose capability and motivation change. Consider exploitability, exposure, required skill, existing controls, detectability, impact and threat intelligence. Feed resulting safety-related harms and risk controls into the device risk-management process.

Use MTL-105 — Medical-device Risk Management to maintain the connection between security scenarios, hazardous situations, harms, controls and residual risk.

Secure design reduces reliance on the operating environment

Define a security architecture with assets, trust boundaries, data flows, interfaces and assumptions. Apply defence in depth so failure of one control does not expose the whole system. Minimise privileges and attack surface, protect credentials and keys, validate inputs, secure data in transit and at rest, log relevant events and fail safely.

Document dependencies on hospital networks, cloud services, mobile platforms and user practices. Required environmental controls should be realistic, verifiable and clearly communicated.

Cybersecurity claims require objective evidence

Trace security requirements to architecture, implementation and verification. Evidence may include threat models, abuse cases, secure-code reviews, static and dynamic analysis, penetration testing, interface testing, cryptographic design review, dependency assessment and update-mechanism testing.

Testing should represent the released configuration and realistic deployment. Record scope, tools, tester independence, findings, severity, disposition, residual risk and retest. A penetration-test report alone does not demonstrate a secure lifecycle or adequate architecture.

Control every evaluated version through MTL-127 — Configuration and Change Management.

Information sharing enables coordinated action

Publish a vulnerability-disclosure route and define how reports will be acknowledged, assessed, remediated and communicated. Coordinate with researchers, customers, regulators and sector information-sharing organisations where appropriate. Protect sensitive technical details while providing enough information for affected parties to manage risk.

Security documentation should explain the supported environment, secure configuration, network and account requirements, logging, backup, update process, residual risks, support period and customer responsibilities. Communications should be timely, consistent and accessible to the people who must act.

An SBOM makes software dependencies visible and actionable

IMDRF N73 describes an SBOM as a formal inventory of software components and dependency information. It supports vulnerability identification, impact assessment, procurement, asset management and communication between manufacturers and healthcare providers.

• Define the component identity, supplier, version and relationship to the product.
• Cover proprietary, open-source and commercial third-party components as appropriate.
• Generate and verify the SBOM from the controlled build and release process.
• Keep it traceable to each supported device and software configuration.
• Monitor disclosed vulnerabilities and assess actual product exposure and exploitability.
• Provide the SBOM in a usable, interoperable format through a controlled delivery method.
• Protect sensitive information without making the inventory unusable to customers.

An SBOM is an information source, not proof that the components are secure. It must connect to supplier control, vulnerability monitoring, risk assessment and remediation.

Post-market security needs prepared decisions and response

Monitor vulnerability databases, supplier notifications, threat intelligence, complaints, incidents and researcher reports. Triage signals promptly. Determine affected products and versions, exploitability, clinical impact, existing mitigations and whether exploitation is occurring.

Choose action based on risk: communication, configuration guidance, compensating controls, software update, field corrective action or other measures. Validate remediation, assess unintended effects and decide whether reporting is required in each jurisdiction. Measure response effectiveness and feed lessons into future designs.

Integrate this work with MTL-111 — Post-market Support and regional guidance such as MTL-308 — FDA Cybersecurity in Medical Devices Guidance.

Legacy-device security is a managed transition, not a label

IMDRF N70 addresses devices that cannot reasonably be protected against current threats because of their design, available controls or support status. Age alone does not make a device legacy, and continued clinical usefulness does not remove cybersecurity risk.

Manufacturers and healthcare providers should identify affected products, reassess risk, implement feasible compensating controls, communicate limitations and plan transition. Options may include network segmentation, access restrictions, enhanced monitoring, reduced connectivity, replacement, withdrawal or controlled decommissioning.

Define support and end-of-support expectations before market release. Preserve essential information, safe data handling and service arrangements during transition. Avoid abrupt unsupported states that leave customers without realistic risk-control options.

Map the international principles to each market

IMDRF documents are not legislation. Regional authorities determine submission content, reporting, update and post-market obligations. Maintain a cross-reference showing how the organisation's cybersecurity lifecycle satisfies each applicable requirement and where market-specific activities differ.

For the EU interpretation, use MTL-315 — MDCG 2019-16 Medical-device Cybersecurity. Consider privacy separately but coordinate the controls using MTL-129 — Privacy and Data Protection by Design.

Common misconceptions

Practical cybersecurity checklist

• Are stakeholder responsibilities and communication routes explicit?
• Does the security plan cover concept through retirement?
• Are assets, data flows, interfaces, trust boundaries and assumptions documented?
• Are security threats connected to safety, performance and privacy consequences?
• Are controls traced to architecture, implementation and objective verification?
• Are third-party components and suppliers controlled?
• Is the SBOM accurate, configuration-specific and usable?
• Are vulnerability intake, triage, remediation and disclosure processes exercised?
• Can updates be delivered, authenticated, validated and recovered safely?
• Are support periods, legacy-device controls and end-of-support transitions planned?