Ask what a manufacturer has to do first under the Cyber Resilience Act, Regulation (EU) 2024/2847, and most answers say "the technical file". The Regulation says something narrower: before the file, before the 22 requirements are applied, there is a cybersecurity risk assessment, and it is the document that decides which requirements apply to your product and justifies every one you leave out. Article 13, paragraphs 2 to 4, describe it. They are short and unusually specific about what the assessment must contain.
What it is for: Article 13(2)
The manufacturer "shall undertake an assessment of the cybersecurity risks associated with a product with digital elements and take the outcome of that assessment 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".
Two things follow. It is a lifecycle document, not a launch document: the outcome is taken into account from planning through maintenance. And health and safety are in scope: a product whose compromise could hurt someone has to say so and treat that risk.
What it must contain: Article 13(3)
Paragraph 3 is the one to read slowly, because it lists the contents.
Documented and updated. "The cybersecurity risk assessment shall be documented and updated as appropriate during a support period." A risk assessment done once at launch and never revisited is not what the text describes; it is updated as the product, its environment and the threat change, for as long as the support period runs.
An analysis based on use. It "shall comprise at least an analysis of cybersecurity risks based on the intended purpose and reasonably foreseeable use, as well as the conditions of use, of the product with digital elements, such as the operational environment or the assets to be protected, taking into account the length of time the product is expected to be in use". So the inputs are named: what the product is for, how it will foreseeably be used and misused, where it runs, what it protects, and for how long.
A ruling on every Part I, point 2 requirement. It "shall indicate whether and, if so in what manner, the security requirements set out in Part I, point (2), of Annex I are applicable to the relevant product with digital elements and how those requirements are implemented as informed by the cybersecurity risk assessment". This is the sentence that makes the assessment the spine of the file: for each of the thirteen "where applicable" properties, applicable or not, and if so how it is implemented.
A statement on Part I, point 1 and Part II. It "shall also indicate how the manufacturer is to apply Part I, point (1), of Annex I and the vulnerability handling requirements set out in Part II of Annex I". Point 1 (an appropriate level of cybersecurity) and the eight vulnerability-handling requirements always apply; the assessment says how.
Where it goes, and the justification rule: Article 13(4)
The assessment is included in the technical documentation (Annex VII, point 3). Where a product is also subject to other Union law with its own risk assessment, the two may be one document. And the sentence that matters most: "Where certain essential cybersecurity requirements are not applicable to the product with digital elements, the manufacturer shall include a clear justification to that effect in that technical documentation."
An exclusion without a written reason is a gap. A reason that does not come from the risk analysis ("we did not have time", "our competitors do not do it") is not the kind of justification the text asks for.
A one-page structure that satisfies the four paragraphs
The Regulation does not prescribe a method. Any structured method works if its output covers the contents above. One that does, in the order the text implies:
- Product and intended purpose. What it is, what it is for, the versions covered, and the expected time in use (which also feeds the support period).
- Foreseeable use and misuse, and conditions of use. Who uses it, where it runs, what it connects to, what it protects (the assets), and what a reasonable misuse looks like.
- Threats and risks. For each asset and interface, what could go wrong, how likely, how bad, including health and safety where relevant. Any recognised method (a threat model, an attack tree, a scored register) is fine; the text asks for an analysis, not a particular form.
- The Part I, point 2 table. Thirteen rows, (a) to (m): applicable yes or no; if yes, how implemented; if no, the reason drawn from step 3. This table is the deliverable a notified body or an authority reads first.
- Part I, point 1 and Part II. How the appropriate level of cybersecurity is achieved overall, and how each of the eight vulnerability-handling requirements is met in practice: the SBOM, the disclosure policy, the update channel, the contact point.
- Review. Who owns it, when it is next reviewed, and what triggers an earlier review (a new version, a new environment, a reported vulnerability). The assessment is updated over the support period, and this section is how.
Date it, version it, and file it with the technical documentation. When the product changes, change the assessment first and the file after, because the file is the assessment's consequence, not the other way round.
What it does not need to be
It does not need to be long: the text asks for "at least" an analysis and the two indications, and a short document that makes every ruling is better than a long one that makes none. It does not need a consultant's methodology, though an existing one (ISO/IEC 27005, a threat-modelling practice already in use) can be reused as long as its output is mapped to the thirteen rows and the Part II statement. And it does not need to wait for a harmonised standard: none has been published, and the assessment is what a manufacturer has instead.
What the Commission's FAQ adds
The Commission's FAQ on the implementation, version 1.4 of 4 September 2026, section 4.1, settles five things the Regulation leaves to the reader.
No methodology is mandated. Entry 4.1.2: "The CRA does not mandate a specific cybersecurity risk assessment methodology." What it asks is that the method "support manufacturers in documenting" that every relevant risk was addressed, so that an authority "can verify how risks have been identified, evaluated and mitigated", and that the threat model fit the product: products for critical infrastructure "may be required to treat risks related to nation-state actors and advanced persistent threats", while consumer products "typically have a lower risk profile and may use a different threat model".
Part II always, Part I as the risks say. Entry 4.1.3: the vulnerability handling requirements of Annex I Part II apply in full "throughout the product's support period", while for the product properties of Part I the manufacturer "need[s] to determine on the basis of the cybersecurity risk assessment which of those requirements are relevant". A requirement set aside needs "a clear justification in the cybersecurity risk assessment included in the technical documentation". The FAQ's example is personal data: a product whose intended purpose does not include processing personal data may need no measure for its protection, and where an interoperability standard the product must follow (Recital 55) makes a requirement inapplicable but leaves a risk, the risk is treated "by other means, for instance by limiting the intended purpose of the product to trusted environments and/or by informing the users".
One assessment can serve several acts. Entry 4.1.1: a manufacturer "may carry out a single risk assessment covering the needs of different legislations", provided it can "demonstrate compliance with each individual legislation". The assessment covers "the entire product with digital elements, including remote data processing when in scope", and every phase from planning to maintenance, for every tier.
Intended purpose is what you publish. Entry 4.1.4 with Article 3(23): the intended purpose is the use the manufacturer specifies "in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation", and where the product lets a user alter configurations or downgrade security for legacy compatibility, those uses go into the assessment, get their own treatment, and are described in the instructions.
Misuse you can foresee is in scope too. Entry 4.1.5 with Article 3(24): deploying a product "on an insecure network" when the instructions require a secure one "might constitute a reasonably foreseeable misuse", and risks from foreseeable misuse "must also be communicated in the information and instructions to the user" under Annex II point 5. Hacking one's own device for fun or research is misuse in this sense, not intended use.
Sources
- Regulation (EU) 2024/2847, Article 13(1) to (4) (quoted), Article 13(8) for the support period, Article 31 and Annex VII point 3 for the file, Annex I Parts I and II. Read from the Official Journal text on EUR-Lex on 11 September 2026.
- European Commission, FAQs on the Cyber Resilience Act, version 1.4 of 4 September 2026, entries 4.1.1 to 4.1.5.
This is not legal advice. Article 13(3) is one paragraph; read it against your own assessment and check that each named content is there.