Essential cybersecurity requirements

The essential cybersecurity requirements are the substantive core of the Cyber Resilience Act (CRA). They do not sit in the articles but in Annex I, and they come in two parts. Part I describes properties of the product; Part II describes the processes by which the manufacturer handles vulnerabilities.

Article 6 turns both parts into a condition of market access. A product with digital elements may be made available only where it meets the requirements in Part I and the processes put in place by the manufacturer comply with those in Part II. One without the other is not enough. Point (a) attaches a proviso to the first condition: the product has to be properly installed and maintained, used for its intended purpose or under conditions which can reasonably be foreseen, and, where applicable, to have had the necessary security updates installed.

Part I: the properties of the product

Part I consists of two very unequal points. Point 1 is a general clause and always applies: products shall be designed, developed and produced so that they ensure an appropriate level of cybersecurity based on the risks.

Point 2 then lists thirteen concrete requirements, points (a)–(m). They apply on the basis of the cybersecurity risk assessment referred to in Article 13(2), and only where applicable:

• made available without known exploitable vulnerabilities (a)
• a secure by default configuration and the option to reset the product to its original state (b)
• vulnerabilities addressable through security updates, where applicable automatically, with an opt-out (c)
• protection from unauthorised access through at least authentication, identity or access management, and reporting of possible unauthorised access (d)
• confidentiality of stored, transmitted or otherwise processed data, for instance through encryption (e)
• integrity of data, commands, programs and configuration, and reporting of corruption (f)
• data minimisation relative to the intended purpose (g)
• availability of essential and basic functions, including after an incident (h)
• minimal negative impact on services provided by other devices or networks (i)
• limited attack surfaces, including external interfaces (j)
• reduction of the impact of an incident through appropriate exploitation mitigation mechanisms and techniques (k)
• provision of security-related information by recording and monitoring relevant internal activity, with a user opt-out (l)
• secure, permanent removal of all data and settings (m)

“Where applicable” is not discretion

The qualifier in point 2 is often read as a free choice. It is tied to a procedure. Article 13(3) requires the risk assessment to state whether and in what manner each requirement in Part I, point 2, applies to the product and how it is implemented. The basis is the Intended purpose, the reasonably foreseeable use and the conditions of use, such as the operational environment or the assets to be protected. What Cybersecurity risk a product carries therefore governs how far the obligations reach.

Where a requirement does not apply, Article 13(4) calls for a clear justification in the Technical documentation. Recital 55 offers an example: a requirement may be incompatible with the nature of the product, for instance because a widely recognised interoperability standard has to be followed whose security features are no longer state of the art. If a risk remains, the same recital says the manufacturer should address it by other means, such as limiting the intended purpose to trusted environments or informing users about the risk.

Part II: vulnerability handling

Part II addresses the manufacturer rather than the product, and it carries no applicability qualifier. All eight points apply in full, and under Article 13(8) they apply for the expected product lifetime and the whole Support period:

• identify and document vulnerabilities and components, including through a Software Bill of Materials (SBOM) in a commonly used, machine-readable format covering at least the top-level dependencies (1)
• address and remediate vulnerabilities without delay; where technically feasible, security updates are provided separately from functionality updates (2)
• apply effective and regular testing and review of product security (3)
• once an update is available, disclose fixed vulnerabilities with a description, the affected product, the impacts and the severity (4)
• put in place and enforce a policy on coordinated vulnerability disclosure (5)
• facilitate information sharing on potential vulnerabilities and provide a contact address for reports (6)
• provide mechanisms to distribute updates securely (7)
• disseminate available security updates without delay and free of charge, with advisory messages on possible action (8)

Two of the points contain an express opening. Point 4 allows publication of a fixed vulnerability to be delayed until users have had the chance to apply the patch, provided the risks of publication outweigh the security benefits and the case is duly justified. Point 8 permits a different arrangement with a business user for tailor-made products, but only as to being free of charge, not as to timing.

How compliance is evidenced

Article 27 offers three routes to a presumption of conformity: a Harmonised standard whose reference has been published in the Official Journal, a common specification adopted by the Commission, and a European cybersecurity certification scheme under Regulation (EU) 2019/881. In each case the presumption goes only as far as the standard, specification or certificate actually covers the individual requirement.

Where no reference has been published, the presumption falls away but the requirement does not. The manufacturer then has to demonstrate compliance on its own: through the conformity assessment under Article 32, which tests precisely against Annex I, through the technical documentation under Article 31 and Annex VII, and through the user information under Annex II. Annex II, point 8(e) asks, among other things, for instructions on how to turn off the default setting that enables the automatic installation of security updates under Annex I, Part I, point 2(c).

What else hangs on Annex I

The Annex is the reference point for a long list of other provisions. Under Article 3(31) the CE marking is the manufacturer’s declaration that the product and the processes meet Annex I. Under Article 3(30) a substantial modification is a change after placing on the market that affects compliance with Annex I, Part I, or that results in a modification to the intended purpose for which the product was assessed. Article 19(1) allows importers to place a product on the market only where it meets Annex I, Part I and the manufacturer’s processes comply with Annex I, Part II.

Annex I also comes first in the penalty regime. Article 64(2) provides for fines of up to EUR 15 000 000 or, in the case of an undertaking, up to 2.5 % of total worldwide annual turnover for the preceding financial year, whichever is higher, for non-compliance with the essential cybersecurity requirements and for breaches of Articles 13 and 14. That is the highest band in the Regulation.

One date matters for planning. The Annex I requirements apply from 11 December 2027. Only two things bite earlier: the reporting obligations in Article 14 from 11 September 2026, and Chapter IV on the notification of conformity assessment bodies, Articles 35 to 51, from 11 June 2026.