How do manufacturers demonstrate the cybersecurity of their medical devices reliably across the entire product lifecycle?
We support manufacturers of connected and software-based medical devices in building an end-to-end cybersecurity evidence base: from threat modeling and the secure development lifecycle through the software bill of materials (SBOM) to post-market vulnerability monitoring. Under the Medical Device Regulation (EU) 2017/745, cybersecurity is not a separate discipline but part of the general safety and performance requirements. The real bottleneck is that the same threat analysis has to feed risk management, the technical documentation and the post-market system, rather than existing as an isolated document.
- MedTech
- IVD
Overview
What cybersecurity requirements do the MDR and FDA place on manufacturers?
Cybersecurity across the entire lifecycle · MDR (EU 2017/745), MDCG 2019-16, IEC 81001-5-1, IEC 62304
Last updated: 2026-06-13
Connected and software-based medical devices are an attack surface and a regulated product at the same time. The requirements are spread across several frameworks that demand the same evidence from different angles. The leverage points where building that evidence most often stalls:
- The MDR (EU 2017/745) does not address IT security separately: Annex I requires programmable electronic systems to be developed in line with the state of the art, including protection against unauthorized access. Cybersecurity is therefore part of the general safety and performance requirements, not an add-on document.
- The MDCG 2019-16 guidance specifies how these GSPR are demonstrated to the notified body: threat analysis, security requirements, verification and a plan for the post-market phase belong in the technical documentation.
- Cybersecurity and risk management to ISO 14971 have to be interlocked: security risks that can lead to patient harm feed into the product-related risk analysis. AAMI TIR57 describes the bridge between security and safety risk management.
- For the US market, the FD&C Act Section 524B requires, among other things, a plan for handling post-market vulnerabilities and a software bill of materials (SBOM) for cyber devices. Since October 2023, the FDA has rejected a premarket submission lacking these elements as incomplete (Refuse to Accept).
- The secure development lifecycle to IEC 81001-5-1 and the software lifecycle to IEC 62304 have to mesh, so that security activities attach to the software documentation that is required anyway instead of running in parallel.
Services
How we support you
Threat modeling & security risk analysis
Systematic threat analysis of the product and its interfaces, documented as a traceable threat model that feeds into risk management to ISO 14971 and the GSPR evidence under the MDR, forming the basis for every further cybersecurity demonstration.
Secure development lifecycle
Establishing a security lifecycle to IEC 81001-5-1, interlocked with the software lifecycle to IEC 62304, with defined security requirements, design measures and verification evidence for the technical documentation.
Learn more →SBOM management
Creating and maintaining a software bill of materials that captures all components, including open-source and third-party libraries, as the basis for vulnerability monitoring and as a mandatory element of the FDA submission under Section 524B.
Post-market cybersecurity
Building a process for monitoring new vulnerabilities, assessing their impact on your own product and remediating them in a coordinated way, linked to post-market surveillance and the reporting system under the MDR.
Learn more →Technical documentation cybersecurity
Consolidating the threat model, security requirements, verification evidence and post-market plan into a cybersecurity dossier ready for review per MDCG 2019-16 as part of the technical documentation.
Gap analysis & audit preparation
Target-actual comparison of the existing security evidence against the MDR GSPR, MDCG 2019-16 and the FDA requirements, with a prioritized action list ahead of the notified body audit or the FDA submission.
How we work together
What it comes down to
Cybersecurity for medical devices rarely fails because of a single measure. It fails because of the sequence and the missing interlocking. The starting point is the threat model: anyone who does not systematically capture threats and attack vectors early ends up deriving security requirements from gut feeling rather than from a traceable analysis. Two strands flow from the threat model: the security risks into risk management to ISO 14971, across the bridge that AAMI TIR57 describes, and the security requirements into the development process. Both have to come from the same source, otherwise the contradictions between the cybersecurity file and the risk analysis arise, and those are the first thing to surface in the notified body audit.
The second bottleneck lies after market launch. The SBOM is not a submission document but a living register: only the continuous reconciliation against newly disclosed vulnerabilities turns it into the evidence that the FD&C Act Section 524B and MDCG 2019-16 require. That is why we plan the post-market process while the technical documentation is being created, and link it to post-market surveillance and the reporting system under the MDR (EU 2017/745). This turns cybersecurity from an add-on chapter into a strand that feeds the same evidence the product has to provide anyway.
Our approach
Our approach
Step
Result
Scoping & gap analysis
Inventory of architecture, interfaces and existing documentation; prioritized gap list against the MDR GSPR, MDCG 2019-16 and FDA requirements.
Threat modeling
Documented threat model with identified threats, attack vectors and derived security requirements.
Security risk assessment
Security risks assessed and transferred into risk management to ISO 14971, with the bridge between security and safety per AAMI TIR57 established.
SBOM & security measures
Maintained software bill of materials, with design and verification measures implemented along IEC 81001-5-1 and IEC 62304.
Cybersecurity dossier
Review-ready cybersecurity documentation per MDCG 2019-16 as part of the technical documentation, prepared for the notified body or the FDA.
Post-market operation
Established process for vulnerability monitoring and coordinated remediation, linked to post-market surveillance and the reporting system.
Common pitfalls
Where projects commonly fail
Cybersecurity is maintained as a standalone document alongside risk management.
Security risks that can lead to patient harm have to feed into the product-related risk analysis to ISO 14971 in line with AAMI TIR57. A separate file creates contradictions that surface in the notified body audit.
The SBOM is created once for the submission and not maintained afterwards.
A software bill of materials only has value if it is continuously reconciled against new vulnerabilities; an outdated SBOM serves neither the purpose under the FD&C Act Section 524B nor the post-market monitoring under MDCG 2019-16.
The post-market part of cybersecurity is not planned until after market launch.
MDCG 2019-16 and Section 524B require a plan for handling post-market vulnerabilities before the submission. Submitting it late risks deficiency requests instead of a straightforward approval.
Open-source and third-party components are not captured systematically.
These components in particular are a frequent source of disclosed vulnerabilities; without a complete SBOM, you cannot demonstrate after a security advisory whether your own product is affected.
The security lifecycle runs in parallel with the software lifecycle to IEC 62304 instead of being interlocked with it.
If security requirements are not tied to the software requirements and tests that are required anyway, duplicate documentation and gaps in verification result.
FAQ
Frequently asked questions
Sources
- Regulation (EU) 2017/745 (MDR), primary text, Annex I (GSPR, programmable electronic systems)
- Regulation (EU) 2017/746 (IVDR), primary text, general safety and performance requirements
- MDCG 2019-16, Guidance on Cybersecurity for medical devices
- IEC 81001-5-1, IEC 62304, IEC 62443, ISO 14971, AAMI TIR57
- FD&C Act Section 524B (Ensuring Cybersecurity of Devices)
- https://theentourage.de/clinical-medical-affairs/cybersecurity-embedded-systems/ (existing page content, revised)
Life Science Journal
Regulatory updates, straight to your inbox.
New requirements, authority decisions and practice notes. Once a month, unsubscribe any time.
Case Studies
What this looks like in practice
Related insights
All insights →Regulations & standards considered
- EU 2017/745 (MDR)
- MDR Annex I (General Safety and Performance Requirements, GSPR)
- EU 2017/746 (IVDR)
- MDCG 2019-16 (Guidance on Cybersecurity for medical devices)
- IEC 81001-5-1 (security in the lifecycle of health software)
- IEC 62304 (software lifecycle for medical devices)
- IEC 62443 (security for industrial automation and control systems)
- ISO 14971 (risk management)
- AAMI TIR57 (Principles for medical device security, risk management)
- FD&C Act Section 524B (Cyber Devices, USA)
Related topics
Risk Management →
Transfer security risks into the risk analysis to ISO 14971
Design Controls →
Anchor security requirements in the development process
Post-Market Surveillance →
Link vulnerability monitoring to PMS and the reporting system
MDR Consulting →
Cybersecurity as part of the GSPR evidence under EU 2017/745
Have a concrete project?
Briefly outline your situation. We'll respond with an initial assessment, usually within one business day.
Prefer direct? +49 89 4161170-0
info@theentourage.de
- Reply usually within one working day
- 4 offices: DE · CH · IT · US
- 100% life sciences