What does the Cyber Resilience Act require in a cybersecurity risk assessment?

Article 13(1) obliges manufacturers to ensure a product with digital elements has been designed, developed and produced in accordance with the essential cybersecurity requirements in Annex I Part I. The risk assessment is the mechanism for doing that.^[1]

Article 13(2) requires manufacturers to undertake an assessment of the cybersecurity risks associated with the product and to take the outcome into account during the planning, design, development, production, delivery and maintenance phases, with a view to minimising cybersecurity risks, preventing incidents and minimising their impact, including in relation to the health and safety of users.^[1]

Article 13(3) sets the minimum content. The assessment has to comprise at least an analysis of cybersecurity risks based on the intended purpose and reasonably foreseeable use, as well as the conditions of use, such as the operational environment or the assets to be protected, taking into account how long the product is expected to be in use. It then has to do three specific jobs:^[1]

1. Indicate whether, and if so in what manner, the security requirements in Annex I Part I point (2) apply to the product, and how those requirements are implemented as informed by the assessment.
2. Indicate how the manufacturer applies Annex I Part I point (1), the general obligation to ensure an appropriate level of cybersecurity based on the risks.
3. Indicate how the manufacturer applies the vulnerability handling requirements in Annex I Part II.

That third job is the one most summaries drop. The risk assessment reaches the vulnerability handling side of Annex I, not only the product properties in Part I.

This is the part that changes how the work is scoped. Annex I Part I point (2) opens with the words "On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable", and then lists the product security requirements from (a) to (m).^[2]

So the requirements in point (2) are conditional. The risk assessment is what establishes which of them apply to a given product and how. Article 13(4) closes the loop. Where certain essential cybersecurity requirements are not applicable, the manufacturer has to include a clear justification to that effect in the technical documentation.^[1]

Annex I Part I point (1) works differently. It requires products to be designed, developed and produced so as to ensure an appropriate level of cybersecurity based on the risks, with no applicability condition attached.^[2] The Commission guidance treats point (1) as a catch-all. Where every relevant risk is already treated by measures implementing the other requirements, point (1) is satisfied. Where the assessment surfaces risks the other requirements do not reach, point (1) demands product-level measures for those as well.^[11]

The practical consequence is that "which requirements apply to us" is an output of the assessment rather than an input to it, and every exclusion has to be written down and defended.

Article 13(3) fixes the scope of the analysis to the intended purpose and reasonably foreseeable use, as well as the conditions of use of the product, such as the operational environment or the assets to be protected, and the expected length of time in use.^[1]

Reasonably foreseeable misuse is a defined term in the Regulation. Article 3, point (25) defines it as the use of a product in a way that is not in accordance with its intended purpose, but which may result from reasonably foreseeable human behaviour or technical operations or interactions.^[4]

The distinction worth getting right is where that term operates. Misuse does not appear in Article 13(3). It appears in Annex II point 5, which requires the product to be accompanied by any known or foreseeable circumstance, related to use in accordance with the intended purpose or under conditions of reasonably foreseeable misuse, that may lead to significant cybersecurity risks.^[3]

In practice the two connect. Annex II point 5 cannot be completed without an assessment that has considered foreseeable misuse, so misuse belongs in the analysis. Attributing the requirement to Article 13(3) misstates the provision, and the New Legislative Framework and the Blue Guide are the wrong citation when the Regulation defines the term itself.

The phrase "residual risk" does not appear anywhere in the Regulation. The binding requirement is Annex I Part I point (1), an appropriate level of cybersecurity based on the risks, and the Annex II point 5 duty to tell users about circumstances that may lead to significant cybersecurity risks.^[2][3]

The Commission guidance is where the residual risk question is addressed directly, and it is firm. Residual risk is measured against a regulatory threshold rather than against the manufacturer's internal risk appetite. Internal risk tolerance, commercial strategy and cost are irrelevant to whether the essential requirements are met. Residual risk always exists, and a product may be placed on the market only once residual risks are addressed sufficiently to meet the essential requirements. The guidance also states that the CRA does not allow cybersecurity risk or responsibility to be transferred to users or third parties. User information can support secure deployment and inform users of residual risks, and it cannot compensate for design shortcomings. Where identified risks cannot be adequately addressed, compliance may require changing the design, the functionality or the intended purpose, and cost alone is not a ground to leave a risk untreated.^[11]

That guidance is interpretive and not binding, so the position is best stated as what the Commission services expect rather than as a rule the Regulation spells out.

Article 13(3) requires the assessment to be documented and updated as appropriate during the support period, which Article 13(8) derives from the time the product is expected to be in use, with five years as a floor.^[1] That makes it a maintained artefact across the product's supported life.

Article 13(4) requires the manufacturer to include the assessment in the technical documentation required under Article 31 and Annex VII when placing the product on the market. For products covered by Article 12, high-risk AI systems, the cybersecurity risk assessment may form part of the risk assessment required under the other Union act rather than being duplicated.^[1]

There is a documentation concession that broad summaries usually miss. Article 33(5) allows microenterprises and small enterprises to provide all elements of the Annex VII technical documentation using a simplified format specified by the Commission in an implementing act, and notified bodies have to accept that form.^[8] The concession runs to the form of the documentation. The substance of the assessment is unchanged, so this is not a lighter assessment for smaller manufacturers.

Two obligations run in parallel and are often collapsed into one.

The Article 13(2) risk assessment covers the product as a whole, including risks that originate outside it such as external networks, the operating environment, and back-end systems the product depends on. The Commission guidance is clear that a manufacturer is not expected to control the external environment, only to mitigate external risks through the product's own design, for example by authenticating remote commands, verifying the integrity of configuration changes, logging abnormal behaviour, or ensuring that an outage of a remote service does not leave the product in an insecure state.^[11]

Article 13(5) is separate. It requires due diligence when integrating components sourced from third parties, so those components do not compromise the cybersecurity of the product, and it says so expressly for free and open source components that have not been made available on the market in the course of a commercial activity.^[1] Article 13(6) adds that on identifying a vulnerability in an integrated component the manufacturer reports it to whoever maintains that component and remediates it under the Annex I Part II requirements.^[1]

One widespread overstatement is worth correcting. A manufacturer is responsible for its own product in its entirety and owes due diligence on what it integrates. The Commission guidance states that manufacturers do not become responsible for an integrated component's own compliance with the Regulation, even where they contribute to its development.^[12]

The Regulation names no methodology. Article 13 sets out what the assessment must cover and what it must conclude, and leaves the method to the manufacturer. What the technical documentation has to show is a repeatable process and a defensible result.

Two standard families are the practical anchors.

• The prEN 40000 series, drafted by CEN-CENELEC JTC 13 under Commission standardisation request M/606, is the horizontal set of harmonised standards for the CRA. prEN 40000-1-2 covers the Annex I Part I product security and risk requirements, and prEN 40000-1-3 covers the Annex I Part II vulnerability handling requirements. The parts carry the pr prefix because they are still drafts, and none is yet cited in the Official Journal, so none currently confers a presumption of conformity.^[13]
• IEC 62443 comes from industrial automation and control systems. IEC 62443-4-1 covers the secure product development lifecycle and IEC 62443-4-2 covers technical security requirements for components. Neither is a harmonised standard under the CRA, so alignment with them is evidence of a sound process and never a presumption of conformity.^[14]

Waiting for the harmonised standards to be cited is the wrong move. Article 32(2) escalates a Class I important product to third-party assessment precisely where the manufacturer has not applied a harmonised standard, a common specification or a certification scheme, or where none exists.^[7] Until the EN 40000 parts are cited, that escalation is the live case for most manufacturers of Annex III products.

Article 71(2) sets the calendar. The Regulation applies from 11 December 2027, so the Article 13 risk assessment duty bites on that date. Article 14 applies earlier, from 11 September 2026, and Chapter IV, Articles 35 to 51, from 11 June 2026.^[10]

Article 69(2) carries a genuine carve-out that is often reported as though it did not exist. Products placed on the market before 11 December 2027 are subject to the requirements of the Regulation only if, from that date, they undergo a substantial modification. Article 69(3) then overrides that for one obligation. The Article 14 reporting duties apply to all products within scope placed on the market before 11 December 2027 regardless.^[9]

Two points of precision follow. The trigger is placing on the market, not when a product was designed. And the exposure on a legacy portfolio is the reverse of the common assumption. Article 13 risk assessment generally does not reach it, while Article 14 reporting does.

Scope exclusions also apply. Article 2 carves out products already covered by sectoral Union law, including medical devices under Regulations (EU) 2017/745 and 2017/746, motor vehicles under Regulation (EU) 2019/2144, civil aviation under Regulation (EU) 2018/1139 and marine equipment under Directive 2014/90/EU.^[5] Free and open source software supplied outside a commercial activity is outside scope as well, and open-source software stewards are subject to Article 24 rather than the Article 13 manufacturer obligations.