AsteronAsteron

    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.

    Review the CRA timeline
    • 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.

    Commercial healthtech application supplied to customers
    Likely in scope when it is a software product with direct or indirect network or device connectivity
    Connected wellness device or non-medical health product
    Likely in scope if made available on the EU market
    Software component supplied separately
    May be an in-scope product with digital elements
    Remote processing required for the product to perform a function
    May form part of the product’s CRA scope
    Medical-device software governed by MDR
    Excluded from CRA for that regulated product
    IVD software governed by IVDR
    Excluded from CRA for that regulated product
    Separate portal, gateway or accessory not covered by MDR or IVDR
    Requires its own CRA applicability assessment
    Software developed only for internal use and not made available commercially
    Generally outside the product-market scope
    Free and open-source software developed outside a commercial activity
    Treated differently; commercial involvement and open-source-steward duties must be assessed

    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

    1. 10 December 2024

      Entered into force

      The transition period began.

    2. 11 June 2026

      Conformity-assessment infrastructure

      Provisions concerning notification of conformity assessment bodies began to apply.

    3. 11 September 2026

      Reporting obligations

      Manufacturers must report actively exploited vulnerabilities and severe incidents affecting product security.

    4. 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.

    1. Step 1

      Within 24 hours

      Submit an early warning after becoming aware of an actively exploited vulnerability or severe incident.

    2. Step 2

      Within 72 hours

      Provide the full notification with available information about the product, vulnerability or incident and its impact.

    3. 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.

    Default product
    Manufacturer self-assessment is generally available
    Important product - Class I
    Self-assessment may depend on applying recognised specifications; otherwise third-party assessment may be required
    Important product - Class II
    Third-party conformity assessment is generally required
    Critical product
    Mandatory third-party conformity assessment or an applicable recognised certification route

    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

    CRA
    Cybersecurity of software and connected hardware placed on the EU market
    MDR and IVDR
    Safety, performance and market access for medical devices and IVDs; regulated products are excluded from CRA
    IEC 81001-5-1
    Health-software security lifecycle processes that can support product-security work
    IEC 62304
    Medical-device software lifecycle processes
    ISO 27001
    Organisation-level information-security management system
    NIS2
    Cybersecurity governance and incident reporting for qualifying organisations
    Product Liability Directive
    Liability exposure for defective products, including software

    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

    1. CRA Applicability Screening - EUR 1,900

      Identify the product, commercial model, connectivity, operator role and possible exclusions.

    2. Product and role scoping

      Define the product boundary, associated remote processing, components and economic operators.

    3. Classification and route

      Determine the likely CRA category and conformity-assessment path.

    4. Security baseline

      Map cybersecurity risks and essential product requirements to the development lifecycle.

    5. Vulnerability and reporting readiness

      Establish intake, triage, remediation, disclosure, updates and regulatory reporting.

    6. 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

    CRA Applicability Screening

    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
    CRA implementation

    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.

    Review related frameworks