Author

Amit Hananel,  Medical Device Cybersecurity & Regulatory Affairs Expert Eurofins Medical Device Services

Body

After reviewing dozens of cybersecurity submissions and audit findings across FDA and EU MDR frameworks, one pattern stands out consistently, manufacturers that fail regulatory cybersecurity review do not fail because they ignored security, they fail because they treated it as a documentation exercise rather than a design discipline. 
What was once considered good engineering practice is now a regulatory obligation. Whether you are developing connected medical devices, Software as a Medical Device (SaMD), AI-enabled diagnostics, or networked IVD systems, regulators expect cybersecurity to be embedded throughout the entire product lifecycle. 
Today, cybersecurity is no longer simply about protecting data. It is about protecting patient safety. 

Many organisations still underestimate how dramatically the regulatory landscape has evolved. 
In the United States, FDA Section 524B requires manufacturers of cyber devices to provide cybersecurity documentation, maintain a Secure Product Development Framework (SPDF), establish vulnerability management processes, and submit a Software Bill of Materials (SBOM). 
A frequent point of confusion is the EU CRA (Cyber Resilience Act) Regulation 2024/2847, which sets horizontal cybersecurity requirements for products with digital elements across the EU market. Medical devices are explicitly excluded from its scope under Article 2- products regulated under MDR 2017/745 and IVDR 2017/746 remain governed by MDR Annex I GSPR 17 and IEC 81001-5-1, not the CRA. 
The consequence is straightforward:  
Insufficient cybersecurity evidence can delay approvals, trigger major audit findings, or lead to regulatory rejection by the FDA. Cybersecurity is no longer a recommendation. It is a compliance requirement. 

A recurring pattern across early-stage manufacturers is treating cybersecurity as a testing activity- penetration testing, fuzz testing, SAST, DAST, performed at the end of development rather than a design discipline applied from the start. 
Regulators increasingly expect a Secure-by-Design approach, where security considerations are embedded from the earliest stages of development. 
This includes: 

• Security requirements 
• Threat modelling 
• Secure architecture design 
• Secure coding practices 
• Verification testing 
• Post-market surveillance 

Security cannot be added at the end of development. It must be integrated from concept through SW life cycle to decommissioning.

At the heart of modern cybersecurity programmes is threat modelling. 
Frameworks such as STRIDE help manufacturers systematically identify vulnerabilities before products reach the market. 
Key threat categories include: 

• Spoofing 
• Tampering 
• Repudiation 
• Information Disclosure 
• Denial of Service 
• Elevation of Privilege 

“A Denial of Service attack on an ICU monitor suppressing alarms for eight minutes is not a cybersecurity event. It is a patient safety event. The technical category and the clinical consequence are the same incident.” 

The real value, however, lies in traceability. 

Every identified threat should be linked to: 

• A mitigation strategy 
• A security control 
• A verification test 
• Objective evidence demonstrating effectiveness 

This traceability is often one of the first areas regulators examine during cybersecurity assessments. 

If there is one cybersecurity activity every manufacturer should prioritise today, it is SBOM creation and maintenance. 
A Software Bill of Materials provides a machine-readable inventory of all software components, libraries, open-source packages, and third-party dependencies within a device. 
Without an SBOM, organisations cannot efficiently determine whether newly discovered vulnerabilities affect their products. 

An effective SBOM enables: 

• Faster vulnerability assessment 
• Improved incident response 
• Greater supply chain transparency 
• Regulatory compliance 
• More efficient software maintenance 

In today's environment, you cannot manage what you cannot see. 
A missing or incomplete SBOM is a Refuse-to-Accept criterion, FDA will return your submission without substantive review. Not a deficiency letter. A rejection before anyone reads your clinical data. 

Unlike conventional software vulnerabilities, which exist in code, AI vulnerabilities can exist in data, specifically in the integrity of the training dataset and the robustness of the model's decision boundary. This means your SBOM, your penetration test, and your SAST scan will not detect them. A separate, AI-specific security assessment is required  and regulators are beginning to mandate it. 

Two emerging attack categories are particularly important: 

1.Data Poisoning 
Manipulating training datasets to influence model behaviour and compromise performance. 
Data poisoning is recognised as a distinct threat class by both FDA and IMDRF. Unlike code vulnerabilities, a poisoned model can pass every standard validation test, overall accuracy metrics remain normal while behaviour on specific targeted inputs is compromised. This is why GMLP Principle 2 requires documented data authenticity and integrity controls across the training pipeline, and why dataset provenance is now a submission expectation rather than a research nicety. 

2.Adversarial Attacks 
Introducing subtle modifications to inputs that result in incorrect predictions or diagnoses. 
A pixel-level perturbation imperceptible to the human eye can flip a dermatology classifier's output from benign to malignant. No firewall catches it. No antivirus flags it. It is a threat that lives entirely inside the model's decision boundary. Finlayson et al. (Science, 2019) 
For healthcare products, these are not merely performance concerns. They represent genuine patient safety risks. 
As AI adoption continues to accelerate, manufacturers must begin treating model integrity and data integrity as core cybersecurity requirements.

One of the most significant regulatory shifts is the increased focus on post-market cybersecurity. 
Regulators now expect manufacturers to demonstrate how they will: 

• Monitor vulnerabilities 
• Assess emerging threats 
• Maintain SBOMs 
• Communicate security issues 
• Deploy patches 
• Operate a Vulnerability Disclosure Policy (VDP) 

A Vulnerability Disclosure Policy (VDP) is the documented, publicly accessible process through which security researchers and users can report vulnerabilities they discover in your device, including a contact mechanism, an acknowledgement commitment, and a coordinated disclosure timeline. Under FDA Section 524B a VDP is not optional: manufacturers of cyber devices must have one in place and referenced in their submission, and its absence is a Refuse-to-Accept criterion. 
A cybersecurity programme is no longer judged solely by the documentation submitted during certification. It is judged by how effectively an organisation responds to evolving threats once the product is on the market. 

Five Key Takeaways 

What manufacturers need to know to stay compliant and competitive:

1. FDA reviewers now check cybersecurity documentation before they read your clinical data. If the SBOM is missing, the submission comes back  regardless of how strong the clinical evidence is.
2. Secure-by-Design principles must be implemented from the earliest stages of development. 
3. The manufacturers who pass their first cybersecurity submission are the ones who built their SBOM on day one of development  not the week before submission.
4. AI systems require additional cybersecurity controls focused on data and model integrity.
5. Post-market vulnerability monitoring is just as important to conduct as pre-market testing. 

Get in touch with our experts