Cyber Resilience Act requirements: what the regulation demands from manufacturers of digital products

By the QuantumSec team

The Cyber Resilience Act imposes two types of obligations on manufacturers of products with digital elements: technical requirements the product must meet (Annex I, Part I) and process requirements for managing the product's security lifecycle (Annex I, Part II). It also establishes a conformity assessment procedure based on the product category, along with mandatory documentation the manufacturer must produce and retain. This guide breaks down every one of these requirements at the level of detail a technical team or product owner needs.

Technical product requirements: Annex I, Part I

Annex I, Part I sets out the essential cybersecurity requirements the product must meet when placed on the market and throughout its entire lifecycle.

1. No known exploitable vulnerabilities: the product cannot be placed on the market with known, exploitable vulnerabilities. This does not mean a complete absence of vulnerabilities, but that the manufacturer must actively verify there is no known, documented vulnerability in databases such as the NVD or CVE that is exploitable in the product as marketed.

2. Secure by default configuration: it explicitly prohibits generic default passwords (the same password for every device of a model), unnecessary open ports, services enabled without need and excessive permissions in the initial configuration.

3. Protection of data at rest and in transit: in practice this means encryption in transit (TLS 1.2 or higher), encryption at rest for sensitive data and proper cryptographic key management.

4. Minimal attack surface: all ports, services, protocols and features not required for the product to function must be disabled.

5. Protection against unauthorised access: authentication appropriate to the contextual risk, session management, and protection against brute-force attacks.

6. Software integrity and secure updates: the firmware or software update mechanism must be secure by design: authenticity verification of the update package, encrypted transmission, and protection against tampering or unauthorised rollback.

7. Security event logging: security-relevant actions —authentication attempts, configuration changes, network connections, integrity errors— must be logged and accessible to the administrator.

8. No hidden functionality: the product cannot include backdoors, hidden access mechanisms or any functionality that compromises the user's security without their knowledge.

Vulnerability management requirements: Annex I, Part II

Annex I, Part II governs the processes the manufacturer must implement to manage the product's security lifecycle once on the market.

1. Identifying and documenting vulnerabilities: the manufacturer must maintain a complete inventory of the product's components and dependencies (a Software Bill of Materials, or SBOM) and actively monitor the relevant vulnerability intelligence sources.

2. Coordinated vulnerability disclosure (CVD): the manufacturer must publish a CVD policy with an accessible channel for security researchers and users to report vulnerabilities, along with a documented assessment and response process.

3. Free security updates throughout the lifecycle: the manufacturer must provide security updates free of charge for a period of no less than five years from being placed on the market, or for the product's expected lifecycle if longer.

4. Notification to ENISA: from August 2026, the manufacturer must notify ENISA of actively exploited vulnerabilities. Deadlines: 24 hours for the early warning, 72 hours for the full notification, and 14 days for the final report.

5. Clear information to the user about the support period: the manufacturer must communicate the date until which it guarantees security updates before purchase and in the product documentation.

6. Embedding security in the SDLC: secure development practices, security code review, security testing and secure management of the release process.

The Software Bill of Materials (SBOM): why it is central to the CRA

The SBOM —a complete inventory of every software component that forms part of a product— is one of the key tools for meeting the CRA's requirements. Without an up-to-date SBOM, it is impossible to comply with the obligation to identify vulnerabilities in the product: you cannot know whether a newly published CVE in an open-source library affects you if you do not have an inventory of which libraries your product uses and in which version. The CRA requires the manufacturer to be able, when a new vulnerability is published, to determine within minutes whether any component of its products is affected and to notify ENISA within the 24-hour deadline. Automatically generating the SBOM in SPDX or CycloneDX format, integrated into the CI/CD pipeline, is one of the first technical measures we recommend implementing in any CRA readiness project.

Conformity assessment: how compliance is certified

The conformity assessment mechanism varies depending on the product category.

Default products: the manufacturer may carry out a self-assessment without involving third parties. The manufacturer assesses its product against the Annex I requirements, prepares the technical documentation and issues the EU declaration of conformity under its own responsibility.

Class I products: they can choose between self-assessment by demonstrating full application of a European harmonised standard (when these become available, expected in 2026-2027), or submitting the product to a development process quality assessment module.

Class II products: they mandatorily require conformity assessment by a notified body, including assessment of the product against the Annex I requirements and the issuance of the EU type-examination certificate.

Mandatory technical documentation

The CRA requires the manufacturer to maintain and retain for 10 years technical documentation that includes: a complete description of the design and development process; a cybersecurity risk analysis with the identified risks and the measures adopted; a list of the harmonised standards applied; testing and conformity assessment procedures; the coordinated vulnerability disclosure policy; and the EU declaration of conformity signed by the manufacturer's authorised representative. In addition, the manufacturer must provide users with instructions for use covering the security measures they must adopt, information about the security support period, and the point of contact for reporting vulnerabilities.

FAQ

Are open-source products subject to the CRA requirements?

The CRA explicitly excludes open-source software developed on a non-commercial basis. However, if a company markets a product based on open-source software (a commercial Linux distribution, a router with OpenWRT-based firmware, or a security appliance based on Suricata), that commercial product is indeed subject to the CRA. The commercial manufacturer is responsible for compliance even if part of the code is open source.

What is a CRA harmonised standard and when will they be available?

Harmonised standards are European technical standards (ETSI, CEN-CENELEC) developed under a mandate from the European Commission which, when fully applied, create a presumption of conformity with the CRA requirements. The relevant standards are still under development and are expected in 2026-2027. In their absence, manufacturers can use other recognised technical standards such as IEC 62443, ETSI EN 303 645, or NIST SP 800-218 to demonstrate conformity, although this requires an explicit mapping between the standard's requirements and those of the CRA.