EU Cyber Resilience Act (CRA) + NIS2: Impact on Medical Device Manufacturers in 2026-2027
Complete guide to how the EU Cyber Resilience Act (CRA) and NIS2 Directive affect medical device manufacturers — including the MDR/IVDR exemption, indirect CRA impact scenarios, NIS2 supply chain obligations, MDCG cybersecurity guidance, timelines, penalties, and compliance strategies.
Medical Devices Are Exempt from the CRA — But You Are Almost Certainly Still Affected
The EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) entered into force on December 10, 2024, establishing the first horizontal cybersecurity regulation for products with digital elements in the EU. The NIS2 Directive (EU 2022/2555) has been enforceable since 2024, with 19 of 27 Member States having transposed it into national law as of February 2026. Together, these two regulations create a comprehensive cybersecurity framework that reaches far beyond what the MDR and IVDR alone require.
The CRA explicitly exempts medical devices regulated under MDR 2017/745 and IVDR 2017/746 from its product requirements. But here is the critical nuance: "exempt" does not mean "unaffected." Medical device manufacturers face at least five scenarios where CRA, NIS2, or their combined effects create new compliance obligations. This guide maps every overlap, explains what is changing in 2026-2027, and provides actionable compliance strategies.
The Three EU Cybersecurity Regulations Affecting Medical Devices
Three overlapping EU cybersecurity instruments create a layered compliance landscape for medical device companies:
| Regulation | Formal Name | Scope | Status (April 2026) |
|---|---|---|---|
| CRA | Regulation (EU) 2024/2847 | Cybersecurity of products with digital elements | EIF Dec 2024; reporting from Sep 2026; full compliance Dec 2027 |
| NIS2 | Directive (EU) 2022/2555 | Network and information system security for essential/important entities | Transposition deadline Oct 2024; 19/27 Member States transposed |
| MDR/IVDR | Regulation (EU) 2017/745 / 2017/746 | Medical device safety, including cybersecurity in GSPR Annex I Section 17 | Fully applicable since May 2021 |
Additionally, the EU AI Act (Regulation (EU) 2024/1689) intersects with all three for AI-enabled medical devices, and the GDPR applies to personal data processed by connected medical devices.
CRA Overview: What It Requires and When
Core Requirements
The CRA introduces 21 mandatory cybersecurity requirements for "products with digital elements" — essentially any hardware or software product with a digital component that is intended to have a logical or physical data connection. Key requirements include:
- Secure by design and default: Products must be designed, developed, and produced so that they ensure an appropriate level of cybersecurity
- Vulnerability handling: Manufacturers must identify and document vulnerabilities and maintain processes for coordinated disclosure
- Security updates: Products must receive security updates for their expected lifecycle (minimum 5 years default)
- SBOM (Software Bill of Materials): Manufacturers must maintain and make available a software bill of materials
- Incident reporting: Actively exploited vulnerabilities and severe incidents must be reported within strict timelines
- Conformity assessment: Products must undergo conformity assessment (self-assessment for default category, third-party for critical/important categories)
Product Categories Under the CRA
| Category | Risk Level | Examples | Conformity Assessment | ~% of Products |
|---|---|---|---|---|
| Default | Standard | Consumer IoT, standard software, mobile apps | Self-assessment | ~90% |
| Important | Elevated | Industrial IoT, network management tools, identity management | Self-assessment with documented risk assessment | ~8% |
| Critical I | High | Smart home products, connected cameras, certain security components | Third-party conformity assessment (Notified Body) | ~2% |
| Critical II | Very high | Operating systems, hypervisors, digital certificates, industrial control systems | Third-party conformity assessment (Notified Body) | <1% |
CRA Timeline
| Date | Milestone |
|---|---|
| December 10, 2024 | CRA enters into force |
| June 11, 2026 | Notified Body framework becomes operational (conformity assessment bodies can be designated) |
| September 11, 2026 | Vulnerability and incident reporting obligations begin — applies to all in-scope products already on the market |
| December 11, 2027 | Full compliance required for all products placed on EU market |
| After December 11, 2027 | Substantial modifications to existing products trigger full CRA requirements |
NIS2 Overview: Enterprise-Level Cybersecurity Obligations
NIS2 focuses on the cybersecurity posture of organizations, not products. It applies to "essential entities" and "important entities" in critical sectors, including healthcare.
Who Is Affected in Healthcare
Under NIS2, medical device manufacturers fall within scope as part of the health sector, which is listed as a critical sector. Specifically:
- Essential entities: Larger medical device manufacturers and organizations that are critical to healthcare infrastructure
- Important entities: Smaller manufacturers or those that play a critical supply chain role
Member States retain discretion in setting quantitative thresholds, so scope varies across the EU. As of February 2026, 19 of 27 Member States have fully transposed NIS2, with Germany's KRITIS-Dach-Gesetz entering force March 17, 2026, and Bulgaria's legislation finalized in early 2026.
Key NIS2 Obligations
| Obligation | Requirement | Timeline |
|---|---|---|
| Risk management | Implement appropriate and proportionate technical, operational, and organizational measures | Ongoing since transposition |
| Incident reporting | Initial notification within 24 hours, full incident notification within 72 hours, final report within 1 month | Ongoing |
| Supply chain security | Address security in supplier relationships and supply chain | Ongoing |
| Business continuity | Implement crisis management and business continuity plans | Ongoing |
| Training | Provide cybersecurity training for all staff | Ongoing |
| Vulnerability handling | Policies for vulnerability handling and disclosure | Ongoing |
| Access control | Multi-factor authentication, privileged access management | Ongoing |
| Asset management | Maintain inventory of all network and information system assets | Ongoing |
NIS2 Penalties
| Entity Type | Maximum Fine | Personal Liability |
|---|---|---|
| Essential entities | €10 million or 2% of global annual turnover (whichever higher) | Management can be held personally liable; temporary ban from management positions |
| Important entities | €7 million or 1.4% of global annual turnover (whichever higher) | Similar but reduced scope |
Five Scenarios Where the CRA Still Affects Medical Device Companies
Despite the MDR/IVDR exemption, the CRA reaches medical device manufacturers through multiple pathways.
Scenario 1: Mixed Product Portfolio
If your company sells medical devices AND consumer health apps, wellness trackers, fitness products, or other non-medical digital products, those non-medical products fall fully under the CRA. A company that sells both a Class II medical device (MDR) and a companion wellness app (CRA) must comply with both regulatory frameworks.
Scenario 2: Supply Chain Components
Components within medical devices — operating systems, microcontrollers, communication modules, software libraries — may be sold as standalone products with digital elements. If a component supplier sells the same component both to medical device manufacturers and to non-medical device makers, the standalone component falls under the CRA. This means medical device manufacturers may need to request CRA-compliant SBOMs and vulnerability information from their suppliers.
Scenario 3: Companion and Accessory Software
Software that accompanies a medical device but is not itself a medical device — such as hospital IT integration platforms, data analytics dashboards, or device configuration tools — falls under the CRA if it meets the "product with digital elements" definition and is not regulated under MDR/IVDR.
Scenario 4: Clinical Trial and Research Products
Products used in clinical investigations that do not yet bear a CE mark may fall outside the MDR exemption and within the CRA scope. Prototype devices, trial units labeled "not for clinical use," and research-only software tools may need CRA compliance.
Scenario 5: Vulnerability Reporting Supply Chain Shock
Even for fully MDR/IVDR-regulated devices, the suppliers in your software supply chain are subject to the CRA. From September 11, 2026, those suppliers must report actively exploited vulnerabilities within 24 hours. Medical device manufacturers must have processes to receive, evaluate, and act on these vulnerability reports to meet their own MDR post-market surveillance obligations.
How MDR/IVDR Already Addresses Cybersecurity
The MDR and IVDR are not silent on cybersecurity. Annex I Section 17.2 requires that devices incorporating 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
MDCG 2019-16 (Rev 1) provides detailed guidance on cybersecurity for medical devices, including:
- Security risk management throughout the product lifecycle
- Secure design principles (least privilege, defense in depth)
- Security testing methods (fuzz testing, vulnerability scanning, penetration testing)
- Secure code analysis and open source code scanning
- SBOM maintenance
- Patch management and update processes
- Incident response and vulnerability disclosure
GSPR Cybersecurity Requirements
| GSPR Section | Requirement | Practical Implication |
|---|---|---|
| Annex I, 17.2 | Software developed per state-of-the-art lifecycle | IEC 62304 + security-specific processes |
| Annex I, 17.2 | Risk management including information security | ISO 14971 must address cybersecurity risks |
| Annex I, 17.2 | Minimum IT security requirements | Protection against unauthorized access |
| Annex I, 18.1 | Devices with electronic programmable systems designed to ensure repeatability, reliability, and performance | Cybersecurity must not compromise device function |
| Annex I, 22.1-22.9 | For devices connected to IT networks, adequate protection against unauthorized access | Network security for connected devices |
The Proposed MDR Revision and CRA Convergence
The European Commission's proposed MDR revision (public consultation in 2026, expected adoption Q2 2027) explicitly addresses the interplay between MDR and the CRA:
- Cybersecurity vulnerability reporting to CSIRTs: The proposal would require medical device manufacturers to report cybersecurity vulnerabilities and severe incidents to Computer Security Incident Response Teams (CSIRTs) and ENISA, aligning with CRA-style reporting requirements
- Cybersecurity in GSPR: Cybersecurity requirements would be strengthened as part of the General Safety and Performance Requirements
- SBOM requirements: While MDR already implies SBOM maintenance through technical documentation requirements, the revision may make this explicit
This means the gap between MDR cybersecurity requirements and CRA requirements is narrowing. Manufacturers who proactively align with CRA best practices will be ahead of the regulatory curve.
Integrated Compliance Strategy for Medical Device Manufacturers
Phase 1: Immediate Actions (Q2 2026)
- Map your entire product portfolio against CRA categories: which products are MDR/IVDR-regulated, which are standalone digital products, which are accessories or companions
- Identify all software components and third-party libraries in your medical devices
- Assess your supplier agreements: do they include CRA-compliant vulnerability notification clauses?
- Verify NIS2 transposition status in each Member State where you operate
Phase 2: Prepare for September 2026 CRA Reporting
- Establish processes to receive vulnerability reports from CRA-regulated suppliers within 24 hours
- Define internal workflows for evaluating supplier vulnerability reports and determining impact on your medical devices
- Prepare your own SBOMs for all products that may fall under CRA scope
- Train your post-market surveillance team on CRA/NIS2 incident reporting timelines
Phase 3: Full Compliance by December 2027
- Ensure all non-MDR/IVDR digital products meet CRA requirements
- Conduct conformity assessments (self-assessment or third-party) for CRA-regulated products
- Implement secure-by-design development practices aligned with both MDR and CRA requirements
- Establish ongoing vulnerability management programs covering the full product lifecycle
- Prepare for potential MDR revision requirements (CSIRT reporting, enhanced GSPR)
Unified Framework: Overlapping Requirements
| Requirement | MDR/IVDR | CRA | NIS2 | Unified Approach |
|---|---|---|---|---|
| Risk management | ISO 14971 + MDCG 2019-16 | CRA Annex I risk assessment | Art. 21 risk management | Single risk framework covering safety, security, and network resilience |
| SBOM | Implied in tech docs | Explicit requirement | Not specified | Maintain comprehensive SBOM for all products |
| Vulnerability management | PMS/vigilance | Art. 10-13 vulnerability handling | Art. 21(2)(d) | Unified vulnerability handling process |
| Incident reporting | Vigilance (Art. 87 MDR) | 24-hour reporting to CSIRTs | 24-hour initial notification | Create single incident triage process feeding multiple reporting channels |
| Secure development | IEC 62304 + GSPR 17.2 | Secure by design | Not product-level | Adopt IEC 62443 or NIST SSDF for all software development |
| Supply chain security | Supplier qualification | Supplier obligations | Art. 21(2)(d) supply chain | Comprehensive supplier security assessment program |
| Business continuity | PMS plan | Not explicit | Art. 21(2)(e) | Enterprise-level BCP covering product and organizational resilience |
Penalties for Non-Compliance
| Regulation | Maximum Penalty | Additional Consequences |
|---|---|---|
| CRA | €15 million or 2.5% of global annual turnover | Market ban, mandatory product recall, inability to obtain CE marking for CRA products |
| NIS2 | €10 million or 2% of turnover (essential entities) | Management personal liability, temporary ban from management positions |
| MDR | Varies by Member State | Market withdrawal, sales ban, criminal liability in some jurisdictions |
The cumulative exposure for a non-compliant medical device manufacturer could reach €25 million or 4.5% of global annual turnover if violations occur across all three regulations simultaneously.
Frequently Asked Questions
Are medical devices completely exempt from the CRA?
Medical devices regulated under MDR 2017/745 and IVDR 2017/746 are exempt from the CRA's product requirements. However, the exemption applies only to products that are medical devices or IVDs. Companion apps, wellness products, standalone software tools, and components sold separately may still fall under the CRA.
When do CRA reporting obligations begin?
Vulnerability and incident reporting obligations under Article 14 of the CRA begin on September 11, 2026. This applies to all in-scope products, regardless of when they were placed on the market. Full product conformity requirements apply from December 11, 2027.
Does NIS2 apply to small medical device manufacturers?
NIS2 applies to medium and large enterprises in the health sector. Micro and small enterprises are generally excluded from NIS2 unless they are critical service providers. However, Member States may set their own thresholds, and some have included smaller entities. Check your specific Member State's transposition law.
What is the relationship between MDR vigilance reporting and CRA/NIS2 incident reporting?
MDR Article 87 requires reporting of serious incidents to competent authorities. The CRA requires reporting of actively exploited vulnerabilities and severe incidents to CSIRTs. NIS2 requires reporting of significant incidents to national CSIRTs. A single cybersecurity incident in a connected medical device could trigger reporting obligations under all three frameworks. Manufacturers should establish a unified incident triage process.
How does the proposed MDR revision change this landscape?
The proposed revision (expected adoption Q2 2027) would explicitly require medical device manufacturers to report cybersecurity vulnerabilities to CSIRTs and ENISA, bringing MDR reporting closer to CRA-style requirements. It also strengthens cybersecurity as part of the GSPR. Manufacturers should begin aligning with these requirements now.
What is an SBOM and do medical device manufacturers need one?
A Software Bill of Materials (SBOM) is a comprehensive list of all software components, libraries, and dependencies in a product. While MDR does not explicitly mandate SBOMs, the MDCG 2019-16 guidance recommends them, and the CRA explicitly requires them. FDA also requires SBOMs for connected medical devices. Best practice is to maintain SBOMs for all software-containing medical devices.
Does the CRA apply to products placed on the market before December 2027?
Products placed on the market before December 11, 2027 are not retroactively subject to the CRA's product requirements, unless they undergo a "substantial modification" after that date. However, the Article 14 reporting obligation (vulnerability and incident notification) applies from September 11, 2026, regardless of when the product was placed on the market.
What standards should medical device manufacturers follow for cybersecurity?
Key standards include IEC 62443 (industrial cybersecurity), IEC 82304-1 (health software safety), NIST SP 800-53 (security controls), NIST SSDF (secure software development framework), and ISO/SAE 21434 (automotive, but increasingly referenced for connected medical devices). For MDR compliance specifically, follow MDCG 2019-16 and IEC 62304.
Does the September 2026 deadline mean full vulnerability management must be in place?
No. This is a common misunderstanding. The September 11, 2026 deadline triggers only Article 14 reporting obligations — the requirement to notify authorities when you discover an actively exploited vulnerability or severe incident in a CRA-regulated product. The full vulnerability handling processes (Article 13) are not required until December 11, 2027. If a consultant tells you that complete vulnerability management must be operational by September 2026, they are conflating Article 14's event-triggered reporting duties with Article 13's ongoing process requirements.
Is the CRA a regulation or a directive?
The CRA is a regulation (Regulation (EU) 2024/2847), not a directive. This means it is directly applicable in all 27 EU Member States without the need for national implementing legislation. This contrasts with NIS2, which is a directive that required each Member State to transpose it into national law by October 2024 (though many missed this deadline).