//EU MDR MEDICAL DEVICE CYBERSECURITY
Meet Your EU MDR Cybersecurity Obligations — Without Slowing Down Your Path to Market
The EU Medical Device Regulation (MDR 2017/745) and In Vitro Diagnostic Regulation (IVDR 2017/746) place significant cybersecurity obligations on medical device manufacturers. Demonstrating state-of-the-art cybersecurity is a mandatory requirement — not an option — for any connected, software-enabled, or data-processing device entering the EU market.
Periculo provides specialist cybersecurity support to medical device manufacturers, giving you the technical evidence, documentation, and expert guidance your Notified Body needs to assess your cybersecurity compliance.
We don’t handle your CE Marking process — we handle the cybersecurity side of it, thoroughly.
Why EU MDR Cybersecurity Compliance Is Non-Negotiable
MDR Annex I General Safety and Performance Requirements (GSPRs) set out specific cybersecurity obligations for software-enabled medical devices:
GSPR 17.2
Software must be developed and manufactured in accordance with the state of the art, taking into account the principles of development lifecycle, risk management including information security, verification and validation.
GSPR 17.4
Manufacturers must set out minimum requirements for hardware, IT network characteristics, and IT security measures, including protection against unauthorised access, necessary to run the software as intended.
GSPR 23.4
Instructions for use must contain cybersecurity-relevant information for users.
Notified Bodies are increasingly rigorous in assessing cybersecurity evidence. Gaps in your technical documentation, risk management file, or post-market surveillance plan are a common cause of delays and non-conformities during conformity assessment.
CONTENTS
What is EU MDR
The European Medical Device Regulation (EU) 2017/745 (EU MDR)
Why EU MDR Compliance Matters
Market Access
Without a valid CE Mark under EU MDR, your device cannot be sold or used within the EU.
Patient Safety & Trust
It ensures that cybersecurity risks are mitigated, protecting patients from device malfunctions or data theft.
GSPR (General Safety and Performance Requirements)
Adhering to the latest GSPR (General Safety and Performance Requirements) shields your organisation from heavy fines and legal action resulting from non-compliance.
Competitive Edge
Demonstrating "State-of-the-Art" security builds immediate trust with hospital IT procurement teams and clinicians.
What is IEC 81001-5-1 Medical Software Security?
EN IEC 81001-5-1 is the international standard for the lifecycle management of health software.
EN IEC 81001-5-1 is the international "State-of-the-Art" standard for the lifecycle management of health software. While ISO 13485 focuses on quality and IEC 62304 on software processes, IEC 81001-5-1 specifically addresses cybersecurity activities.
Secure-by-Design
Integrating security requirements from the initial concept.
Vulnerability Handling
Section 524B requires manufacturers making premarket submissions for cyber devices to demonstrate a reasonable assurance that the device and related systems are cybersecure. This is a statutory requirement, and non-compliance can result in denial of market authorisation, independent of other safety and effectiveness considerations.
Software Configuration
Ensuring the software environment remains stable and protected against external threats.
Under EU MDR, following this standard is the primary way to demonstrate compliance with cybersecurity mandates.
What is Post-Market Cybersecurity Surveillance?
Post-Market Cybersecurity Surveillance (PMCS)
Post-Market Cybersecurity Surveillance (PMCS) is the continuous process of monitoring your device for new threats after it is deployed. As part of your Post-Market Clinical Follow-up
Active Monitoring
Tracking new CVEs (Common Vulnerabilities and Exposures) that could affect your device’s OS or libraries.
Incident Response
Having a plan to deploy "security patches" or "hotfixes" before a vulnerability is exploited.
Regulatory Reporting
Notifying authorities and users of significant cyber risks to maintain the device's high level of safety over time.
How It Works
1. Discovery Call
We start by understanding your device, your submission timeline, and where you currently stand on cybersecurity documentation.
2. Gap Assessment
We map your current position against EU MDR requirements and produce a clear, prioritised list of what needs to be done. You'll know exactly what's missing and what it will take to fix it.
3. Documentation & Remediation
We get to work. Depending on your needs, this means threat modelling, SBOM development, policy drafting, architecture review, or the full package. We work to your timeline, not ours.
4. Submission Support
We review your final submission documentation, flag any remaining risk, and make sure what goes to the FDA is as strong as it can be. If Q-Sub feedback comes back, we help you respond.
Ready to Start Your ISO 42001 Journey?
Book Your Discovery Call
EU MDR rejections cost time you don't have and money you shouldn't be spending. Most of the manufacturers we speak to have left cybersecurity too late, and are scrambling to catch up.
If your submission window is approaching, start the conversation now.
FAQ’s
If your device contains software, is software itself (SaMD), or features any form of electronic connectivity (Bluetooth, Wi-Fi, Cloud), it must meet the General Safety and Performance Requirements (GSPR) outlined in Annex I. Specifically, GSPR 17.2 mandates that devices be resilient against unauthorised access and "state-of-the-art" security threats.
As of 2026, EN IEC 81001-5-1 is recognised by Notified Bodies as the primary standard for demonstrating a secure software lifecycle. While IEC 62304 covers general software safety, IEC 81001-5-1 adds specific requirements for threat modelling, vulnerability testing, and secure-by-design principles.
If your device uses AI, it must comply with both the EU MDR and the EU AI Act. The AI Act introduces additional requirements for "Cyber Resilience," requiring manufacturers to protect AI models against "adversarial attacks" (attempts to manipulate the AI’s output) and data poisoning.
While the term "SBOM" isn't explicitly in the MDR text, Notified Bodies and hospital procurement teams now require one under GSPR 17.4. An SBOM provides transparency into third-party libraries and open-source components, allowing for faster vulnerability management and risk mitigation.
Under the MDR, cybersecurity is a continuous process. You must actively monitor for new CVEs (Common Vulnerabilities and Exposures) affecting your device's components. If a "serious incident" or a high-risk vulnerability is discovered, it must be reported to the relevant authorities and users—often within 72 hours for critical threats.
Legacy software (originally certified under the MDD) must still be brought up to "state-of-the-art" security standards if it is transitioning to an MDR certificate. This usually involves a Gap Analysis to determine if patches or architectural "wrappers" are needed to meet modern encryption and access control requirements.
Manufacturers must register their devices in the EUDAMED database. While specific vulnerability details aren't usually public, summary information regarding the device’s safety and clinical performance (SSCP) may include high-level statements about its cybersecurity profile and IT environment requirements.
Latest Insights
Threat Advisory: Weaponisation of Anthropic's...
Introduction: The Emergence of AI-Powered Cyber Threats In early 2026, a sophisticated cyber intrusion targeting the Mex...
AI Security Threat Series: Model Inversion
Extracting secrets from an AI that was never meant to share them A deployed AI model does not hand over its training dat...
Weekly Round-Up Issue 15
This week's round-up arrives against a backdrop of significant cyber, regulatory and assurance activity affecting health...
MHRA SaMD Classification for Agentic AI: Is Y...
I have spent the better part of a decade navigating the intersection of cybersecurity and regulated industries, from the...
LiteLLM Supply Chain Attack: The $10 Billion ...
In our original post from 27 March, we covered the initial details of the LiteLLM supply chain compromise: the affected ...
AI Security Threat Series: Data Poisoning
Corrupting an AI before it ever goes live Most AI attacks happen at the point of use. Data poisoning happens much earlie...
NHS Clinical Safety and AI Agents: What DCB01...
I've spent the better part of a decade in cybersecurity, working with digital health organisations and later across the ...
Red Teaming the Microsoft Agent Governance To...
I have spent the better part of a decade in the trenches of cybersecurity, moving from the high-stakes world of NHS digi...