Cyber Resilience Act readiness for healthtech products
The EU Cyber Resilience Act introduces lifecycle cybersecurity requirements for commercially supplied software and connected hardware. Reporting of actively exploited vulnerabilities and severe security incidents begins on 11 September 2026, followed by the main product and conformity requirements on 11 December 2027. Asteron first determines whether the CRA applies to your product, which economic-operator role your company holds and whether an exclusion or other EU product regime changes the route, then scopes the security, vulnerability-handling, documentation and reporting work actually required.
- CRA Applicability Screening - EUR 1,900
- Product and economic-operator role mapped
- September 2026 reporting readiness
- December 2027 implementation roadmap
What is the Cyber Resilience Act?
The Cyber Resilience Act is an EU product-security regulation for hardware and software products with digital elements made available on the European market.
It requires manufacturers to address cybersecurity throughout design, development, production, delivery and maintenance. Products must undergo the applicable conformity assessment, carry appropriate information for users and remain supported against vulnerabilities for a defined support period.
Unlike NIS2, which primarily governs organisational cybersecurity through national laws, the CRA applies directly across the EU and focuses on products placed on the market.
Does the CRA apply to your product?
A product-level assessment is essential. A company may have an MDR-regulated medical application excluded from CRA while a separate customer portal, integration gateway, device-management tool or non-medical product remains in scope. Being a healthtech or medical-device company does not create a blanket exemption.
Economic-operator roles
Most Asteron clients developing and selling their own software will be assessed as manufacturers.
Manufacturer
Places a product on the market under its own name or trademark and holds the primary CRA responsibility, even when development is outsourced.
Importer
Places a product from a non-EU manufacturer on the EU market and must verify that the manufacturer completed the required conformity work.
Distributor
Makes a product available without changing it and must verify required markings, information and operator details.
Authorised representative
Performs specific documented tasks on behalf of a non-EU manufacturer but does not automatically assume every manufacturer obligation.
CRA timeline
- 10 December 2024
Entered into force
The transition period began.
- 11 June 2026
Conformity-assessment infrastructure
Provisions concerning notification of conformity assessment bodies began to apply.
- 11 September 2026
Reporting obligations
Manufacturers must report actively exploited vulnerabilities and severe incidents affecting product security.
- 11 December 2027
Main CRA requirements
Product-security, vulnerability-handling, documentation, conformity-assessment and market obligations become fully applicable.
Products placed on the market before 11 December 2027 are generally subject to the main CRA requirements only if they undergo a substantial modification after that date. The reporting obligations, however, also apply to in-scope products already made available before full application.
Reporting from September 2026
Reports are made through the CRA Single Reporting Platform and addressed to the relevant CSIRT, with information also made available to ENISA under the regulatory process.
- Step 1
Within 24 hours
Submit an early warning after becoming aware of an actively exploited vulnerability or severe incident.
- Step 2
Within 72 hours
Provide the full notification with available information about the product, vulnerability or incident and its impact.
- Step 3
Final report
For an actively exploited vulnerability, within 14 days of a corrective or mitigating measure becoming available. For a severe incident, within one month of the 72-hour notification.
The reporting workflow must distinguish:
- - A vulnerability from an actively exploited vulnerability
- - A general security incident from a severe incident affecting product security
- - Product reporting under CRA from GDPR, NIS2, customer and medical-device reporting duties
- - Initial facts from conclusions that require further investigation
Product-security requirements
The cybersecurity risk assessment must inform design decisions and remain part of the technical documentation. It is not a generic company risk register.
Secure product design
- - Product-specific cybersecurity risk assessment
- - Security by design and by default
- - Protection against unauthorised access
- - Confidentiality, integrity and availability
- - Reduced attack surface and unnecessary data exposure
- - Resilience against denial-of-service and other relevant threats
- - Security logging and monitoring capabilities where appropriate
Lifecycle vulnerability handling
- - Identification and documentation of product components
- - Software bill of materials where required
- - Coordinated vulnerability-disclosure process
- - Security updates during the support period
- - Timely remediation of vulnerabilities
- - Testing and review of security updates
- - Public contact point for vulnerability reporting
- - CRA regulatory-reporting workflow
Support periods and security updates
Manufacturers must define how long the product will receive security support and communicate the end date to users.
The support period should reflect the expected use of the product, its dependencies, market expectations and the time users reasonably rely on it. For healthtech products, short support commitments can conflict with hospital procurement, clinical workflows and long deployment cycles.
The organisation therefore needs a defensible approach to:
- - Dependency and end-of-life management
- - Security-update ownership
- - Backward compatibility
- - Customer notification
- - Unsupported versions
- - Vulnerability triage across maintained releases
- - Evidence that updates were tested and distributed
Product classification and conformity assessment
Most ordinary applications remain in the default category. A product must not be labelled important or critical merely because it processes health data.
Independent conformity assessment
Most products do not automatically require an external notified body. Where CRA classification does require independent assessment:
- - The conformity assessment is performed by an appropriately notified third party.
- - The client contracts and pays that body directly.
- - Its fees are not included in Asteron’s implementation proposal.
- - Asteron prepares the product, documentation and evidence but does not issue the independent conformity decision.
- - Keeping preparation and independent assessment separate avoids a conflict of interest.
CRA, MDR, IVDR and NIS2
Exclusion from CRA does not remove cybersecurity duties under MDR, IVDR or other applicable legislation. Conversely, ISO 27001 certification does not replace CRA product conformity.
How Asteron delivers CRA readiness
CRA Applicability Screening - EUR 1,900
Identify the product, commercial model, connectivity, operator role and possible exclusions.
Product and role scoping
Define the product boundary, associated remote processing, components and economic operators.
Classification and route
Determine the likely CRA category and conformity-assessment path.
Security baseline
Map cybersecurity risks and essential product requirements to the development lifecycle.
Vulnerability and reporting readiness
Establish intake, triage, remediation, disclosure, updates and regulatory reporting.
Documentation and validation
Prepare the evidence structure, test representative workflows and define remaining work.
Deliverables
Applicability and product scope
- - CRA applicability screening outcome
- - Product and component boundary
- - Economic-operator role map
- - MDR or IVDR exclusion analysis where relevant
- - Preliminary CRA product classification
- - Conformity-assessment route
- - Prioritised readiness roadmap
Implementation readiness
- - CRA requirements and evidence matrix
- - Product cybersecurity risk-assessment structure
- - Secure-development and release controls
- - Vulnerability-handling process
- - Support-period and update model
- - CRA incident-reporting workflow
- - Technical-documentation structure
- - Readiness evidence pack
CRA applicability and readiness pricing
The screening covers one defined product or closely related product family. It determines whether the product is likely in scope, which economic-operator role applies, whether an exclusion requires deeper analysis and which deadline requires attention.
The screening ends with one of three clear outcomes:
- - Likely outside CRA scope
- - Likely in scope and ready for a scoped implementation proposal
- - Uncertain or overlapping scope requiring specialist legal or regulatory analysis
Implementation is scoped individually after the screening. Price depends on the number of products, product category, components, development maturity, support model, existing technical documentation, reporting readiness and required conformity-assessment route.
Prices exclude VAT where applicable.
What remains separate
- - Formal legal opinions or binding applicability decisions
- - Product-development and technical remediation
- - Source-code review
- - Penetration testing
- - Continuous vulnerability management
- - Live incident handling
- - SBOM or vulnerability-scanning software licences
- - MDR or IVDR technical-documentation projects
- - Fees charged by a CRA notified body
- - Representation before market-surveillance authorities
- - Work for products outside the agreed scope
Responsibilities
Asteron
- - Assess likely CRA applicability
- - Define product and evidence scope
- - Map requirements into practical lifecycle controls
- - Prepare vulnerability and reporting workflows
- - Structure readiness and conformity evidence
Your organisation
- - Confirm product purpose, architecture and commercial model
- - Provide component and dependency information
- - Implement and operate technical controls
- - Approve product risks and support commitments
- - Maintain security updates and vulnerability handling
- - Obtain legal advice where applicability remains uncertain
- - Sign declarations and make formal regulatory submissions
Frequently asked questions
What products does the Cyber Resilience Act cover?
The CRA covers products with digital elements - hardware and software commercially made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. Remote data-processing solutions required for the product to perform a function form part of the product’s scope. Products regulated under certain other EU regimes, such as MDR and IVDR, are excluded to avoid duplication.
Does CRA apply to SaaS and web applications?
Software products supplied commercially and made available on the EU market can fall within the CRA. Pure services are outside the product-focused scope, but the boundary between a service and a product with digital elements is not always obvious. A product-level assessment is required to determine whether a given SaaS offering, on-premise application or component is treated as a CRA product.
Are medical devices excluded from CRA?
Medical devices regulated under MDR and IVDs regulated under IVDR are excluded from CRA for those regulated products. This avoids duplicative cybersecurity conformity between the two regimes. MDR and IVDR cybersecurity duties continue to apply, and the exclusion does not extend to unrelated products or accessories.
Can part of a medical-device ecosystem still fall under CRA?
Yes. A company may have an MDR-regulated medical application excluded from CRA while a separate customer portal, integration gateway, device-management tool or non-medical product remains in scope. Applicability must be assessed product by product, not company by company.
When do CRA reporting obligations begin?
The reporting obligations for actively exploited vulnerabilities and severe incidents affecting product security apply from 11 September 2026. The main product-security, vulnerability-handling, documentation and conformity requirements apply from 11 December 2027.
What must be reported within 24 and 72 hours?
Within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, the manufacturer submits an early warning. Within 72 hours, the manufacturer provides the full notification with available information about the product, vulnerability or incident and its impact. Reports are submitted through the CRA Single Reporting Platform to the relevant CSIRT.
When do the full CRA requirements apply?
The main CRA requirements - product security, vulnerability handling, technical documentation, conformity assessment and market obligations - apply from 11 December 2027. Products placed on the market before that date are generally subject to the main requirements only if they undergo a substantial modification afterwards. Reporting obligations also apply to in-scope products already on the market.
Does every product require a notified body?
No. Most ordinary products remain in the default category and manufacturer self-assessment is generally available. Important products in Class II and critical products typically require third-party conformity assessment. Being a healthtech or health-data product does not automatically place a product in a higher category.
What is an important or critical product?
Important products are those the CRA lists as having a higher cybersecurity risk profile, split into Class I and Class II. Critical products are subject to the strictest route and may require an applicable recognised certification. Classification depends on the product’s core functionality, not on the sector in which it is used.
How long must security updates be provided?
The manufacturer defines a support period reflecting the expected use of the product, its dependencies and users’ reasonable expectations, and communicates the end date. Short support commitments can conflict with hospital procurement and clinical deployment cycles. The support model must be defensible against actual customer use.
Does ISO 27001 establish CRA compliance?
No. ISO 27001 is an organisation-level information-security management system and does not replace CRA product conformity. It can, however, provide reusable governance and controls that support the CRA lifecycle, secure-development and vulnerability-handling work.
How does CRA differ from NIS2?
CRA is a product-security regulation that applies directly across the EU to products with digital elements. NIS2 is an organisational-cybersecurity directive implemented through national laws and focused on qualifying entities in essential and important sectors. A company can be affected by both, or by only one, depending on its products and its entity status.
What does the CRA applicability screening (EUR 1,900, defined scope and output) include?
The screening covers one defined product or closely related product family, determines whether it is likely in scope, identifies the applicable economic-operator role, checks whether an exclusion needs deeper analysis and highlights the CRA deadlines that matter. It ends with one of three clear outcomes: likely out of scope, likely in scope, or uncertain and requiring specialist legal or regulatory analysis.
How much does CRA implementation cost?
CRA implementation is scoped individually after the CRA applicability screening (EUR 1,900, defined scope and output). Price depends on the number of products, product category, components, development maturity, support model, existing technical documentation, reporting readiness and any required conformity-assessment route. Notified-body fees, if applicable, are contracted and paid by the client directly. Prices exclude VAT where applicable.
Determine your CRA route before building the wrong controls
Establish whether the regulation applies, identify the correct product and conformity route and prepare for the reporting duties that begin in September 2026.
Official references: Regulation (EU) 2024/2847, European Commission - Cyber Resilience Act, CRA FAQ, CRA factsheet.
Last reviewed: July 2026
