CRA and MedTech: Two Questions Decide Whether You Must Report from 11 September

CRA Regulation (EU) 2024/2847 · Art. 2(2) · Art. 14 · Art. 69(3) · Art. 71(2) · EU MDR 2017/745

Two mistakes about the Cyber Resilience Act circulate in medtech. They point in opposite directions, and most companies hold one of them.

The first: "Medical devices are exempt — done." Box ticked, file closed. That is true for the device and misses everything else the company ships.

The second has lately become the more common one: "Everything around our device is now in scope — cloud, portals, all of it." That is the panic version, and it is equally wrong. A substantial share of what sits beside the device falls outside both regimes.

Between those two mistakes lies a fairly simple sorting exercise. It consists of two questions, in this order.

And it is time-critical: the CRA reporting obligations under Art. 14 apply from 11 September 2026 — the rest of the CRA only from 11 December 2027.

Question 1: Is it a product at all?

This question is almost always skipped, and it sorts most cases.

The CRA covers products with digital elements. It does not cover services. Software is not a product merely because it is software.

A European Commission guidance of 27 July 2026 sets out the criterion: what matters is where the software runs.

In practice:

• If the software runs on your customer's device — a downloaded app, an installed client, a browser extension, a desktop tool — it is a product.
• If it runs only on your servers and the customer sees it in a browser, that alone does not make it one.

This removes an entire category that many file reflexively: pure cloud backends, web portals, browser-based analysis front-ends. A backend is only part of a CRA product where it carries the core function of a product you have actually placed on the market — and if it carries the core function of your MDR device, it is part of that product and exempt along with it.

This does not mean services carry no cybersecurity obligations. It means those obligations sit in other legislation — for service providers, NIS2 is the relevant regime. This article does not cover it.

In one line: the CRA reaches what you ship, not what you operate.

Question 2: If it is a product — does the medical device exemption apply?

Only now does the MDR enter.

Under Art. 2(2)(a) and (b), the CRA excludes products already covered by the MDR (Regulation (EU) 2017/745) or the IVDR (Regulation (EU) 2017/746). What matters is the cut of that exemption:

What is exempt is the CE-marked medical device itself — including the software that forms part of its intended purpose and CE marking. What is not exempt is the manufacturer as a company, and everything else it ships.

The reason there is no second compliance path for the device: the MDR is lex specialis here — the more specific law prevails. The cybersecurity requirements for the device follow from the MDR general safety and performance requirements, and the standard operationalising them across the software lifecycle is IEC 81001-5-1. The CRA and the MDR therefore do not apply in parallel to the same device.

For body-worn wearables, classification as a medical device or non-medical device can go either way depending on intended purpose and must be settled case by case.

What remains after both questions

Anyone who answers both questions for each item usually ends up with a short list. Typically on it:

• Companion apps without their own medical intended purpose that your customer downloads from an app store. They run on their device, they are not a medical device — the clearest case.
• Installable standalone software without CE marking: configurators, service tools, PC analysis software. Pure web portals do not belong here (Question 1).
• Non-medical hardware with digital elements in your portfolio: accessories, charging stations, gateways, test equipment. Indisputably a product, indisputably not a medical device.
• Supply chain reports on vulnerabilities in supplied components of those products that fall within scope.

Not conclusively settled is the treatment of OTA/update infrastructure: the distributed software belongs to the respective product, while the distribution infrastructure itself looks more like a service. We list it deliberately as an open point, not as an obligation.

Whether a specific component actually falls within scope depends on its intended purpose and design and must be assessed case by case. This list is therefore not a verdict of obligation but the checklist with which you and your regulatory function (RA/PRRC) decide.

And the point most often missed in practice: it is the same manufacturer for the overall system. But the exemption follows the product, not the company.

Why 11 September and not December 2027

The CRA obligations do not all bite at once. Art. 71(2) staggers them:

So on 11 September 2026 only the reporting obligation begins — but it begins in full. The essential requirements in Annex I, the remaining manufacturer obligations, conformity assessment and CE marking follow in December 2027.

This is uncomfortable precisely because the part that bites first is the one you cannot document but must be able to do:

And the installed base is explicitly included. The CRA transitional rule largely exempts products placed on the market before 11 December 2027 — but not from Art. 14. Under Art. 69(3), the reporting obligation applies regardless of when the product was placed on the market, as long as it is still on the EU market on or after 11 September 2026. Building future products correctly is therefore not enough: your installed base is covered immediately.

The point almost nobody writes about: the reporting channel is not up yet

Reporting goes through ENISA's Single Reporting Platform, simultaneously to ENISA and to the national CSIRT designated as coordinator.

As of late August 2026 that platform is not reachable. No URL has been published, the list of designated coordinator CSIRTs is still outstanding, no reporting API is offered, and no dry run in the production system is possible. ENISA has committed to operation from 11 September 2026 and published step-by-step instructions on 31 July 2026; registration runs through EU Login.

The uncomfortable part is not the delay but a gap: should the platform be unavailable or only partly available on the date, no alternative route is provided for — neither in the Regulation nor in ENISA's guidance.

And here lies the difference from a case many hold up as the template: with EUDAMED, the obligation was tied to the database being available; while it was missing, the obligation rested. This is structured differently. The clock runs from your knowledge of the vulnerability, not from the availability of the channel. A manufacturer can therefore become subject to reporting on 12 September without a functioning route being guaranteed.

The practical conclusion is very concrete: register now via EU Login and settle now which national CSIRT is responsible for you. Both can be done today. On the day of the incident it is no longer a research question — by then the 24 hours have already started.

What you can do yourself — four steps, no tooling

You do not need software for this. You need a list, two hours, and the willingness to take your portfolio apart once.

1. List everything you ship. Not "our product", but each item on its own: device, embedded software, apps, installable tools, accessories, gateways. And separately, a second list: what you operate rather than ship — portals, cloud services, browser-based front-ends. This split alone answers Question 1 for most of the portfolio.
2. Answer Question 2 for each shipped item: does it belong to the intended purpose and CE marking of your medical device — or does it stand on its own? Record the reasoning, not just the outcome. The reasoning is what you will be asked for.
3. For whatever remains, settle the reporting path: who in your organisation notices an actively exploited vulnerability? Who decides within 24 hours that it is reportable? Who reports — registered via EU Login, to which CSIRT? And how will you afterwards show it happened on time? Those four questions are the entire process.
4. Have your RA/PRRC function countersign the result. Classification is a regulatory assessment, not a gut call — and it belongs in the documentation, not in an inbox.

If after step 1 the shipped list holds exactly one row — "our device" — that is already a result: either you genuinely have no CRA object, or you forgot the accessories.

What this article does not do

It replaces neither a case-by-case regulatory assessment nor legal advice. It sorts two regimes against each other, names a deadline, and names a reporting channel that was not yet up at the time of writing. Which of your items ends up in which scope is decided by you together with your regulatory function — not by an article and not by a tool.

Information on deadlines, dates of application and the reporting channel is current as of 27 August 2026.