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.
• September 11, 2026 — Reporting Obligations (ENISA reporting becomes mandatory).
• December 11, 2027 — Full Compliance CE marking, Non-compliant products cannot be sold.

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.

• 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 — Products must include functions enabling the notification, distribution, download, and installation of security updates, including automatic updates for consumer products.
• 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.

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.
• Public disclosure of fixed vulnerabilities — Information about addressed vulnerabilities must be made publicly available after fixes are deployed.
• Mandatory reporting to authorities — Manufacturers must notify actively exploited vulnerabilities and severe incidents simultaneously to the designated CSIRT and ENISA via a single reporting platform.
• Support period declaration — 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.
• Single point of contact for users — A clearly accessible contact point must be provided to allow users to report vulnerabilities and receive security information.

Additional Cross-Cutting Obligations

• 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 — Depending on product risk class (default, important class I/II, or critical), either internal self-assessment or mandatory third-party audit applies.

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.	Coordinated Vulnerability Disclosure Policy	WORK IN PROGRESS	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).	Active vulnerability & incident reporting process	WORK IN PROGRESS	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.	User documentation	WORK IN PROGRESS	December 11, 2027
SBOM (Annex I Part II / Annex VII point 2b)	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.	SBOM, SPDX	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.	EU Declaration of Conformity	DEFINITION	December 11, 2027
Technical Documentation (Annex II pre-market / Annex VII post-market)	The CRA requires two distinct layers of technical documentation. The pre-market file (governed by Annex II) must demonstrate conformity with Annex I essential requirements and includes: a general product description and intended purpose, software versions, design and development details, the cybersecurity risk assessment, applicable standards, test and validation results, the EU Declaration of Conformity, and the SBOM. The post-market file (governed by Annex VII) covers evidence accumulated after the product is placed on the market, including records of security updates, vulnerability handling, and incident reporting. Both must be retained for 10 years from the date the product is placed on the market, per Article 13.	Technical Documentation	DEFINITION	December 11, 2027
CE marking	The CE marking must be affixed before a product is placed on the EU market, and must appear on the product itself, its packaging, or a document accompanying the product. 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 and Class II important products, and critical products, require third-party assessment by a notified body.	CE marking	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.	Support-period statement	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 pre-market technical documentation.	Cybersecurity Risk Assessment	DEFINITION	December 11, 2027