The EU Cyber Resilience Act and medical devices: what's in scope and what isn't.

The EU Cyber Resilience Act (CRA) entered into force in December 2024, with most requirements applying from December 2027. If you're a medical device manufacturer, you've probably heard that the CRA excludes products already regulated under MDR and IVDR.

That's true. But it's not the whole story.

The exclusion is narrower than many assume. Plenty of products from MedTech companies still fall within the CRA's scope. Understanding where the boundary lies matters for your compliance planning.

What the CRA is trying to achieve

The CRA establishes baseline cybersecurity requirements for products with digital elements sold in the EU. It's a horizontal regulation, meaning it applies across sectors rather than to specific industries.

The core requirements include secure by design principles throughout the product lifecycle, vulnerability handling processes and coordinated disclosure, security updates for a defined support period, incident reporting to ENISA (early warning within 24 hours, full notification within 72 hours, final report within 14 days of a fix being available), and a Software Bill of Materials for each product.

The CRA also mandates CE marking for cybersecurity, separate from any other CE marking your product might require. Non-compliance means you cannot place the product on the EU market.

For most software and connected products, the CRA fills a gap. Before now, there was no EU-wide cybersecurity baseline for consumer and commercial products. The CRA changes that.

The medical device exclusion

Article 2 (2a & 2b) of the CRA explicitly excludes products already covered by certain sector-specific regulations. Medical devices under MDR (Regulation 2017/745) and in vitro diagnostic medical devices under IVDR (Regulation 2017/746) are on that list.

The logic is straightforward: MDR and IVDR already have cybersecurity requirements. GSPR 17.2 requires manufacturers to consider information security, and GSPR 17.4 mandates minimum IT security measures. Notified Bodies assess against IEC 81001-5-1 as the state of the art. Adding CRA requirements on top would create duplication and potential conflict, but with no guidance for IEC 81001-5-1, it does offer an insight into the intent and best practice on Cybersecurity within the single market.

So if your product is a regulated medical device under MDR or IVDR, the CRA does not apply to that product.

However, this may be changing. In December 2025, the European Commission published a proposal to revise MDR and IVDR. The proposal would keep the general CRA exclusion for medical devices, but introduce the CRA's incident reporting requirements. Manufacturers would need to report actively exploited vulnerabilities and severe cyber incidents to CSIRTs and ENISA , in addition to existing vigilance obligations where public health and patient safety are concerned. The proposal is currently working through Parliament and Council, so the final requirements may shift. Worth watching.

But here's where it gets more nuanced.

What's still in scope

The exclusion applies to the medical device itself. It doesn't automatically extend to everything your company makes, or even everything connected to that device.

Companion apps without medical device functionality. Many medical devices have associated mobile apps. If the app is part of the medical device (performs a medical function, is included in your MDR technical file), it's excluded along with the device. But if the app is purely for convenience, data display, or lifestyle features, and isn't itself a medical device, the CRA applies to it.

Wellness and health apps. Products positioned as wellness rather than medical often fall outside MDR scope. Fitness trackers, sleep monitors, general health apps without diagnostic or therapeutic claims. These are squarely within CRA scope.

Backend infrastructure and cloud services. Your device might connect to cloud services for data storage, analytics, or remote monitoring. If those services aren't part of the certified medical device, they may have separate obligations. Note that pure SaaS products fall under the NIS 2 Directive rather than the CRA, so the applicable regime depends on how the service is structured.

Accessories and peripherals. A smart charging dock, a carrying case with electronics, a display unit. If these aren't covered by your MDR certification, consider whether they have digital elements that bring them into CRA scope.

General-purpose software tools. If your company also produces software tools for healthcare professionals that aren't medical devices (practice management, scheduling, general record-keeping), the CRA likely applies.

The health app scenario

This is where I see the most confusion.

A common piece of advice for MedTech startups: launch as a health app first, defer the medical device claims until you have traction and investment. It's sensible from a go-to-market perspective. Lower regulatory burden while you're finding product-market fit.

But "lower" doesn't mean "none."

A health app without medical device claims doesn't need MDR certification. It also doesn't get the MDR exclusion from the CRA. Your wellness app, your symptom tracker, your lifestyle companion, if it has digital elements and you're selling it in the EU, the CRA applies.

This isn't necessarily a problem. But it does mean planning for CRA compliance from day one, even if MDR comes later. The good news is that CRA and MDR cybersecurity requirements overlap significantly. If you're building to CRA requirements now, you're laying groundwork that will serve you when you pursue MDR certification. SBOMs, vulnerability management, secure development practices, these transfer directly.

The manufacturers who get caught out are those who assume "not a medical device" means "no cybersecurity regulation." That was true before December 2024. It won't be by December 2027.

How CRA requirements compare to MDR

For those tracking compliance across both regimes, here's how they align.

SBOMs: CRA explicitly requires them. MDR doesn't mandate the term, but Notified Bodies expect vulnerability (CVE) surveillance of 3rd party software in your device, and an SBOM is industry best practice for achieving this.

Vulnerability handling: Both require processes for identifying, assessing, and addressing vulnerabilities. CRA is more prescriptive on timelines and disclosure.

Security updates: CRA requires a defined support period and free security updates. MDR expects ongoing security maintenance under postmarket surveillance.

Incident reporting: CRA requires reporting actively exploited vulnerabilities to ENISA with an early warning within 24 hours, full notification within 72 hours, and a final report within 14 days. MDR requires vigilance reporting to competent authorities (timelines vary by severity) for cybersecurity vulnerabilities leading to public health or patient safety concerns.

Secure development: Both expect security to be designed in, not bolted on. CRA references secure by design principles. MDR, via IEC 81001-5-1, expects a secure development lifecycle.

The practical upshot, if you're already meeting MDR cybersecurity expectations properly, CRA compliance for your non-medical device products shouldn't require a fundamentally different approach. The frameworks are philosophically aligned.

Timeline and enforcement

The CRA entered into force on 10 December 2024. Most obligations apply from 11 December 2027, right now you have two years to prepare.
Some requirements kick in earlier. Reporting obligations for actively exploited vulnerabilities apply from 11 September 2026. This doesn't apply to medical devices yet, but this change has been proposed.

Enforcement will be through market surveillance authorities in each member state, similar to how CE marking compliance is monitored today. Penalties for non-compliance can be significant, up to €15 million or 2.5% of global turnover for the most serious infringements.

What to do now

If you're a medical device manufacturer, start by mapping your product portfolio. Identify which products are covered by MDR/IVDR (and therefore excluded from CRA), and which have digital elements but fall outside medical device regulations.

For products in CRA scope, assess your current cybersecurity practices against CRA requirements. If you're already building to IEC 81001-5-1 for your medical devices, you likely have a solid foundation. The gaps will be in CRA-specific requirements like the 24-hour reporting timeline and formal support period declarations.

For products that might transition from wellness to medical device, plan your compliance roadmap to work for both paths. Building to CRA requirements now won't hinder your MDR submission later, and it may make it easier.

And if you're advising startups on regulatory strategy, make sure the "launch without medical device claims" advice comes with the full picture. The CRA means cybersecurity obligations exist regardless.

The bottom line

The CRA excludes medical devices under MDR and IVDR. But plenty of products from MedTech companies still fall within scope: companion apps, wellness products, backend services, accessories, and software tools.

If you're building anything with digital elements for the EU market, the question isn't whether cybersecurity regulation applies. It's which regulation applies. For medical devices, it's MDR. For everything else, it's increasingly the CRA.

Understanding that boundary now will save you surprises in December 2027.