Reg (EU) 2024/2847Generate dossier — €149
LIVE — Enforcement tracker · Deadline dashboard · Transposition status — Updated weekly from EUR-Lex, Safety Gate, OEIL & 12 official sourcesView regulatory intelligence →

Your software is used in hospitals, clinics or health systems, but it is not classified as a medical device under Regulation (EU) 2017/745 or Regulation (EU) 2017/746. Article 2(2) of the Cyber Resilience Act excludes medical devices from CRA scope. Your product is not a medical device. The CRA applies to it in full — every paragraph of Article 13, every element of Annex VII.

The CRA's healthcare exclusion is narrower than it appears. Art. 2(2)(a) excludes products subject to Regulation (EU) 2017/745 (medical devices). Art. 2(2)(b) excludes products subject to Regulation (EU) 2017/746 (in vitro diagnostic devices). Everything else — hospital information systems, clinical decision support that does not qualify as a medical device, patient scheduling platforms, health data analytics, EHR middleware, wellness apps — falls within CRA scope as products with digital elements under Art. 3(1). If your product has a data connection and you market it in the EU, Art. 13 manufacturer obligations apply. CRACheck generates the 8-document technical file under Art. 31 and Annex VII. €149 per product. 15-25 minutes. Patient-adjacent data architecture stays in your browser.

Generate CRA dossier — €149Free: check your product classification

€149 one-time · 8-document ZIP · 15–25 minutes · Browser-side

Built on Regulation (EU) 2024/2847 · Art. 31 + Annex VII · 8 PDF documents · 100% browser-side

Key figures

Art. 2(2)
CRA excludes only medical devices under Reg. 2017/745 and 2017/746
Art. 13
Full manufacturer obligations for non-MDR healthcare software
€15M
Maximum fine under Art. 64(2) — no MDR exclusion applies to the fine

How to proceed

1
Confirm your product is NOT a medical device
If your product is classified under Regulation (EU) 2017/745 (MDR) or 2017/746 (IVDR), Art. 2(2) excludes it from the CRA. If it is not classified as a medical device, the CRA applies regardless of the healthcare context. The MDR/IVDR classification is the dividing line — not the deployment environment.
2
Classify under CRA categories
Most healthcare IT software falls under Default. If your product includes identity management or access control for clinical systems, it may be Important Class I (Annex III item 1). Network management systems for hospital infrastructure fall under Annex III Class I item 6.
3
Conduct the cybersecurity risk assessment
Art. 13(2)-(3): the assessment must account for healthcare-specific risks — patient data confidentiality, system availability in clinical workflows, integrity of clinical-adjacent data.
4
Address Annex I Part I essential requirements
Annex I Part I point (2)(e) requires confidentiality through encryption. Point (2)(f) requires integrity protection. Point (2)(h) requires availability even after incidents. For healthcare software, these map directly to patient safety and data protection concerns.
5
Compile Art. 31 technical documentation
Annex VII covers system architecture, vulnerability handling, SBOM, risk assessment and test reports. Hospital procurement will increasingly require this documentation alongside existing cybersecurity questionnaires.
6
Prepare ENISA reporting
Art. 14 from September 2026. A vulnerability in hospital-deployed software has immediate patient-safety implications — the 24h notification deadline is operationally critical in this sector.

Common mistakes

EXCLUSION MISAPPLICATION

Assuming all healthcare software is excluded under Art. 2(2)

Art. 2(2)(a)-(b) of Regulation (EU) 2024/2847 excludes only products subject to Regulation (EU) 2017/745 (MDR) or 2017/746 (IVDR). Hospital IT systems, clinical analytics, scheduling platforms and health data middleware are not medical devices under MDR. The CRA applies to them in full.

DATA SENSITIVITY UNDERESTIMATION

Treating CRA cybersecurity as a generic compliance exercise in healthcare

Annex I Part I point (2)(e) of Regulation (EU) 2024/2847 requires encryption of data at rest and in transit. In healthcare, this includes patient-identifiable data, clinical workflow data and access credentials. A cybersecurity risk assessment under Art. 13(2) that does not specifically address healthcare data sensitivity is incomplete.

AVAILABILITY GAP

Not prioritising availability requirements for clinical-facing software

Annex I Part I point (2)(h) requires availability protection even after incidents. For software deployed in clinical workflows — even if not a medical device — availability failures can disrupt care delivery. A risk assessment that omits availability is missing one of the Annex I essential requirements.

What the ZIP contains

8 PDF documents generated from your data. Each cites the specific article of Regulation (EU) 2024/2847 it complies with.

1

Product Classifier

Confirms that your product falls within CRA scope (not excluded under Art. 2(2)) and identifies the category: Default or Important Class I if identity/access management is a core function.

2

Technical Documentation

Art. 31 and Annex VII documentation structured for healthcare IT: system architecture, data flows, API integrations with hospital systems, authentication mechanisms.

3

Risk Assessment

Cybersecurity risk assessment per Art. 13(2)-(3) covering healthcare-specific vectors: patient data exposure, clinical workflow disruption, integration point vulnerabilities, medical device interoperability risks.

4

User Information

Annex II information adapted for hospital IT departments: secure deployment in clinical environments, configuration for data protection, support period, vulnerability reporting.

5

Declaration of Conformity

EU Declaration per Art. 28 and Annex V for the healthcare software product.

6

CVD Policy

Coordinated vulnerability disclosure policy aligned with healthcare sector responsible disclosure practices and CERT coordination.

7

Notification Template

ENISA notification template per Art. 14 with healthcare urgency context.

8

Obligations Calendar

Key dates with healthcare procurement cycles: Art. 14 from September 2026, full enforcement December 2027, hospital contract renewal windows.

See before you buy — Download sample dossier (PDF, fictional company) — Real structure, real articles, real format. Fictional data.

Generated from your data, in your browser. No data leaves your device.

What you pay

🧾 HEALTHCARE IT COMPLIANCE CONSULTANCY
CRA gap analysis for medical-adjacent software
€12,000-30,000 per product
10-20 weeks
Requires sharing system architecture with consultant
Report-based — does not produce Art. 31 file
Re-engagement per software version
✓ CRACHECK — ART. 31 DOCUMENTATION
8-document technical file for non-MDR healthcare software
€149 per product
15-25 minutes
Patient-adjacent architecture stays in your browser
Feeds hospital procurement reviews
30-day edit window, 10 regenerations
Permanent PDF

Two layers

● LAYER 1 — DOCUMENTATION · CRACHECK

The CRA documentation layer

CRACheck generates the Art. 31 and Annex VII documentation for your healthcare software product that is not classified as a medical device. The output addresses cybersecurity requirements relevant to healthcare deployment: data confidentiality, integrity, availability and vulnerability handling. Eight documents per product.

∅ LAYER 2 — NOT INCLUDED

What CRACheck does not cover

CRACheck does not determine whether your product qualifies as a medical device under MDR (Regulation (EU) 2017/745). That classification determines CRA scope under Art. 2(2) and must be assessed separately. CRACheck does not produce MDR technical documentation, clinical evaluation reports, or notified body submissions. It does not perform security testing on hospital-integrated systems. It does not conduct GDPR data protection impact assessments.

If your product is not a medical device, the CRA applies. CRACheck produces the CRA documentation. MDR classification is a separate question with separate tools.

Enforcement regime

📅
11 September 2026 — Art. 14 reporting

A vulnerability in hospital-deployed software triggers the 24h ENISA early warning. In healthcare contexts, the operational urgency of reporting exceeds the regulatory minimum.

⚖️
11 December 2027 — Full CRA enforcement

Healthcare software products on the EU market must have Art. 31 documentation. Hospital procurement will require this as standard evidence in supplier cybersecurity assessments.

🔒
Art. 64(2) — €15M or 2.5% of global turnover

No exemption for healthcare-adjacent software. The MDR exclusion under Art. 2(2) does not extend to CRA penalties — it determines scope, not penalty severity.

Alternatives

CriterioHealthcare compliance consultantInternal IT security teamMDR-only approachCRACheck
Price€12K-30KStaff timeDoes not cover CRA€149 per product
CRA Art. 31 coverageReport, not fileDepends on expertiseNone8-document technical file
Healthcare-specificYesPartiallyMDR onlyYes — healthcare risk context
Data stays with youShared with consultantInternalN/A100% browser-side
CRACheck€149YesHealthcareBrowser-side

Healthcare software suite with multiple modules? Document each one.

Pack 10: €99 per product. Pack 30: €79 per product. For healthtech companies with multi-module platforms deployed across EU hospitals, contact us.

Request volume pricing
Commercial enquiries via hello@solidwaretools.com

What CRACheck guarantees and what it does not

CRACheck generates a structured document set according to Art. 31 and Annex VII of Regulation (EU) 2024/2847 based on the information you provide. The accuracy of that information — including system architecture, data flows and security mechanisms — is your responsibility as manufacturer.

We guarantee that the document structure follows Art. 31 and Annex VII and that the legal references cited are correct. We do not determine whether your product is a medical device under MDR, nor do we guarantee acceptance by a hospital procurement process or market surveillance authority.

CRACheck is not legal advice. For MDR classification and the CRA/MDR boundary under Art. 2(2), consult a qualified health technology regulatory lawyer.

Frequently asked questions

How do I know if my software is a medical device or not?
Regulation (EU) 2017/745 (MDR) Art. 2(1) defines a medical device based on intended purpose: diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease. If your software's intended purpose falls within this definition and the manufacturer makes a medical claim, it is likely a medical device under MDR and excluded from CRA scope under Art. 2(2)(a). If it is general-purpose healthcare IT — scheduling, analytics, data management — without a medical intended purpose, the CRA applies. This classification must be assessed independently of CRACheck.
Can the CRA and MDR apply simultaneously?
No. Art. 2(2)(a) of Regulation (EU) 2024/2847 excludes products to which Regulation (EU) 2017/745 applies. If your product is a medical device under MDR, the CRA does not apply. If it is not, the CRA applies. The two are mutually exclusive for a given product.
Our product interfaces with medical devices. Does that change CRA scope?
No. Interfacing with medical devices does not make your product a medical device under MDR. Your product's MDR classification depends on its own intended purpose, not on the devices it connects to. If your middleware is not itself a medical device, the CRA applies to it even if it transmits data from regulated medical devices.
Will hospitals require CRA documentation in procurement?
Hospital procurement increasingly includes cybersecurity evidence requirements. DORA Art. 28 (for hospital systems classified as financial infrastructure) and NIS2 (for hospitals as essential entities under healthcare) already require supplier security assessments. CRA Art. 31 documentation provides a standardised evidence format that procurement teams can reference.
Is this a subscription?
No. One-time payment. The licence includes 30 days of editing and 10 regenerations. The downloaded PDF is yours permanently.
Can I request a refund?
Under Art. 16(m) of Directive (EU) 2011/83, activating the licence constitutes express consent for immediate generation of digital content, waiving the 14-day withdrawal right. Refunds are only processed for reproducible technical failures.
What if the regulation changes?
If Regulation (EU) 2024/2847 is amended during your licence window, you can regenerate the documentation using the updated version of the generator at no additional cost.
⚠️ Important notice: CRACheck is a self-assessment documentation tool, not legal advice and not a third-party audit. The document under Article 31 and Annex VII of Regulation (EU) 2024/2847 is generated from your input data. You are responsible for the accuracy of the data you provide. CRACheck does not replace a qualified professional assessment.

Not a medical device? Then the CRA applies. Document it.

Art. 2(2) excludes MDR/IVDR devices. Everything else in healthcare IT falls under the CRA. Eight documents. €149 per product. Browser-side.

€149 one-time
8-document ZIP · 15-25 min · Art. 31 + Annex VII · 100% browser-side · Permanent PDF
Generate Technical Documentation
✓ Last regulatory check: 1 May 2026 · No substantive changes detected · View history