Contact Us
Sep 10, 2026

When the Instrument is Exempt but the Software Isn’t

Picture of Nathan Smith

Nathan Smith

Nathan Smith is a principal consultant at SolaSec focusing on securing applications and products. He began is career developing embedded products, he now leverages his experience to help organizations assess and improve the security posture of products across multiple industries.

Mapping Cyber Resilience Act Exposure Across a Connected Diagnostic Workflow

A scope-mapping guide for regulatory, quality, and product-security teams at connected-diagnostics and medical device manufacturers.

 

Some manufacturers out there are reaching the wrong conclusion internally. It goes like this: “Our devices are MDR-regulated, so the Cyber Resilience Act doesn’t apply to us.” That conclusion is correct about the device but could be wrong about what ships alongside it.

The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, does carve out products covered by the MDR and IVDR. But the exclusion applies only to products to which the MDR or IVDR applies. Companion software and supporting infrastructure need their own scope assessment; some may qualify as products with digital elements under the CRA.

A manufacturer can’t report vulnerabilities for products it hasn’t scoped, and from September 11, 2026, Article 14 gives it 24 hours to report. The question is no longer whether the CRA applies to a manufacturer, but to which of its products.

TL;DR

  • The MDR/IVDR carve-out covers the device. It does not automatically cover the companion app, cloud backend, integration connectors, update infrastructure, or service tooling shipped around it.
  • Manufacturers need a component-by-component map of what the CRA actually reaches inside their portfolio. Everything downstream depends on getting it right, and the window to get it right is already open.
  • The deliverable is a one-page exposure map — a row per component, a clause per determination, an owner per row.
 

What the CRA Regulates, and What the Carve-Out Actually Covers

The CRA governs “products with digital elements”, hardware or software that connects, directly or indirectly, to another device or a network. That definition is deliberately broad. First, a “product with digital elements” includes its remote data processing components. If a product cannot do its job without the manufacturer’s cloud, that cloud is part of the regulated product. Second, any component a manufacturer places on the market separately is a product in its own right.

The CRA excludes products already covered by sector-specific EU law, medical devices among them. The practical distinction is the product boundary:

The carve-out follows the regulated product. It does not automatically follow every digital component the manufacturer ships around it.

An exempt device is not an exempt ecosystem, and the gap between those two ideas is where the risk concentrates.

Exempt is not unobligated, either: the device still answers to the MDR’s general safety requirements and, in practice, to existing sector guidance.[i]

Below are six places to look in a connected device architecture and a place to look for deciding factors:

1.      The device itself. Hardware and embedded control software — the pump, the monitor, the analyzer. Usually the one node nobody argues about; the device file decides it.

2.      The companion app. More and more devices ship with one, and its intended purpose and relationship to the device need explicit review.

3.      The cloud backend. The remote-data-processing test decides whether it is part of the product or a neighbor of it.

4.      Integration layers.HL7/FHIR interfaces, EHR and LIS connectors, middleware — often general-purpose, and hard to attribute to any one device file.

5.      Update and fleet-management infrastructure. The systems that sign, distribute and install software on fielded devices. The CRA has explicit expectations here.[ii]

6.      Service and support tooling. Field diagnostics, remote-access appliances, configuration tools. Include these in the inventory and assess their intended purpose and supply model.

Location tells a manufacturer where to look, not what the answer is: medical device software is qualified by its intended purpose, wherever it runs. 

Why the CRA Could Reach Further Than the MDR

The CRA could pull a cloud backend inside the product boundary while the MDR may not. The remote-data-processing test has three limbs, and the third is the one people miss: the processing is at a distance; the product cannot perform a function without it; and the software is built by the manufacturer or under its responsibility. Separately, a service the manufacturer licenses off the shelf is a third-party component — the manufacturer owes it due diligence, but it does not become part of the manufacturer’s product.

Nothing in the MDR or IVDR makes a service part of a device due to the simple fact that the device cannot function without it. The MDR has the manufacturer specify what the device needs from the network and treats the IT environment as something the device “operates and interacts” with — which only makes sense if the network is outside the device.4

So where does an indispensable cloud backend behind an exempt device land? Well, it appears to be unsettled. One reading has the carve-out cover the whole composite, so the backend follows the device out of CRA scope; the other leaves the backend inside the CRA with its own CE mark. You shouldn’t treat these as interchangeable options, so the most defensible position may very well be to document the applicable product boundary and be prepared to revisit retroactively as policies evolve.

The uncomfortable reality is that a single commercial offering routinely straddles both regimes. The instrument may be exempt while the cloud reporting layer is not; the bundled analysis software may be covered while the connector that ships with it is not. Uniform answers across a portfolio are the exception, not the rule — which is exactly why a blanket “we’re exempt” cannot survive contact with the actual architecture.

How to Decide Whether a Component Is Exempt or In Scope

The four-step test

  1. Does the MDR or IVDR apply to the component itself — as a device in its own right, as part of one, or as an accessory? If yes, it falls outside the CRA. This turns on the regulation applying, not on a CE mark. If no, keep going.
  2. Does it connect, directly or indirectly, to a device or a network? If yes, it is a “product with digital elements” and a candidate for scope.
  3. Is it a remote data processing solution of another product? All three Art. 3(2) limbs must hold: processing at a distance, the product cannot perform a function without it, and the manufacturer built it or had it built. If so, it is part of that product and follows it. If not, anything placed on the market separately is a product in its own right, with whoever places it there as its manufacturer.
  4. Does the device’s existing MDR/IVDR cybersecurity coverage extend to this component? This is the step teams skip. “It’s covered under the device file” is a claim, and claims get verified.
 

Worked example: the companion app that pairs with the device

Step 1 is where the errors happen. “It isn’t the device” does not answer it; there are two ways the app can be caught.

First, is it a device in its own right? An app that displays or logs readings has no medical purpose of its own. An app that interprets them — alarming on a threshold, calculating a dose, flagging a trend as clinically significant — is providing information used for a diagnostic or therapeutic decision. That is medical device software, Class IIa at minimum. The MDR applies; the CRA does not.5

Second, is it an accessory — something intended to specifically enable the device to be used as intended, or to directly assist its medical functionality? An app that is the only way to configure therapy parameters is; an app that mirrors a display for convenience is not.

If both answers are no, steps 2 to 4 go quickly: it connects, it is distributed and versioned on its own, and the device file does not reach it. Verdict: a CRA product, with its own CE mark and reporting obligations. And nothing turned on where the app runs — embed it on the device and it classifies identically.

Why Vulnerability Reporting Bites Before the Main Compliance Deadline

Internal CRA conversations fixate on December 2027. The reporting clock starts fifteen months earlier.

Starting September 11, 2026, a manufacturer of an in-scope product that becomes aware of an actively exploited vulnerability must notify the CSIRT designated as coordinator under Article 14(7) and ENISA together, through the single reporting platform. For exploited vulnerabilities: early warning within 24 hours of awareness, notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure becomes available. Severe incidents also have 24-hour and 72-hour stages, but their final report is due within one month after the incident notification.6

Every component the map places inside the CRA inherits that cadence, and the intake and escalation machinery behind a 24-hour deadline takes time to stand up and rehearse.7

September is also when suppliers’ clocks start. Separately supplied chips, OS images and crypto libraries may be in-scope CRA products, with Article 14 reporting duties for their manufacturers. Assess the supply model and exclusions, including those for non-commercial open-source software. For in-scope products, Article 13(5)–(6) sets due-diligence and upstream vulnerability-reporting duties, generally applicable from December 11, 2027. Those CRA duties do not automatically extend to an excluded medical device because its components are in scope. Supplier notices need a path into post-market surveillance and CAPA. Define and rehearse that route before a supplier notice arrives.8

Fines run to €15 million or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher, and a product the manufacturer knows to be non-conforming must be corrected, withdrawn or recalled.9

Does the December 2025 MDR/IVDR proposal remove the exemption?

No. In December 2025 the Commission proposed amendments to the MDR and IVDR as part of its medtech simplification package. It does not touch the CRA’s scope. It would instead require device manufacturers to report actively exploited vulnerabilities and severe security incidents through EUDAMED, using the CRA’s own definitions. It is not law yet and will likely change — but if it passes in anything like its current form, the scope map becomes the device-side reporting inventory, and the classification work carries across intact.10

Putting It to Work: The Exposure-Mapping Template

Start with a concise exposure register: a row per component, with columns for connectivity, regulatory status, and the basis for the determination. Inventory every digital component shipped with or alongside the devices — including the ones nobody thinks of as products — run the four-step test on each, record the reasoning rather than just the verdict, and revisit whenever the architecture changes or the MDR/IVDR proposal advances. Auditors ask for evidence, not intent.

What a filled-in row looks like

Here is the map applied to an infusion pump and the estate around it. The two companion apps differ only in what they are for.

Before You Close the Tab

SolaSec is a Dallas-based cybersecurity consulting firm specializing in offensive security services for the healthcare sector. We partner with medical device manufacturers and healthcare organizations to identify and mitigate risks across medical devices, embedded systems, and connected networks, supporting FDA premarket submissions, post-market surveillance, and security-focused design reviews. We pair rigorous technical testing with recognized third-party accreditation, aligned to FDA guidance, to help our clients secure what matters most. If CRA scope-mapping is on your list, get in touch.

Key dates at a glance

  • September 11, 2026 — Vulnerability-reporting obligations under Article 14 apply.
  • December 11, 2027 — Main CRA obligations apply.
  • In progress — Harmonized standards for secure development and vulnerability handling. No presumption of conformity until cited in the Official Journal.11
  • Pending — December 2025 Commission proposal to amend the MDR/IVDR: leaves the CRA carve-out untouched and adds device-side cybersecurity reporting using CRA definitions. Not adopted; not expected before 2027.

This is general information, not legal advice. Classification turns on a product’s specific intended purpose and architecture, and the law and guidance are still moving. Confirm determinations with qualified regulatory counsel.

References

  1. Recital (25): “Products with digital elements to which either of those Regulations apply should not therefore be subject to this Regulation.”
  2. MDR Annex I GSPR 17.2 and 17.4. The matching labelling duty is at MDR Annex I 23.4(ab). Sector guidance in practice: MDCG 2019-16, and IEC 81001-5-1 for the health software security lifecycle.
  3. Annex I Part I(2)(c) requires that vulnerabilities can be addressed through security updates; Part II(7) requires mechanisms to securely distribute them.
  4. MDR Annex I 17.4 (specify and disclose the minimum requirements the device needs from the network); Annex I 14.2(d) (the IT environment as something the device “operates and interacts” with).
  5. MDR Annex VIII Rule 11(a): Class IIa, IIb or III according to the consequences of the decisions informed by the software. IVDR has separate classification rules.
  6. Art. 14(1)–(4) and (7). The single reporting platform is established under Art. 16.
  7. Art. 13(17) adds a further constraint: the single point of contact must let users choose their preferred means of communication, and must not limit them to automated tools.
  8. Art. 13(5): due diligence when integrating third-party components, including free and open-source software. Art. 13(6): report a vulnerability found in an integrated component to the person or entity maintaining it.
  9. Art. 64(2): administrative fines up to EUR 15 000 000 or 2,5 % of total worldwide annual turnover for the preceding financial year, whichever is higher. Art. 13(21): corrective action, withdrawal, or recall.
  10. COM(2025) 1023, 16 December 2025. The proposed provisions are a new Art. 87a (MDR) and Art. 82a (IVDR).
  11. Standardization request M/606, addressed to CEN, CENELEC and ETSI. Delivery deadlines have themselves been subject to amendment; check the CRA’s Official Journal listing before relying on a standard.
Contact Us