Introduction

In a world where medical devices increasingly incorporate software and electronic functionalities, cybersecurity is no longer optional: it is a major regulatory requirement and a patient safety imperative.

Whether it's an infusion pump, a medical imaging system, diagnostic software, or an implantable device, whenever a software component is present, vulnerabilities may exist. The consequences of a security breach can be dramatic: theft of health data, alteration of device functionality, disruption of critical services, or even direct endangerment of patients.

Faced with these risks, regulatory authorities have tightened their requirements. The European MDR Regulation and the US FDA now require manufacturers to demonstrate that their devices integrate robust cybersecurity measures throughout their lifecycle – whether connected or not.

In this article, we break down the essential requirements and propose a practical approach for medical device manufacturers.

The Regulatory Framework in Brief

European Requirements (MDR)

Regulation (EU) 2017/745 imposes cybersecurity requirements in its Annex I, Section 17, which covers devices containing software.

Key points:

• Point 17.2: Software must be developed in accordance with the state of the art, including risk management and information security
• Point 17.4: Manufacturers must define necessary IT security measures, including protection against unauthorized access

The MDCG 2019-16 guidance details these requirements in four areas:

• Incorporate appropriate technological solutions to ensure cybersecurity
• Provide information on cybersecurity measures taken
• Maintain cybersecurity throughout the lifecycle
• Implement post-market surveillance to detect vulnerabilities

To implement these requirements: The IEC 81001-5-1 standard provides the operational framework with concrete processes for each development phase: how to perform security risk management, how to design a secure architecture, what security tests to perform, and how to manage vulnerabilities after commercialization.

US Requirements (FDA)

Section 524B of the Food, Drug and Cosmetic Act (FDA guidance June 2025) imposes requirements for devices containing software and capable of connecting (USB, Bluetooth, Wi-Fi...).

Mandatory premarket documentation:

• Threat model and security risk analysis
• Detailed security architecture
• Mandatory SBOM (CycloneDX or SPDX format) with end-of-support dates
• Security test reports:
  • Source code analysis to detect vulnerabilities
  • Penetration testing simulating real attacks
• Post-market vulnerability monitoring and management plan
• Demonstration that there are no uncontrolled critical vulnerabilities

Consequence: The FDA may refuse to accept incomplete submissions. Cybersecurity is now an integral part of demonstrating device safety.

Implementation: Adopt a secure development framework recognized by the FDA: AAMI SW96, IEC 81001-5-1, or ANSI/ISA 62443-4-1.

Key Standards and Technical Guidelines

Common EU and US Standards:

European Union Specific:

US Specific :

Now that the regulatory framework is established, let's see concretely how to structure your cybersecurity approach.

How to Structure Your Cybersecurity Approach

Risk Analysis and Threat Modeling

Objective: Identify threats specific to your device and define protective measures. The FDA guidance (June 2025) requires submission of complete threat modeling results in the premarket dossier.

STRIDE Methodology (most commonly used)

The STRIDE method structures threat identification into 6 categories:

• Spoofing: identity impersonation
• Tampering: data or code alteration
• Repudiation: inability to trace who did what
• Information Disclosure: unauthorized access to data
• Denial of Service: making the device unavailable
• Elevation of Privilege: obtaining elevated access rights

Approach: Identify assets to protect (patient data, critical functions), map attack surfaces (physical, network, software interfaces), apply STRIDE to each interface, then describe exploitation scenarios and their impact.

Example - Infusion Pump:

Threat: Flow rate modification via network interface
Consequence: Overdose → serious patient risk
Protection: Enhanced authentication + encryption + digital signature

Recommended tools: Microsoft Threat Modeling Tool or OWASP Threat Dragon.

Expected documentation: Flow diagrams, threat registry with unique identifiers, traceability threats → risks → controls → tests.

Security Architecture

Defense-in-depth principle: Your device must integrate multiple complementary layers of protection. If one layer is compromised, the others limit the attack's impact.

The six essential layers:

• Authentication: verify user identity (enhanced authentication for critical functions)
• Encryption: protect stored and transmitted data (current standards: AES-256, TLS 1.3)
• Access control: each user accesses only the functions necessary for their role
• Integrity: ensure critical data has not been modified (digital signatures)
• Detection: record security events to identify anomalies
• Isolation: separate critical from non-critical functions

Key point: Each security layer must be justified by your risk analysis and traceable to threats identified in your model. Authorities verify this consistency.

SBOM (Software Bill of Materials)

The SBOM is a comprehensive list of all software components in your device.

Mandatory content:

• Exact name and version of each component (e.g., "OpenSSL 3.0.7", not "OpenSSL 3.x")
• Vendor/publisher
• Software license
• Dependencies (including transitive)
• Cryptographic hash (SHA-256) for integrity verification

FDA-accepted formats:

• CycloneDX (JSON or XML format)
• SPDX (Software Package Data Exchange)

Critical importance: An incomplete or incorrectly formatted SBOM is the leading cause of FDA rejection. SBOMs in PDF or Excel format are automatically rejected.

Recommended tool: OWASP DependencyTrack for automatic generation and continuous vulnerability monitoring.

Security Testing

Objective: Demonstrate that your protective measures are effective.

Two mandatory types of testing:

• Automated testing: source code analysis and detection of known vulnerabilities (CVE) with each modification
• Penetration testing: simulation of realistic attacks by an external team specialized in MedTech (mandatory before FDA submission, then at regular intervals proportional to risk - typically annual post-market)

Required documentation: detailed protocols, test results, evidence of corrections and retests

Key point: Tests must be traceable to threats identified in your STRIDE model and to defined security controls.

Patch Management

Critical requirement: You must demonstrate that you have an operational process to rapidly correct vulnerabilities discovered after commercialization.

Mandatory elements:

• Defined response times
• Establish correction deadlines according to vulnerability criticality
  Example: critical vulnerability = immediate action, high vulnerability = planned correction
• Reference to CISA Known Exploited Vulnerabilities catalog
• Secure deployment mechanism
• Digitally signed updates
• Rollback mechanism in case of failure
• Regression testing before deployment

Communication:

• Coordinated vulnerability disclosure process
• User notification (Field Safety Notice if patient impact)
• Information to regulatory authorities according to criticality

Regulatory requirement: MDR and FDA require complete traceability of your corrective actions. Preserve deployment evidence for each applied patch.

Regulatory Documentation

The Cybersecurity Management Plan (CSMP) for FDA

For FDA submissions, you must provide a comprehensive cybersecurity management plan covering the device's entire lifecycle. This document structures your security approach in several key sections: risk management, security architecture, SBOM, threat modeling, controls and testing, patch management, incident response, training, third-party security, and supply chain.

Cybersecurity Annex for EU (MDR)

For CE marking, integrate cybersecurity into your technical documentation: ISO 14971 risk analysis, compliance with general safety and performance requirements (§17 Annex I MDR), references to MDCG 2019-16 guidance, and post-market surveillance plan.

Point of vigilance: The notified body will verify consistency between your risk analysis, security architecture, and test reports.

Post-Market: Continuous Surveillance

Vulnerability Surveillance

Regulatory obligation: Continuously monitor the emergence of new vulnerabilities affecting your software components.

Recommended process:

• Maintain an updated SBOM with each modification
• Use automated tools (DependencyTrack, Trivy) to detect CVEs
• Subscribe to alerts from ICS-CERT, CISA, ANSSI
• Define correction deadlines according to criticality (reference: CISA Known Exploited Vulnerabilities catalog)

Incident Management

Regulatory notification timelines:

• EU (MDR): "Without delay" to national authorities if serious incident affecting safety
• US (FDA): Follow incident notification procedures under 21 CFR Part 803 and 806
• CISA Coordination: 72h for critical infrastructure if active exploit or compromised data

Common Mistakes to Avoid

❌ Incomplete or incorrectly formatted SBOM → Use automated tools and CycloneDX or SPDX format
❌ Superficial threat modeling → Conduct a real STRIDE workshop with the technical team
❌ Insufficient security testing → External pentest + automated tests + complete documentation
❌ Untested patch management → Simulate emergency deployment before commercialization
❌ Generic documentation → Write specifically for your device

Conclusion

Medical device cybersecurity has become an unavoidable regulatory imperative. Manufacturers must demonstrate a rigorous and documented approach, from design to post-market surveillance.

Keys to success:

• Integrate cybersecurity from the design phase
• Automate testing and surveillance
• Document continuously
• Test patch management before commercialization
• Train your teams

Future trends: Requirements will continue to tighten: increasingly detailed SBOMs, shortened correction deadlines, mandatory threat intelligence. Beyond regulatory compliance, cybersecurity is becoming a commercial differentiator: hospitals and investors now scrutinize cybersecurity maturity when making decisions.

Ready to Secure Your Medical Device and Ensure Regulatory Compliance?

At Certeafiles, we support you:

• Structure your cybersecurity approach (threat modeling, SBOM, testing)
• Write your FDA and MDR documentation
• Prepare your audits and certifications

👉 Contact us for a free initial consultation and discover how Certeafiles can accelerate your time to market.