Do Medical Devices Need Both CRA and MDR Identity Controls?

June 22, 2026 ·Gustav Poola ·

medical-device-identitycyber-resilience-actcramdrmedical-device-regulationidentity-of-thingsdevice-cybersecurityarticle-14nis2eidas

Medical devices regulated under MDR 2017/745 are currently exempt from the CRA's product requirements. The exemption is incomplete — wearables, companion apps, standalone software, and components sold separately may still fall under CRA. The December 2025 European Commission proposal would remove the exemption entirely. CRA Article 14 vulnerability reporting starts 11 September 2026.

Do Medical Devices Need Both CRA and MDR Identity Controls?

In our work integrating identity primitives into device-manufacturer security stacks, the CRA/MDR question lands on the engineering desk regularly. A Cologne-based mid-market medical-wearables manufacturer we work with — shipping continuous glucose monitor variants under MDR Annex IIa for the last six years — received a procurement request from a Dutch hospital chain in early 2026 asking for CRA-aligned vulnerability handling on the companion mobile app, with no implementation hint other than "consistent with CRA Article 14 + ENISA guidance". The engineering team's first reaction was that the wearable itself was MDR-exempt and the request must therefore be misdirected; the regulatory team's first reaction was that the companion app might fall outside the MDR boundary anyway. Resolving who was right took three weeks. The honest answer in 2026 sits at the intersection of three legal instruments, two implementing acts, and one open MDR amendment proposal. This post is the glossary that lets you read the answer, and the analysis that lets you act on it. The staff-identity layer hospitals running these devices have to defend under NIS2 is the topic of our earlier post on NIS2 hospital staff identity, and the EHDS data-side cross-border framework is in our EHDS Patient Summary post.

What does the CRA actually require for product identity?

That every product with digital elements placed on the EU market carries verifiable identity for the product itself, its software supply chain, and its security-update mechanism.

The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024 as the EU's first horizontal cybersecurity regulation for products with digital elements. The Act covers any product whose intended purpose includes data processing, network connection, or storage, sold or made available on the EU market. The compliance timeline has two key dates: Article 14 vulnerability and incident reporting obligations apply from 11 September 2026 (across all in-scope products regardless of when they were placed on the market), and full product conformity requirements apply from 11 December 2027 (European Commission — Cyber Resilience Act page).

The identity-related requirements sit in CRA Annex I. They include: a unique identifier for the product allowing it to be traced through the supply chain; a software bill of materials (SBOM) documenting all third-party components; a digitally-signed mechanism for delivering security updates that the receiving device can verify; and a process for documenting the identity of the manufacturer, importer, and distributor at conformity assessment. These are the "product identity" controls the CRA actually defines. A 2026-compliant product can answer: who made me, what software am I running, who signed the update I just installed.

What this is not is identity controls for the user of the device. CRA's identity language is about the device-side identity chain — manufacturer, components, update authority. User identity is downstream of this and not directly in CRA's scope.

What does the MDR say about device identity?

Considerably more about regulatory traceability and considerably less about cybersecurity primitives — historically.

The Medical Device Regulation (Regulation (EU) 2017/745) requires a Unique Device Identifier (UDI) on every medical device placed on the EU market, registered in the EUDAMED database. The UDI carries traceability information — manufacturer, device model, lot or serial, expiry date — and is intended for clinical safety and post-market surveillance rather than cybersecurity. The IVDR (Regulation (EU) 2017/746) mirrors this for in-vitro diagnostic devices. The conformity assessment under MDR also requires technical documentation, Notified Body involvement for higher-risk classes, and ongoing post-market surveillance.

The cybersecurity language in MDR has historically been thin. Annex I (General Safety and Performance Requirements) requires devices to be designed to minimise risks arising from cybersecurity vulnerabilities, but the operationalisation has been left to MDCG guidance and to the manufacturer's risk-management process under ISO 14971. There is no MDR equivalent to CRA's SBOM requirement, no MDR-defined signed-update mechanism, no MDR-defined manufacturer identity chain in the same shape as CRA Annex I lays out.

The honest reading is that MDR's identity controls are clinically rigorous (UDI, EUDAMED, Notified Body) and cybersecurity-light. CRA's identity controls are cybersecurity-rigorous (SBOM, signed updates, manufacturer chain) and clinically agnostic. Until the December 2025 amendment proposal, these were genuinely orthogonal regimes covering overlapping device populations.

Where do the two overlap — and where do they leave gaps?

The legal overlap is currently exempt, but in practice the gap covers a wider device population than the exemption text suggests.

Article 2 of the CRA exempts products subject to the MDR and IVDR from the CRA's product requirements (CRA Article 2). The exemption is intentional — the EU did not want to impose two parallel conformity-assessment regimes on the same device. But the exemption has structural limits. The five recurring gaps I see integrators hit in our work:

Wearables and connected devices not classified as medical devices — e.g., a wellness-tracking smartwatch sold alongside a clinical-grade glucose monitor. The watch is CRA-scope; the monitor is MDR-scope.
Companion apps and software tools that ship with medical devices — a mobile app pairing with a connected diagnostic device. The app may be CRA-scope independently if not certified as a Software-as-a-Medical-Device (SaMD).
Standalone software components — analytics platforms, dashboards, telemetry receivers. CRA-scope when not part of the regulated medical-device product.
Components sold separately — replacement modules, accessory sensors. CRA-scope individually even if installed into MDR-regulated devices.
Cloud and platform-side components — the manufacturer's backend, cloud APIs, update infrastructure. CRA-scope as platforms-as-services.

NIS2 (Directive (EU) 2022/2555) sits over both. Medical device manufacturers crossing NIS2 size thresholds are essential entities under Annex I and have to implement the Article 21(2) measures regardless of which product-regulation they ship under (European Commission — CRA page). For the integrator's engineering desk, this means the question "are we CRA-scope or MDR-scope" is incomplete — the actual question is "what cybersecurity obligations apply across our portfolio, layered through CRA, MDR, NIS2, and the upcoming MDR amendment".

If you sit with all three regulations side-by-side, the gap that emerges is consistent: the manufacturer-identity, software-supply-chain-identity, and update-authority-identity controls that CRA explicitly defines for non-medical products are not formally defined in MDR for medical products. In practice, MDR-regulated manufacturers ship them anyway — Notified Bodies have been increasingly requiring SBOM and signed-update evidence in technical documentation reviews since 2023 — but the requirement is informal until the MDR amendment lands.

What the December 2025 MDR amendment proposal changes

It collapses the exemption — and turns the orthogonal regimes into a layered one.

The European Commission published in December 2025 a proposal to amend MDR and IVDR that would remove the CRA exemption for medical devices entirely. The amendment would add cybersecurity explicitly to the General Safety and Performance Requirements in Annex I of both MDR and IVDR, aligning the medical-device cybersecurity baseline with the CRA's horizontal framework. The amendment is currently in the European Council and Parliament review cycle; final adoption is expected in 2026-2027, with phased application following.

What's actually in scope after the amendment is adopted — assuming the current text holds — is the same SBOM, signed-update, manufacturer-identity chain that CRA Annex I defines, applied to MDR-regulated devices. The Notified Body assessment cycle would then incorporate the cybersecurity criteria explicitly rather than as informal expectations. Manufacturers who shipped under MDR alone will have to add the CRA-style identity-chain documentation to their conformity dossier.

What we tell medical device integrators when they ask about CRA scope in 2026 is to ship the CRA-style identity controls now, regardless of whether their device is currently exempt. The reasoning is operational, not legal. The amendment is on the EU's books with significant political support, the Notified Bodies are already asking for the same evidence informally, and the engineering work to add SBOM + signed updates + manufacturer chain to an existing device pipeline is non-trivial. Doing it under time pressure when the amendment lands is harder than doing it now.

The most under-stated implication of the September 2026 Article 14 deadline is that vulnerability reporting obligations apply to in-scope products already on the market — the manufacturer of a wellness wearable shipped in 2023 has to be ready to report vulnerabilities by 11 September 2026, regardless of whether the product was placed on the market before the CRA was even adopted. Retrofitting vulnerability handling onto deployed devices is the kind of project that takes more than a quarter; planning has to start now.

For the device-identity layer in particular — the part where the chip-and-firmware identity of the device itself gets bound to a manufacturer-signed update chain — the IdentiGate angle sits in the Identity of Things product and connects to the broader cross-border identity primitives we ship as the Identity Verification product. We are not a CRA conformity assessment body and we do not issue CE marks; we sit at the foundation-layer identity primitives that CRA and the upcoming MDR amendment both depend on but do not specify cryptographically.

The architectural reading is straightforward. CRA and the amended MDR will both require a verifiable device-identity chain. The chain has to be cryptographically anchored at the manufacturer, propagated through the firmware-signing pipeline, and verifiable by any party in the supply chain or end-of-life recycler. That's the layer beneath the conformity-assessment paperwork. Manufacturers who treat the conformity assessment as the primary procurement and the identity primitive as an afterthought will find themselves rebuilding the identity layer when the assessment asks for it.

Sources

Primary — CRA and MDR/IVDR

Primary — adjacent EU cybersecurity framework

Primary — clinical / cybersecurity standards

About the author

Gustav Poola is co-founder of IdentiGate. He focuses on the technical architecture of passport-chip identity verification, advanced electronic signature production under eIDAS, and the engineering of identity flows that survive regulator and auditor walk-back.

The signature carries the burden of proof — but the burden falls back on whoever relied on it if the evidence chain behind the signature isn't complete. Under eIDAS Article 25(2), Qualified Electronic Signatures presume authenticity unless the challenger rebuts it. For Advanced signatures, the party asserting the signature has to demonstrate identity binding, integrity, and time — and courts have been consistent since 2020 that thin proofing evidence loses the case.

Strictly speaking, digital signatures don't encrypt anything — they use asymmetric cryptography to sign a hash of the data. The signer's private key transforms the hash into a signature; the corresponding public key verifies it. In 2026 production: RSA-PSS with SHA-256 (RFC 8017), ECDSA over P-256 or P-384 (RFC 6979), and Ed25519 (RFC 8032). ETSI TS 119 312 sets which cryptographic suites are acceptable for AdES, and the post-quantum migration is starting to reshape the algorithm shortlist through 2030.

Three things stacked in the right order under eIDAS Article 25: non-discrimination in principle for any electronic signature, equivalence to a handwritten signature only for Qualified Electronic Signatures under Article 25(2), and successful validation under the Article 32 procedure. The gap that costs cases in court is between 'the signature exists' and 'the signature validates against Article 32 requirements' — and the identity-proofing under the signing certificate is where most legal-validity claims quietly break.