Cyber Resilience Act - Cybersecurity Requirements in EU
Note
This document is provided for informational purposes only and is intended solely to describe the process. It does not create any legal obligations, commitments, rights, or liabilities for any party.
The Cyber Resilience Act (CRA) is an EU regulation establishing cybersecurity requirements for products with digital elements placed on the EU market. It applies to software products and software components, including SDKs supplied to customers and integrated into downstream applications. Tech Soft 3D Industrial Applications and Toolkits are therefore in scope as software products with digital elements.
Objectives
The CRA (Cyber Resilience Act) (EU) 2024/2847 cybersecurity law for every product made available in EU requires companies selling hardware or software products to build cybersecurity into products from the start and maintain security throughout the product lifecycle.
Timeframe
December 10, 2024 — Entered Into Force, Already law.
June 11, 2026 — Provisions on the notification of conformity assessment bodies (notified bodies) apply (Article 71(2)).
September 11, 2026 — Reporting Obligations (ENISA reporting becomes mandatory). These apply to all products with digital elements made available on the EU market, including products placed on the market before 11 December 2027 (Article 69(3)).
December 11, 2027 — Full Compliance CE marking, Non-compliant products cannot be placed on the market. Products placed on the market before this date are only subject to the CRA requirements if they are substantially modified afterwards (Article 69(2)).
Requirements
September 11, 2026 — Reporting Obligations
Detect, manage, and rapidly report cybersecurity vulnerabilities and incidents.
Manufacturers of digital products will be required to
Report actively exploited vulnerabilities.
Report severe security incidents affecting their products.
Submit an initial alert within 24 hours of discovering the incident or vulnerability.
Submit a detailed report within 72 hours.
Submit a final report once a patch, workaround, or corrective action has been defined and the case is mature enough to be properly summarized:
for actively exploited vulnerabilities, the final report is due no later than 14 days after a corrective or mitigating measure becomes available,
for severe incidents, the final report is due within 1 month after the 72-hour incident notification.
Reports will be submitted through ENISA‘s European platform:
The CRA Single Reporting Platform (SRP).
Companies will therefore need to have:
A vulnerability detection process,
an internal escalation procedure,
a team capable of responding very quickly,
software component tracking (SBOM) (becoming mandatory in Dec 2027)
Illustrative mockups based on ENISA public tender specs. Not an official design. The ENISA Single Reporting Platform
December 11, 2027 — Full Cyber Resilience Act (CRA) Compliance
Demonstrate how products are secured, vulnerabilities managed, security updates are delivered, and prove regulatory compliance before the product is placed on the market.
Source: Cyber Resilience Act Website
Cyber Resilience Act (EU) 2024/2847 — High-Level Requirements
Source: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
Annex I is split into two sections: Part I – Security Properties of the Product, and Part II – Vulnerability Handling.
Part I — Security Properties (Product Design & Development)
These apply at the time of placing the product on the market and throughout its lifecycle. They are not absolute: Annex I Part I(2) requires them “on the basis of the cybersecurity risk assessment” and “where applicable”, so the risk assessment (Article 13) determines which requirements apply to a given product and how they are implemented.
No known exploitable vulnerabilities — Products must be placed on the market free of known exploitable vulnerabilities that could impact their security.
Secure by default configuration — Products must ship with a secure default configuration, including the ability to reset to factory/original state.
Protection from unauthorized access — Adequate authentication, identity management, and access control mechanisms must be in place to prevent unauthorized access.
Data confidentiality and integrity — Protection of stored, transmitted, or processed data through state-of-the-art encryption and other technical controls.
Data minimisation — Products must only process data that is strictly necessary for their intended function (privacy by design principle).
Attack surface limitation — Products must be designed to reduce the number of exploitable interfaces and entry points, applying exploitation mitigation techniques.
Resilience against denial-of-service attacks — Products must be designed to limit the impact and availability risks from DoS/DDoS attacks.
Availability of security update mechanisms — Vulnerabilities must be addressable through security updates. Where applicable, automatic security updates must be enabled by default, with a clear and easy-to-use opt-out mechanism, notification of available updates to users, and the option to temporarily postpone them.
Limitation of negative impact on other systems — Products must be designed so that any cybersecurity incident has a limited impact on other connected devices or networks.
Logging and monitoring capabilities — Products must record and monitor security-relevant events to support the detection and analysis of incidents.
Secure data removal and transfer — Users must be able to securely and easily remove all data and settings on a permanent basis and, where such data can be transferred to other products or systems, transfer it securely.
Part II — Vulnerability Handling (Ongoing Obligations)
These apply throughout the declared support period (minimum 5 years).
Vulnerability identification and documentation — Manufacturers must identify and document vulnerabilities in their products, including generating and maintaining a Software Bill of Materials (SBOM).
Timely remediation without delay — Known vulnerabilities must be addressed and fixed promptly through security updates, distributed free of charge to users.
Coordinated vulnerability disclosure (CVD) policy — Manufacturers must have and publish a policy for handling vulnerability reports from external researchers and third parties.
Separate security updates from feature updates — Where technically feasible, security patches must be deliverable independently from functionality updates, to avoid forcing users to accept new features just to stay secure.
Regular security testing and review — Manufacturers must apply effective and regular tests and reviews of the security of the product.
Public disclosure of fixed vulnerabilities — Once a security update has been made available, information about the fixed vulnerabilities must be shared and publicly disclosed, including a description, the affected products, the impact, the severity and remediation guidance. In duly justified cases, where the security risks of publication outweigh the benefits, disclosure may be delayed until users have had the possibility to apply the patch.
Single point of contact for users — A clearly accessible contact point must be provided to allow users to report vulnerabilities and receive security information.
Secure distribution of updates — Manufacturers must provide mechanisms to securely distribute updates, so that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, automatically.
Additional Cross-Cutting Obligations
Mandatory reporting to authorities (Article 14) — Manufacturers must notify actively exploited vulnerabilities and severe incidents simultaneously to the designated CSIRT and ENISA via a single reporting platform.
Support period declaration (Article 13(8)) — Manufacturers must declare a support period of at least five years (unless the product’s expected lifetime is shorter), during which they must handle vulnerabilities.
Availability of security updates (Article 13(9)) — Each security update made available to users during the support period must remain available for at least 10 years after it has been issued, or for the remainder of the support period, whichever is longer.
Due diligence on third-party components (Article 13(5)) — Manufacturers must exercise due diligence when integrating components sourced from third parties, including free and open-source software, so that these components do not compromise the cybersecurity of the product.
Reporting vulnerabilities in integrated components (Article 13(6)) — Manufacturers that identify a vulnerability in an integrated component, including an open-source component, must report it to the person or entity manufacturing or maintaining that component, and address and remediate it.
Informing impacted users (Article 14(8)) — After becoming aware of an actively exploited vulnerability or a severe incident, manufacturers must inform the impacted users, and where appropriate all users, together with any risk mitigation and corrective measures they can deploy.
Cybersecurity risk assessment — Manufacturers must conduct and document a cybersecurity risk assessment to identify relevant risks and applicable requirements.
Technical documentation (Annex VII) — Full technical documentation must be drawn up before placing the product on the market.
CE marking & Declaration of Conformity — Manufacturers must affix the CE marking and draw up an EU declaration of conformity.
Conformity assessment (Article 32) — The procedure depends on the product risk class. Default-category products can be self-assessed (internal control). Class I important products can also be self-assessed if harmonised standards, common specifications or a European cybersecurity certification scheme are applied in full; otherwise a notified body is required. Class II important products require third-party assessment, and critical products require European cybersecurity certification where a scheme has been designated.
Trust Center
Tech Soft 3D Trust Center will be the place where public and official documents related to the Cybersecurity Requirements will be made available.
Project Update & ETA
To meet the cybersecurity law requirements manufacturers must be able to produce the following information and address concerns in given timeframe, this includes:
Description |
Document |
Status |
Due Date |
|
|---|---|---|---|---|
Coordinated Vulnerability Disclosure Policy |
Manufacturers must have appropriate policies and procedures, including a coordinated vulnerability disclosure policy, to process and remediate potential vulnerabilities reported from internal or external sources. This requires a clear, published point of contact and mechanisms to receive, triage, and address vulnerabilities reported by external researchers. |
DONE |
December 11, 2027 |
|
Active vulnerability & incident reporting (Article 14) |
From 11 September 2026, manufacturers must report any actively exploited vulnerability or severe incident impacting product security via the ENISA Single Reporting Platform (SRP) — one submission simultaneously reaches the designated coordinator CSIRT and ENISA. Reporting follows a tiered escalation: an early warning within 24 hours of becoming aware, a structured notification with an initial severity assessment within 72 hours, and a final report within 14 days of a corrective or mitigating measure being available (for exploited vulnerabilities) or within one month of the 72-hour notification (for severe incidents). |
DONE |
September 11, 2026 |
|
User documentation (Annex II) |
Before placing a product on the market, manufacturers must provide users with: the manufacturer’s name, postal address, and contact details; a point of contact for reporting cybersecurity vulnerabilities; product identification (type, batch, version, or serial number); the intended purpose and essential security functionalities; any known or foreseeable cybersecurity risks; how to access the EU Declaration of Conformity; the type of security support offered and the end date of the support period; and instructions for secure setup, operation, software updates, and secure decommissioning including how to remove user data. Where the product is intended for integration into other products, as is the case for an SDK, the documentation must also give integrators the information they need to comply with the essential requirements of Annex I and the technical documentation requirements of Annex VII (Annex II point 8(f)). If the manufacturer chooses to make the SBOM available to users, the documentation must state where it can be accessed (Annex II point 9). |
WORK IN PROGRESS |
December 11, 2027 |
|
SBOM (Annex I Part II(1) / Annex VII points 2(b) and 8) |
Manufacturers must create and maintain a Software Bill of Materials covering at least the top-level dependencies of the product, in a commonly used machine-readable format such as SPDX, CycloneDX, or SWID. The CRA does not mandate public disclosure — the SBOM must be kept up to date and made available upon request to market surveillance authorities or conformity assessment bodies. |
WORK IN PROGRESS |
December 11, 2027 |
|
EU Declaration of Conformity (Annex V) |
Before placing a product on the market, manufacturers must draw up an EU Declaration of Conformity asserting that the product meets the essential cybersecurity requirements of Annex I. The declaration must be kept up to date and made available to market surveillance authorities upon request. A simplified EU Declaration of Conformity (Annex VI) may be supplied instead, provided it gives the internet address where the full declaration can be accessed. For software, this is often the practical choice, as the CE marking can be affixed to the declaration. |
DEFINITION |
December 11, 2027 |
|
Technical Documentation (Article 31 / Annex VII) |
Before placing a product on the market, manufacturers must draw up technical documentation demonstrating conformity with the essential cybersecurity requirements of Annex I. Its content is defined in Annex VII and includes: a general description of the product (intended purpose, software versions affecting compliance, and the Annex II user information); a description of the design, development and production of the product, including the system architecture; a description of the vulnerability handling processes, including the SBOM, the coordinated vulnerability disclosure policy, the vulnerability reporting contact and the secure update distribution mechanism; the cybersecurity risk assessment; the information used to determine the support period; the harmonised standards or other solutions applied; test reports; and a copy of the EU Declaration of Conformity. The documentation must be kept up to date during the support period and retained for at least 10 years after the product is placed on the market, or for the support period, whichever is longer (Article 13(13)). |
DEFINITION |
December 11, 2027 |
|
CE marking |
The CE marking must be affixed before a product is placed on the EU market. For software products, which have no physical product or packaging, the CE marking is affixed to the EU Declaration of Conformity or to the website accompanying the product (Article 30). From 11 December 2027, products without a CE marking demonstrating CRA conformity cannot legally be placed on the EU market. For default-category products, conformity can be self-assessed. Class I important products may also be self-assessed if harmonised standards, common specifications or a European cybersecurity certification scheme are applied in full; otherwise a notified body is required. Class II important products require third-party assessment, and critical products require European cybersecurity certification where a scheme has been designated. |
DEFINITION |
December 11, 2027 |
|
Support-period statement |
Manufacturers must define and communicate a support period at or before the point of purchase, including the end date, which must also appear in the Annex II user documentation. During the support period, manufacturers must actively monitor for vulnerabilities, maintain an up-to-date SBOM, and provide security updates free of charge. The criteria used to determine the support period must be documented in the technical file. |
DEFINITION |
December 11, 2027 |
|
Cybersecurity Risk Assessment (Article 13) |
Before placing a product on the market, manufacturers must carry out a cybersecurity risk assessment covering the product’s intended purpose, reasonably foreseeable use, and operational environment. The assessment must identify which Annex I Part I security requirements apply and how they are implemented, and must address the vulnerability handling requirements of Annex I Part II. It is a standalone deliverable explicitly required by Article 13 and must be included in the technical documentation (Annex VII). It must be documented and updated as appropriate during the support period (Article 13(3)). |
DEFINITION |
December 11, 2027 |
