Most medical device manufacturers still treat cybersecurity documentation as a software appendix. In 2026, that approach is not just an MDR liability, it is a cross-regulatory exposure across at least three simultaneous frameworks.
Connected medical devices now sit at the intersection of EU MDR Annex I GSPR requirements, the EU Cyber Resilience Act (CRA, Regulation 2024/2847) which entered into force December 10, 2024, and the Radio Equipment Directive cybersecurity requirements which became mandatory August 1, 2025. Your device may be exempt from the CRA. Your ecosystem, companion apps, cloud services, and update infrastructure not classified as medical devices, is not. The exemption is narrower than most manufacturers assume.
What we are seeing across global submissions is that cybersecurity deficiencies are not because a manufacturer lacks technical controls, they are because regulatory teams cannot demonstrate how cybersecurity risk management connects coherently across patient safety, software lifecycle controls, post-market surveillance, and the expanding web of overlapping obligations that connected devices now carry. That documentation and governance gap is widening and notified bodies are increasingly structured to find it.
Notified bodies are no longer reviewing cybersecurity as a narrow IT topic. They are evaluating whether manufacturers have operationalized cybersecurity across the entire product lifecycle, from design controls through post-market monitoring. For many regulatory teams, that shift is exposing gaps in documentation ownership, cross-functional coordination, and technical file readiness.
At RegDesk, we increasingly see cybersecurity-related questions appear earlier in MDR review cycles, especially for connected devices, SaMD products, AI-enabled systems, and hospital-integrated technologies. In practice, many delays stem less from the existence of cyber risks and more from inconsistent evidence linking those risks to MDR General Safety and Performance Requirements (GSPRs).
For regulatory teams, the challenge now is not simply understanding cybersecurity guidance. It is building a submission strategy that proves cybersecurity maturity in a way notified bodies can evaluate efficiently.
Why MDR Cybersecurity Reviews Are Becoming More Intensive
The regulatory environment changed faster than many manufacturers anticipated.
Five years ago, cybersecurity reviews often focused narrowly on software validation or basic network protection. Today, regulators expect manufacturers to demonstrate continuous cybersecurity governance across the full device lifecycle.
Several trends are driving that shift:
| Trend | Regulatory Impact |
|---|---|
| Increase in connected medical devices | Expanded attack surface and higher patient safety risk |
| AI-enabled and cloud-connected systems | Greater scrutiny of software architecture and data integrity |
| Ransomware attacks on healthcare systems | Increased focus on operational resilience |
| Remote patient monitoring growth | More concern about authentication and secure data transmission |
| Lifecycle software updates | Greater emphasis on post-market cybersecurity management |
| EU AI Act (Regulation EU 2024/1689) intersection | MDCG 2025-6 (June 2025) clarifies how MDR/IVDR and AI Act obligations interact for high-risk AI-enabled devices, with most AIA obligations applying from August 2, 2026 |
| EU Cyber Resilience Act in force | CRA vulnerability and incident reporting requirements take effect September 11, 2026; full SBOM and remaining requirements December 11, 2027. |
| EU Action Plan on Cybersecurity for hospitals | Launched January 2025, the European Commission’s Action Plan established a pan-European Cybersecurity Support Centre covering connected medical devices |
The consequence of these intersecting frameworks is not just additional documentation. It is a fundamental shift in where cybersecurity accountability sits organizationally. The proposed MDR revision published in December 2025 explicitly integrates cybersecurity into the GSPRs and proposes new obligations to report actively exploited vulnerabilities and severe cyber incidents to Computer Security Incident Response Teams (CSIRTs) and ENISA bringing MDR reporting obligations closer to CRA-style requirements. Manufacturers who are planning their cybersecurity documentation strategy around the current GSPR text are planning for a framework that the Commission has already signaled it intends to strengthen. Under MDR, cybersecurity is fundamentally treated as a patient safety issue; not merely an IT compliance requirement.
That distinction is important because once cybersecurity becomes tied to patient safety, it automatically intersects with:
- ISO 14971 risk management
- Clinical performance
- Software lifecycle validation
- CAPA processes
- PMS and vigilance obligations
- Design controls
This is where many submissions begin to struggle.
In several MDR reviews we have observed, manufacturers provided strong technical cybersecurity testing but failed to clearly map those controls back to specific GSPR requirements or residual patient safety risks. Reviewers increasingly expect traceability across the entire documentation set.
What MDR Actually Requires for Cybersecurity Compliance
One of the biggest misconceptions among manufacturers is that MDR contains a dedicated cybersecurity section. It does not.
Instead, cybersecurity expectations are embedded throughout the regulation.
The most important requirements appear within Annex I General Safety and Performance Requirements (GSPRs), particularly around:
- Protection against unauthorized access
- Data integrity and reliability
- Repeatability and software performance
- Risk reduction
- Device interoperability
- Protection against reasonably foreseeable misuse
Two precision points that matter for submissions in 2026:
First, MDR Annex IX, Chapter I, Section 4.3 requires manufacturers to inform their notified body of any planned change that could affect conformity. For Class IIa, IIb, and III devices, the notified body must assess significant changes before implementation. For cybersecurity patches specifically, MDCG 2020-3 Appendix 2, Section 4 lists criteria for when a software change is “significant” and requires notified body approval versus when it can be managed under the manufacturer’s own quality system. Patch management governance is not a quality team decision alone, it is a regulatory decision that must be documented and traceable.
Second, notified bodies now expect EN IEC 81001-5-1:2022 as the de facto authoritative evidence for cybersecurity requirements under MDR/IVDR Annex I Sections 17.2 and 17.4. Alternative implementation paths are possible but must be documented and justified. If your submission relies on MDCG 2019-16 without mapping to IEC 81001-5-1, expect questions
For connected and software-driven devices, notified bodies increasingly expect cybersecurity evidence to appear across multiple sections of the technical documentation file rather than in a standalone summary document.
Key MDR Cybersecurity Areas Regulatory Teams Must Address
| MDR Area | What Reviewers Expect |
|---|---|
| Risk Management | Cyber threats integrated into ISO 14971 processes |
| Software Lifecycle | Secure development and maintenance controls |
| Clinical Evaluation | Assessment of cybersecurity impact on safety/performance |
| PMS | Monitoring vulnerabilities and cybersecurity incidents |
| CAPA | Defined remediation and update processes |
| Technical Documentation | Clear traceability between threats, controls, and residual risk |
The practical challenge is that cybersecurity documentation often sits across engineering, software, quality, and regulatory teams. When ownership is fragmented, submissions become inconsistent.
That operational issue is now one of the biggest causes of cybersecurity-related review delays.
The Standards Regulatory Teams Need to Understand Now
Many manufacturers still rely heavily on IEC 62304 alone when preparing software documentation. Increasingly, that is no longer sufficient.
Notified bodies and global regulators are placing greater emphasis on secure product development lifecycle expectations, particularly through IEC 81001-5-1.
The Most Important Cybersecurity Standards and Guidance
| Standard / Guidance | Status | Why It Matters in 2026 |
|---|---|---|
| IEC 81001-5-1 | Current | De facto authoritative standard for cybersecurity evidence under MDR/IVDR Annex I, notified bodies expect this, not just IEC 62304 |
| IEC 62304 | Current | Governs software lifecycle; now extended by IEC 81001-5-1 security activities |
| ISO 14971 | Current | Connects cybersecurity threats to patient safety risk management |
| MDCG 2019-16 | Current (Rev.1) | Primary EU cybersecurity guidance — ensure you are using the most current revision |
| MDCG 2020-3 | Current | Significant changes regarding software qualification |
| MDCG 2025-6 | June 2025 | Governs significant software changes Appendix 2 Section 4 determines when patches require notified body assessment |
| EU AI Act (2024/1689) | Most obligations Aug 2026 | High-risk AI medical devices face additional cybersecurity, bias mitigation, and transparency obligations. MDCG 2025-6 clarifies the MDR/AIA interface |
| Radio Equipment Directive cybersecurity | Mandatory Aug 2025 | Articles 3.3(d)(e)(f) cybersecurity requirements mandatory for internet-connected and radio-connected devices from August 1, 2025 |
| FDA Section 524B / FD&C Act | In force Dec 2024 | SBOM and vulnerability handling become the CRA-mandated state of the art baseline. Vulnerability/incident reporting active September 2026; full SBOM requirements December 2027 |
The convergence point that matters most for Regulatory Executives making infrastructure decisions: for most networked medical devices, CRA obligations apply via the MDR, avoiding double regulation, but the CRA’s substantive requirements around SBOM, vulnerability handling, and security updates become the operational standard manufacturers must meet. Building cybersecurity documentation that satisfies MDR GSPR requirements while ignoring CRA “state of the art” expectations is building to a standard that regulators and notified bodies have already moved beyond.
Although MDR and FDA cybersecurity frameworks are structured differently, both increasingly emphasize:
- Secure-by-design development
- Continuous vulnerability management
- Software transparency
- Post-market monitoring
- Lifecycle cybersecurity governance
That convergence creates both a challenge and an opportunity.
Manufacturers that build region-specific cybersecurity documentation separately often duplicate work unnecessarily. The companies moving fastest are creating harmonized cybersecurity evidence packages that can support multiple markets simultaneously.
What We See in Practice Across MDR Submissions
One recurring pattern we see is that manufacturers frequently over-focus on penetration testing reports while under-investing in cybersecurity traceability.
A penetration test alone rarely satisfies reviewers.
Notified bodies increasingly want to see:
- How threats were identified
- How risks were prioritized
- Why certain controls were selected
- How residual risks were evaluated
- How vulnerabilities will be monitored post-market
In several recent software-heavy submissions, we observed reviewers asking more detailed questions about:
- Software update governance
- Vulnerability disclosure procedures
- Open-source software management
- Authentication controls
- SBOM documentation
- Patch deployment responsibilities
SBOM has moved from a best practice to an expectation that requires specific handling.
The FDA’s updated June 2025 final cybersecurity guidance clarifies that for “cyber devices,” SBOMs are legally mandatory under Section 524B(b)(3). For all other software-containing devices, SBOMs are strongly recommended. The February 2026 guidance update reinforced and expanded these expectations. In the EU, while MDR does not yet explicitly mandate SBOMs, MDCG 2019-16 recommends them and the CRA explicitly requires them, establishing SBOM maintenance as state of the art under MDR Annex I Section 17.2.
For regulatory leaders, this means SBOM is no longer a software engineering deliverable that gets attached to a submission. It is a living regulatory document that must be current, machine-readable, and maintained throughout the product lifecycle. The governance question, who owns SBOM maintenance, how updates are tracked, and how changes feed back into the risk management file, is now a regulatory operations question, not just a software team process.
Along with these governance questions that need to be addressed, timing is important to pay attention to.
Cybersecurity often gets pulled into submission preparation too late, after software development decisions have already been finalized. At that point, regulatory teams are forced to retrofit documentation instead of demonstrating a cohesive cybersecurity strategy from the beginning.
That creates avoidable review friction.
The Cybersecurity Documentation Most Manufacturers Still Underestimate
Many regulatory teams assume cybersecurity evidence is limited to software documentation. Under MDR, reviewers increasingly expect much broader operational evidence.
The strongest submissions typically include:
| Documentation Element | Why It Matters in 2026 |
|---|---|
| Threat modeling | Demonstrates proactive risk identification |
| Security architecture diagrams | Helps reviewers understand system protections |
| SBOM (Software Bill of Materials) | CRA state-of-the-art standard for EU; must be machine-readable and maintained post-market, not a static submission document |
| Vulnerability management procedures | Shows lifecycle cybersecurity governance |
| Penetration testing summaries | Validates security controls |
| Secure update procedures | Demonstrates post-market readiness |
| Cybersecurity PMS processes | Supports ongoing compliance obligations |
| Vulnerability disclosure policy | Reviewers increasingly expect a documented, public-facing process for how vulnerabilities are received, assessed, and communicated which aligns with CRA and FDA postmarket expectations |
| AI-specific cybersecurity documentation | For AI-enabled devices, MDCG 2025-6 requires cybersecurity evidence integrated with AIA compliance documentation. Bias mitigation, transparency, and algorithm change management all intersect with cybersecurity under the combined MDR/AIA framework |
One area becoming especially important is demonstrating “state of the art” cybersecurity practices.
This requirement creates a moving target. Unlike traditional hardware validation, cybersecurity expectations evolve continuously as threats change. Regulatory teams therefore need processes capable of adapting after commercialization, not just during submission preparation.
What Regulatory Teams Should Prioritize Right Now
The manufacturers navigating MDR cybersecurity reviews most effectively tend to share three characteristics:
- Cybersecurity involvement begins early
- Documentation ownership is centralized
- Cybersecurity is treated as a lifecycle process rather than a submission checkbox
For regulatory leaders, several priorities stand out immediately.
1. Integrate Cybersecurity Into Regulatory Strategy Earlier
Cybersecurity cannot remain isolated within software engineering teams. Regulatory, quality, and security stakeholders need aligned documentation strategies from the start of development.
2. Strengthen Traceability Across Documentation
One of the most common review weaknesses is disconnected evidence. Threats, mitigations, software requirements, testing evidence, and residual risk conclusions should all connect clearly.
3. Build Repeatable Global Cybersecurity Processes
Manufacturers managing submissions across EU and US markets increasingly need harmonized cybersecurity documentation strategies. For MedTech teams filing in both markets, the FDA Section 524B framework and EU MDR/IVDR GSPR requirements share the same threat model, what differs is the presentation. Building one evidence set structured to satisfy both reduces duplication without sacrificing specificity. The SBOM, vulnerability management procedures, and secure development lifecycle documentation required by FDA Section 524B and MDR Annex I Section 17.2 are substantively the same artifacts, the regulatory team’s job is to ensure they are mapped and presented correctly for each framework.
4. Prepare for More Detailed Reviewer Questions
Cybersecurity scrutiny is increasing, especially for:
- AI-enabled devices
- Cloud-connected systems
- Remote monitoring technologies
- Software-heavy Class IIb and III products
5. Map Your CRA Exposure Before September 2026
CRA vulnerability and incident reporting requirements take effect September 11, 2026. Manufacturers whose connected device ecosystem includes companion apps, cloud infrastructure, or update services that are not classified as medical devices need to assess CRA applicability to those components now. The CRA exemption for medical devices is narrower than most manufacturers assume, body-worn medical device wearables must fulfill CRA requirements regardless of the medical device exemption. A regulatory team that discovers its ecosystem has CRA exposure in August 2026 will not have time to respond before the reporting deadline.
6. Assess AI Act Obligations for Any AI-Enabled Device
Most AI Act obligations for high-risk AI-enabled medical devices apply from August 2, 2026. MDCG 2025-6 clarifies the interface between MDR/IVDR and the AIA, but the operational work of mapping AIA requirements (bias mitigation, transparency, data governance, cybersecurity) onto existing MDR technical documentation is not trivial. For regulatory leaders with AI-enabled devices in their portfolio, this assessment should already be underway
Teams that prepare deeper lifecycle evidence upfront typically move through reviews more efficiently.
Why This Matters Beyond MDR
Cybersecurity requirements are no longer expanding toward a future state. They are active, overlapping obligations in the present across all major markets.
The EU MDR Simplification Package, currently in public consultation with adoption expected Q2 2027, would explicitly require medical device manufacturers to report cybersecurity vulnerabilities to CSIRTs and ENISA, bringing MDR reporting obligations in line with CRA-style requirements and strengthening cybersecurity as part of the GSPR. The direction of regulatory travel is unambiguous: manufacturers who are building cybersecurity governance infrastructure now are building the system that will be mandated within 18 months. Those waiting for final adoption before acting will be building it under enforcement pressure.
Across MDR, the Radio Equipment Directive, and the CRA, regulators are converging on one principle: manufacturers must know what is in their software, monitor it continuously, and patch it fast. This is not solved by a regulatory consultant engagement. It requires engineering infrastructure, a build-derived SBOM that is a live artifact from the actual build pipeline, continuous CVE monitoring matched against deployed binaries, and a patch deployment process with documented regulatory assessment at every change. For regulatory leaders, this means cybersecurity compliance is increasingly an architectural and operational infrastructure decision, not a documentation project.
These updates change how regulatory operations need to function internally. For many organizations, spreadsheets and fragmented documentation systems are no longer sufficient for managing cybersecurity evidence across markets, products, and lifecycle updates.
This is one reason Regulatory Information Management (RIM) Systems are becoming more central to global compliance operations.
RegDesk helps medical device and life sciences companies centralize regulatory documentation, manage submission workflows, track evolving market requirements, and maintain visibility across global regulatory activities. As cybersecurity expectations expand across MDR, FDA, and international frameworks, centralized regulatory data management becomes increasingly important for maintaining consistency across submissions and post-market obligations.
Conclusion
Cybersecurity under MDR is no longer a future compliance issue. It is already shaping how notified bodies evaluate software, risk management, and lifecycle governance today.
The manufacturers that adapt successfully will not be the ones with the largest cybersecurity teams. They will be the organizations that connect cybersecurity evidence clearly across regulatory, quality, software, and post-market processes.
For regulatory teams, the priority now is operational maturity, not simply technical compliance.
Because increasingly, cybersecurity readiness is becoming regulatory readiness.
FAQ
Q: What does MDR require for medical device cybersecurity?
A: EU MDR does not contain one standalone cybersecurity section. Instead, cybersecurity expectations are integrated throughout the regulation, particularly within Annex I General Safety and Performance Requirements (GSPRs). Manufacturers must demonstrate that cybersecurity risks are identified, mitigated, monitored, and managed throughout the device lifecycle.
Q: What cybersecurity standards are most important for MDR compliance?
A: The core standards framework for EU MDR cybersecurity is IEC 81001-5-1 (secure product development lifecycle, now the de facto authoritative standard notified bodies expect for GSPR Annex I Sections 17.2 and 17.4), IEC 62304 (software lifecycle), and ISO 14971 (risk management). MDCG 2019-16 Rev.1 remains the primary EU cybersecurity guidance document. MDCG 2025-6 (June 2025) addresses AI-enabled devices at the MDR/AIA intersection. MDCG 2020-3 governs significant software changes including security patches. The EU Cyber Resilience Act establishes the “state of the art” SBOM and vulnerability handling baseline that MDR Annex I Section 17.2 requires, with full requirements applicable December 2027.
Q: Why are notified bodies increasing cybersecurity scrutiny?
A: Connected devices, cloud integrations, AI-enabled technologies, and ransomware threats have increased concerns about patient safety risks associated with cybersecurity vulnerabilities. Regulators now expect manufacturers to demonstrate continuous cybersecurity governance rather than one-time testing activities.
Q: What documentation is typically required for MDR cybersecurity reviews?
A: Manufacturers are commonly expected to provide threat models, security architecture documentation, penetration testing evidence, vulnerability management procedures, SBOM information, secure update processes, and cybersecurity post-market surveillance plans.
Q: What does MDCG 2025-6 require for AI-enabled medical devices?
A: MDCG 2025-6, released in June 2025, is a FAQ-style guidance document clarifying how MDR/IVDR and the EU AI Act (AIA) obligations interact for high-risk AI-enabled medical devices. It outlines how manufacturers, notified bodies, and regulators should navigate combined regulatory obligations for Medical Device Artificial Intelligence (MDAI), emphasizing cybersecurity integration, bias mitigation, and transparency requirements. Most AIA obligations for high-risk AI devices apply from August 2, 2026. Manufacturers with AI-enabled devices should map their existing MDR technical documentation against MDCG 2025-6 requirements immediately, as the August 2026 deadline leaves limited runway for gap remediation.
Q: How does RegDesk help regulatory teams manage MDR cybersecurity compliance?
A: RegDesk is a cloud based Regulatory Information Management (RIM) System that helps medical device and life sciences companies centralize regulatory documentation, manage global submissions, track evolving market requirements, and maintain visibility across regulatory workflows. By organizing regulatory data and streamlining submission processes, RegDesk helps teams manage increasingly complex compliance requirements across global markets.
