Most medical device manufacturers believe CRA medical device compliance doesn’t apply to them. They’re half right. And that’s the dangerous part.
CRA Medical Device Exemption: The Exposure It Creates
Medical devices regulated under MDR and IVDR are explicitly excluded from the CRA. Your embedded device software – the part that qualifies as a medical device – stays under IEC 62304, MDR Annex I, and related cybersecurity requirements.
But your device doesn’t operate alone.
It connects to a companion app. It talks to a cloud dashboard. It receives firmware updates through an update server. It transmits data over WiFi or Bluetooth.
Each of those components may fall under a different regulation. And most of them are not exempt.
CRA, MDR, and RED: Three Regulations for One Medical Device
MDR / IVDR regulates the medical device itself.
The Radio Equipment Directive (RED) regulates internet-connected radio equipment – cybersecurity requirements under Articles 3.3(d), (e), and (f) became mandatory on August 1, 2025.
The Cyber Resilience Act (CRA) regulates products with digital elements – including companion apps, cloud services, and update infrastructure that aren’t classified as medical devices.
Your device may be exempt. Your ecosystem is not.
Important exception: even under the current CRA exemption, medical device wearables (body-worn devices) must fulfill CRA requirements. The exemption is narrower than many manufacturers assume.
September 11, 2026: The Deadline Nobody’s Preparing For
Full CRA enforcement starts December 11, 2027. But vulnerability reporting obligations under Article 14 begin on September 11, 2026.
From that date, manufacturers of in-scope products must:
- Submit an early warning to ENISA and national CSIRTs within 24 hours of becoming aware of an actively exploited vulnerability
- Provide a detailed vulnerability notification within 72 hours
- Submit a final report no later than 14 days after a corrective measure is available
This isn’t a documentation exercise. It’s an operational capability you either have or you don’t.
Note for SMEs: the CRA provides that microenterprises and small enterprises may not be fined for failures to meet the 24-hour reporting deadline. However, the reporting obligation itself still applies – and the operational infrastructure needed to detect and assess vulnerabilities must still be in place.
A Scenario That Can Happen
A critical OpenSSL vulnerability is actively exploited in the wild.
Your cloud dashboard runs OpenSSL 1.1.1. Your companion app uses a shared library that depends on it. Your OTA update server hasn’t been audited in 18 months.
Can you – right now – answer these questions?
- Which deployed products are affected?
- Is the vulnerability exploitable in your specific configuration?
- Can you notify authorities within 24 hours?
- Can you deploy a secure patch to your entire installed base?
If not, you’re not ready for September 2026.
The Exemption May Not Last
In December 2025, the European Commission published a proposal to amend MDR and IVDR that would remove the CRA exemption for medical devices entirely. Under this proposal, cybersecurity would be explicitly added to the general safety and performance requirements (GSPR) in Annex I of the MDR and IVDR, and medical devices would no longer be excluded from the CRA.
The proposal also introduces new obligations for medical device manufacturers to report actively exploited vulnerabilities and severe cyber incidents to national CSIRTs and ENISA – mirroring CRA Article 14 requirements.
This is a Commission proposal, not yet adopted. It requires European Parliament and Council approval, which typically takes 12–24 months. But the direction is clear: cybersecurity obligations for medical device manufacturers are expanding, not contracting.
Whether the exemption stays or goes, the engineering infrastructure you need is the same: SBOM, CVE monitoring, OTA updates, and incident response capability.
What CRA Compliance Means For Your Engineering Team
Across MDR, RED, and CRA, regulators are converging on one principle: manufacturers must know what is in their software, monitor it continuously, and patch it fast.
This isn’t solved by hiring a regulatory consultant for two weeks. It requires engineering infrastructure:
- A build-derived Software Bill of Materials (SBOM) – not a spreadsheet, a live artifact from your actual build pipeline
- Continuous CVE monitoring matched against your deployed binaries
- Secure over-the-air (OTA) update capability
- Audit-ready documentation that connects your SBOM to your risk analysis
- Qualified suppliers under ISO 13485 for critical software components
Cybersecurity compliance is now an architectural decision, not a regulatory afterthought.
The Real Question
The question isn’t whether the CRA applies to your medical device today.
The question is whether your full product ecosystem – device OS, companion app, cloud backend, update infrastructure – can withstand regulatory scrutiny after September 2026. And whether you’ll be ready when the exemption narrows further or disappears entirely.
The CRA vulnerability reporting deadline is September 11, 2026. Count backward from there – that’s what you have.
Regulatory framework described as of February 2026.
Are You CRA-Ready? Find Out in 5 Minutes.
We’ve published a detailed whitepaper with a self-assessment checklist covering all three regulations (MDR, RED, CRA), a component classification guide, penalty amounts, and a 90-day action plan to reach operational readiness before September 2026.
Can’t Wait 90 Days?
We deliver the OS layer that your CRA compliance depends on.
SBOM · CVE monitoring · OTA updates · IEC 62304 docs — in 30 days.
BOOK A SCOPING CALL →ISO 13485 certified (software development & cybersecurity) · l4b-software.com
**This article is provided for general informational purposes only and does not constitute legal or regulatory advice.
