Cybersecurity for Medical Devices - What Do You Follow?

[RA_QA_Expert]

Hello,
For manufacturers placing medical devices on the EU market, MDR (EU) 2017/745 Annex I (e.g. 17.2, 17.4, 18.8) requires "state-of-the-art" cybersecurity — but what does that actually mean in practice?

I’m looking to clarify which technical standards and guidance are considered essential or expected by Notified Bodies. Specifically:

• For cyber risk management: is ISO 14971 enough, or should we integrate AAMI TIR57, TIR97, or others?
• For secure design: what’s the role of IEC 81001-5-1, IEC 62443-4-1/4-2, NIST CSF, etc.?
• How relevant are MDCG 2019-16 and IMDRF N60 in current EU reviews?
• What cybersecurity documentation is typically expected during conformity assessment?

We’re building an internal framework for cybersecurity-by-design and would appreciate any practical insights or shared experiences — especially from recent audits or submissions.

Thanks in advance!

 

[RA-QA&Cyber]

Hello,
For manufacturers placing medical devices on the EU market, MDR (EU) 2017/745 Annex I (e.g. 17.2, 17.4, 18.8) requires "state-of-the-art" cybersecurity — but what does that actually mean in practice?

I’m looking to clarify which technical standards and guidance are considered essential or expected by Notified Bodies. Specifically:

• For cyber risk management: is ISO 14971 enough, or should we integrate AAMI TIR57, TIR97, or others?
• For secure design: what’s the role of IEC 81001-5-1, IEC 62443-4-1/4-2, NIST CSF, etc.?
• How relevant are MDCG 2019-16 and IMDRF N60 in current EU reviews?
• What cybersecurity documentation is typically expected during conformity assessment?

We’re building an internal framework for cybersecurity-by-design and would appreciate any practical insights or shared experiences — especially from recent audits or submissions.

Thanks in advance!

For cyber risk management, ISO 14971 is necessary but not sufficient on its own. AAMI TIR57 is widely recognized for guiding threat modeling and security specific risk analysis, while AAMI TIR97 adds valuable direction for managing legacy systems and security update planning.

Regarding secure design and development, IEC 81001-5-1 has become a key reference particularly for software in medical devices and standalone SaMD and is explicitly mentioned in MDCG 2019-16. It offers detailed technical and process requirements for managing cybersecurity in health software. IEC 62443-4-1 and 4-2 are also helpful, especially for networked or connected medical devices, providing structured guidance on secure product lifecycle processes and technical requirements. While NIST CSF or NIST SP 800-53 are not mandatory, they are often used to supplement and demonstrate a mature cybersecurity posture.

In terms of documentation, Notified Bodies typically expect a cybersecurity specific risk analysis, a detailed threat model (e.g., using STRIDE or a similar methodology), and documentation of the device’s security architecture and controls. Other expected documents include a Software Bill of Materials (SBOM) with a plan for vulnerability disclosure and patching, penetration and vulnerability test reports (especially for networked or connected devices), post-market cybersecurity surveillance procedures, and a traceability matrix mapping design controls to IEC 81001-5-1 or equivalent requirements.

MDCG 2019-16 is still highly relevant and is often cited during conformity assessments, particularly for software-based medical devices. IMDRF N60 is becoming more influential and can be helpful for manufacturers aligning their practices with both EU and international expectations.

 

[Ed Panek]

From ChatGPT model 4.0. This is the paid version.

MDR Annex I (especially sections like 17.2, 17.4, and 18.8) sets high-level cybersecurity expectations but doesn’t spell out exactly what technical standards are “state-of-the-art.” In practice, Notified Bodies expect manufacturers to demonstrate a comprehensive, proactive, and standards-based approach to cybersecurity. Here’s how that typically breaks down

1. Cyber Risk Management:

• ISO 14971 is foundational, but not sufficient on its own for cybersecurity.
• AAMI TIR57 (“Principles for medical device security risk management”) is considered essential by many Notified Bodies. It contextualizes how to apply ISO 14971 for security (not just safety) risks.
• AAMI TIR97 builds on TIR57 and helps bridge clinical context and cybersecurity — useful especially if your device connects to hospital networks or cloud services.
• Recommended approach: Use ISO 14971 as your base, then integrate TIR57 for security-specific processes. TIR97 is valuable, particularly for risk controls and residual risk justification

2. Secure Design Standards

• IEC 81001-5-1:2021 (health software—security) is becoming the go-to standard for demonstrating compliance with Annex I cybersecurity requirements. Notified Bodies are increasingly expecting its use, especially for software-heavy devices.
• IEC 62443-4-1 (secure development lifecycle) and 62443-4-2 (technical requirements) are highly relevant for network-connected or embedded systems.
• NIST Cybersecurity Framework (CSF) and NIST SP 800-53/800-82 offer robust guidance, especially if you’re designing systems with broader infrastructure touchpoints—but they are supplemental in the EU context.
• Recommended approach:
  • IEC 81001-5-1 as your primary design/control standard.
  • Integrate parts of IEC 62443 where relevant (especially if your product interfaces with industrial or hospital systems).
  • Reference NIST CSF to show maturity in governance and security operations, especially for cloud or post-market elements.

3. MDCG & IMDRF Guidance:

• MDCG 2019-16 is critical. It outlines how cybersecurity should be handled in the MDR context and maps security to Annex I.
  • It is often directly referenced by Notified Bodies during conformity assessments.
• 
  
• IMDRF N60 (cybersecurity for legacy medical devices) is useful but less directly applicable unless you’re maintaining older products on the market. It can still help frame end-of-life support policies.
• Recommended approach: Treat MDCG 2019-16 as mandatory reading.

• ChatGPT-4 can see and understand images, while ChatGPT-3.5 can only process plain text input.
• ChatGPT-4 has more than ten times the number of parameters compared to ChatGPT-3.5, which means it can process more data and generate more human-like responses.
• ChatGPT-4 is 82% less likely to respond when prompts are technically not allowed, and it’s 60% less likely to fabricate facts.

 

[Dave T]

For cyber risk management, ISO 14971 is necessary but not sufficient on its own. AAMI TIR57 is widely recognized for guiding threat modeling and security specific risk analysis, while AAMI TIR97 adds valuable direction for managing legacy systems and security update planning.

Regarding secure design and development, IEC 81001-5-1 has become a key reference particularly for software in medical devices and standalone SaMD and is explicitly mentioned in MDCG 2019-16. It offers detailed technical and process requirements for managing cybersecurity in health software. IEC 62443-4-1 and 4-2 are also helpful, especially for networked or connected medical devices, providing structured guidance on secure product lifecycle processes and technical requirements. While NIST CSF or NIST SP 800-53 are not mandatory, they are often used to supplement and demonstrate a mature cybersecurity posture.

In terms of documentation, Notified Bodies typically expect a cybersecurity specific risk analysis, a detailed threat model (e.g., using STRIDE or a similar methodology), and documentation of the device’s security architecture and controls. Other expected documents include a Software Bill of Materials (SBOM) with a plan for vulnerability disclosure and patching, penetration and vulnerability test reports (especially for networked or connected devices), post-market cybersecurity surveillance procedures, and a traceability matrix mapping design controls to IEC 81001-5-1 or equivalent requirements.

MDCG 2019-16 is still highly relevant and is often cited during conformity assessments, particularly for software-based medical devices. IMDRF N60 is becoming more influential and can be helpful for manufacturers aligning their practices with both EU and international expectations.

I'd echo all those - we use IEC 81001-5-1 for a secure lifecycle in addition to IEC 62304

ISO 14971 alleges that it covers cyber-sec (see TR 24971 Annex F) but it doesn't fit terribly well and evaluating 'damage to property' is always difficult. AAMI TIR 57 adds "or reduction in effectiveness, or breach of data and systems security" to the definition of harm which makes things a little easier. You likely want to use CVSS for evaluating security risk and feed that into the standard 14971 assessment.

One additional thing I'd suggest is downloading the FDAs eSTAR template. If you begin the describe your device at the start of the form, it will tailor the form to your 'submission'. The cyber-sec section then guides you through what documents the FDA would expect to see for your device. Depending who your NB is, if you comply with the FDA's expectations, you will be pretty close, if not all the way there to EU/UK compliance. The FDA are slightly ahead of the curve with their cyber-sec requirements with the added benefit that they're often a lot clearer.