If you make medical devices for the European market, you have probably been told the Cyber Resilience Act is not your problem. That is correct, and it is also the reason a number of manufacturers are going to be surprised on 11 September 2026, when the regulation's reporting obligations start applying.

The exclusion is real. It is narrower than the company.

The exclusion, in the regulation's own words

Article 2(2) of Regulation (EU) 2024/2847 is unambiguous:

“This Regulation does not apply to products with digital elements to which the following Union legal acts apply: (a) Regulation (EU) 2017/745; (b) Regulation (EU) 2017/746…”

Those are the MDR and the IVDR. Recital 25 gives the reason: those regulations already impose cybersecurity requirements across the product lifecycle, so layering the CRA on top would duplicate them.

So if you place a CE-marked medical device on the EU market under the MDR, the CRA does not apply to that device. That sentence is worth reading twice, because every word in it is doing work.

Three things it does apply to

The CRA excludes products covered by the MDR. It does not exclude manufacturers of those products. Most medtech companies place more than one thing on the European market, and the exclusion does not travel with the company logo.

1. Wellness and dual-use products

This is the largest door, and companies walk through it deliberately.

Consumer wearables, connected health products and companion hardware are frequently engineered — and more importantly, claimed — so that they stay outside the definition of a medical device. That is a rational strategy. It avoids the MDR in Europe and it avoids device classification in the United States.

Here is the part that catches people. In the US, cybersecurity obligations under Section 524B travel with device classification: stay on the wellness side of the line and 524B never attaches. In the EU, the CRA excludes what the MDR already covers — so staying on the wellness side of the same line takes you out of the MDR and into the CRA.

The same design decision, made once, produces opposite regulatory outcomes in the two markets. It removes an obligation in one jurisdiction and buys one in the other.

2. Anything outside the certificate

Companion apps, accessories, standalone software sold separately, and connected products that are not covered by your MDR certificate are products with digital elements in their own right. The exclusion in Article 2(2) attaches to the product the MDR covers, not to everything shipped alongside it.

If your notified body's certificate does not name it, do not assume the CRA exclusion reaches it.

3. Electronic health record systems

This one is not obvious, because it arrived through a different regulation.

Regulation (EU) 2025/327 — the European Health Data Space — is titled, in part, “amending Directive 2011/24/EU and Regulation (EU) 2024/2847.” Its Article 104 inserted a new Article 32(5a) into the CRA:

“Manufacturers of products with digital elements that are classified as EHR systems under Regulation (EU) 2025/327 shall demonstrate conformity with the essential requirements set out in Annex I to this Regulation using the relevant conformity assessment procedure provided for in Chapter III of Regulation (EU) 2025/327.”

Read the reference carefully. “Annex I to this Regulation” is Annex I of the CRA. An EHR system manufacturer meets the CRA's essential cybersecurity requirements; the EHDS only decides where that gets assessed.

And the procedure it points to is a self-assessment. The EHDS imposes a mandatory conformity self-assessment scheme for the harmonised software components of EHR systems: the manufacturer draws up the EU declaration of conformity and affixes the CE marking. No notified body reviews it.

Self-assessment reads like the lighter option. In the part that matters it is the opposite. The substantive standard does not drop — the liability moves. Nobody is going to tell you what is missing, and your name is on the declaration.

What actually starts on 11 September 2026

Two dates circulate together and they are not the same thing.

The September date is the one with teeth this year. It covers actively exploited vulnerabilities and severe incidents, on a schedule: an early warning within 24 hours, a notification within 72 hours, and a final report — 14 days for actively exploited vulnerabilities, one month for severe incidents.

Two things about that schedule are worth stating plainly. First, 24 hours is not a documentation deadline; it is an operational one. It assumes somebody is watching, somebody can decide, and somebody knows where to file, on a weekend if necessary.

Second, and more uncomfortable: the reporting duty reaches products already on the market. It is not limited to products placed on the market after full application in December 2027. A product you shipped in 2024 can generate a 24-hour obligation in October 2026.

What the CRA asks for that FDA does not

If your compliance instincts were trained on FDA expectations, three CRA requirements will not be where you expect them.

A minimum support period. The CRA sets a floor: the support period “shall be at least five years,” or the expected use time where the product is expected to be in use for less than five years. FDA sets no minimum at all. FDA requires you to disclose end of support and end of life, and to have a pre-established, pre-communicated process for transferring the risk to the user. A product can be entirely 524B-compliant with a two-year support window. That same product does not satisfy the CRA.

Security updates free of charge. Annex I requires that security updates be disseminated without delay and, save for tailor-made products agreed with a business user, free of charge. If extended support is a revenue line, it does not survive the crossing.

An SBOM you are not required to show anyone. This one runs opposite to the usual assumption about which jurisdiction is stricter on transparency. The CRA requires manufacturers to draw up a software bill of materials “in a commonly used and machine-readable format covering at the very least the top-level dependencies.” On disclosure, Annex II is explicit that it is optional: information on where the SBOM can be accessed is required only “if the manufacturer decides to make available the software bill of materials to the user.”

Section 524B, by contrast, requires you to provide the SBOM to FDA, and the guidance asks for the maintenance status of each component — actively maintained, no longer maintained, abandoned — along with its end-of-support date. Europe asks for less depth and lets you keep it. The US asks for more and takes a copy.

What to do in the next month

Not a compliance programme. Three questions, answerable from what you already know:

  1. List what you place on the EU market that your MDR certificate does not name. Companion apps, accessories, standalone software, wellness products, anything sold separately. That list is your CRA scope, and for most companies it is not empty.
  2. Check whether anything in that list claims interoperability with an EHR system. Under the EHDS, that claim is voluntary — but making it attaches a labelling regime, with market surveillance authorities checking against essential requirements and a label that expires after three years. The trigger is not what the product is. It is what you say about it.
  3. Decide who receives a report at 3 a.m. on a Sunday. A 24-hour early warning obligation is a rota question before it is a legal one.

None of that requires a decision about the December 2027 deadline. It requires knowing, before September, which of your products the CRA was always going to reach.