The gray areas between the Cyber Resilience Act and your medical device

Where scope turns gray

The CRA applies to products with digital elements made available on the market in the course of a commercial activity, where the intended purpose or reasonably foreseeable use includes a direct or indirect data connection. Each element of that sentence is a place where a portfolio becomes unclear.

Date	What happens
10 Dec 2024	Regulation (EU) 2024/2847 entered into force.
11 Sep 2026	Article 14 reporting of actively exploited vulnerabilities and severe incidents begins.
11 Dec 2027	Product, manufacturer, and conformity obligations become generally applicable.

Made available commercially

Software applications, operating systems, embedded software, connected hardware, network appliances, software components, mobile and desktop applications, certain cloud-dependent functionality, and commercial open-source software all qualify as products with digital elements. Blind spot: free of charge does not mean outside commercial activity. Software supplied without a separate fee stays commercial where it supports a paid service, device, subscription, or data offering.

Connected, directly or indirectly

A connection may be physical or wireless, local or remote, mediated through another device, occasional, machine to machine, through an API, or through a gateway or cloud component. The product does not need to reach the public internet. Blind spot: software recorded as offline often is not. Installation, license verification, updates, synchronization, and export each create relevant connectivity.

Remote data processing is part of the product

Remote data processing forms part of the product where the manufacturer develops it or carries responsibility for it, and its absence would stop the product performing one of its functions. A manufacturer-controlled inference service, a backend authentication service, or a remote configuration service integral to operation sits inside the boundary. A corporate website or a generic external cloud service outside the manufacturer's responsibility does not, although NIS2, the GDPR, and contracts may still apply to it. Five questions settle the boundary: does the manufacturer develop it or carry responsibility for it, is it necessary for one or more product functions, is it supplied as part of the product offering, can the product perform those functions without it, and is the function within the intended or foreseeable use.

Article 2(2), and its limit

The CRA does not apply to products with digital elements to which Regulation (EU) 2017/745 or 2017/746 applies. Risk class is irrelevant: Class I to Class III, IVDR Class A to Class D, software or hardware, connected or local. The exclusion reaches the product only. It does not reach the portfolio, the platform, the brand, or the company.

A shared codebase, shared brand, shared cloud environment, or shared cybersecurity program does not make all modules subject to the same legislation.

Nine products around one device, and what each one gets wrong

Each row is a marketed offering, not a repository or a brand. The position is a starting hypothesis. The third column names the assumption that fails in review and the record that closes it.

Scenario	Likely position	The blind spot, and what closes it
Standalone medical device software	MDR applies. CRA excluded under Article 2(2).	Teams read the exclusion as portfolio-wide. Record it per product, and keep MDR cybersecurity, lifecycle, and PMS evidence current.
IVD software	IVDR applies. CRA excluded.	Analytical modules sold to laboratories outside the IVDR purpose need their own qualification.
Companion app that controls the device	Part of the device, a device itself, or an accessory. Where MDR applies, CRA is excluded.	The label companion app decides nothing. Qualify on function, then bring the app, interfaces, backend, and update path into the device risk file.
Companion app, non-medical functions only	Possibly not an MDR product or accessory. Assess the CRA on its own facts.	Free of charge and bundled in the same store listing do not remove commercial supply. Decide whether it is a separate product.
Cloud delivering the medical purpose	Excluded where the cloud functionality forms part of the MDR or IVDR product and is necessary to deliver its intended medical purpose.	Controlling a service through the device QMS does not by itself establish the exclusion. Document the regulated product boundary; separately supplied infrastructure, analytics, or platform functionality needs its own assessment.
General cloud platform, supplied separately	The independently marketed platform may be in CRA scope.	The same instance can be inside the device and a separate product. Split claims, documentation, support period, and reporting route.
Deployment appliance or gateway	Depends on whether it is part of the device, an accessory, or a general product.	Shipping with the device is not the test. Record whether it assists the medical function and whether it is also sold alone.
SDK or API for partners	May be a separately supplied product or component under the CRA.	Internal tooling opened to partners changes status quietly. Define versioning, support, disclosure, and integration duties.
Update or distribution service	Inside the device framework where integral. CRA may apply where sold as a general product.	Control update authenticity, integrity, rollback, release approval, and deployment evidence on either route.

One platform can carry a regulated diagnostic module, a non-medical workflow module, and an administrative dashboard. Each marketed configuration needs its own qualification. White labeling adds a further trap: a party that places a product under its own name becomes the manufacturer for CRA purposes. And a product on the market before 11 December 2027 can still be pulled in where it is substantially modified after that date and made available again, through a new network-facing function, a changed trust architecture, or a new intended purpose. A security update that reduces risk generally is not substantial. Document the assessment either way, because the labels patch and minor release decide nothing.

The clock starts at awareness, fifteen months before the rest of the CRA

Reporting applies before the main requirements do, so a manufacturer may still be building its technical documentation while already required to recognize and report qualifying events, including events affecting products already on the market.

Deadline	Actively exploited vulnerability	Severe incident affecting product security
24 hours	Early warning from awareness.	Early warning from awareness.
72 hours	Vulnerability notification.	Incident notification.
Final	14 days, once a corrective or mitigating measure is available.	One month from the 72-hour notification.

A theoretical vulnerability, a proof of concept, or a vulnerability in a component is not automatically active exploitation. Assess whether your product is affected and whether reliable evidence of malicious exploitation exists. An incident is severe where it negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions, or where it has led, or could lead, to malicious code being introduced or executed in the product or the user's networks and information systems. Scale, duration, affected markets, and operational impact belong in the impact assessment, not in the threshold.

Three blind spots on the clock

• Awareness is undefined until you define it. State which personnel create organizational awareness, how reports arrive, how service providers escalate, and who covers weekends. A process that waits for technical certainty misses 24 hours.
• Excluded product, in-scope neighbor. An event can start in an excluded device and land in a gateway, SDK, or platform that is not. Triage by affected product and version, not by team.
• One event, several clocks. The CRA, the MDR and IVDR, the GDPR, NIS2, and contracts each have their own triggers and deadlines. Use one internal event identifier across all assessments and keep the rationale for each route separate. A CRA severe incident may sit below the MDR health-harm threshold, and an MDR serious incident may involve no exploitation.

Eight assumptions that create blind spots

The claim	Why it does not survive review
"We are a medical device manufacturer, so the CRA does not apply to us."	The exclusion attaches to MDR and IVDR products, not to the company or the portfolio.
"Our product is CE marked, so the CRA is covered."	One CE mark, supported by a declaration that identifies each applicable act. Conformity is assessed per act.
"We hold ISO/IEC 27001, so the product is CRA compliant."	Organizational certification does not replace product-specific CRA evidence.
"It was sold before December 2027, so no CRA obligation applies."	Article 14 reporting applies from September 2026, and substantial modification can trigger more.
"The software runs in a hospital, so it is excluded."	Administrative and general-purpose software used in healthcare can remain in CRA scope.
"Every connected medical device must comply with both regimes."	The CRA excludes MDR and IVDR products. Cybersecurity duties remain under the MDR.
"The CRA requires publication of the full SBOM."	It requires machine-readable component and vulnerability documentation, covering at least top-level dependencies.
"The MDR revision has removed the exemption."	The December 2025 proposal would add an MDR and IVDR route for reporting through Eudamed. It does not remove the Article 2(2) exclusion, and as at 5 August 2026 the procedure is ongoing.

The regulatory applicability register

One controlled record per digital product, module, and component, with the rationale written down rather than assumed: product and version, intended purpose, claims and labeling, market status, economic operator role, MDR or IVDR qualification, accessory status, CRA status and rationale, other applicable legislation, CRA product category, Annex III or IV category, conformity assessment route, standards relied upon, whether a notified body is needed, support period, reporting contacts, approval, and review triggers.

Category decides the route. Most products use internal control. Important Class I products may use it only where harmonized standards, common specifications, or a certification scheme are fully applied, and important Class II and critical products take third-party routes. A gateway, network-management component, firewall, or operating system often lands in these categories, so record the Annex III or IV rationale against the technical descriptions in Implementing Regulation (EU) 2025/2392. CRA classes are unrelated to MDR classes. The support period is at least five years unless the product is reasonably expected to be in use for less time, with the end date clear at the time of purchase, and issued security updates stay available for at least ten years or the remainder of the support period where that is longer.

A medical device QMS is a strong operational foundation, and it still has to be extended to cover CRA product classification, support periods, SBOMs, vulnerability reporting, and declarations for independently in-scope products.

Seven questions about one connected product you supply today

Answer for a single marketed product rather than for the company. More than two answers of no indicates a position that is asserted rather than documented, which is where the gray areas become findings.

Summary and interpretation only, current as at 5 August 2026, and not legal advice. Applicability is decided for each product, module, and economic operator role on the applicable legislation and the intended purpose. Sources: Regulation (EU) 2024/2847, Regulations (EU) 2017/745 and 2017/746, the Commission practical CRA guidance of 27 July 2026, Implementing Regulation (EU) 2025/2392, MDCG 2019-16 rev.1, and COM(2025) 1023. The manufacturer retains responsibility for conformity.