The CRA cybersecurity risk assessment
Short answer. Annex VII point 3 asks for an assessment of the cybersecurity risks the product is designed against. In practice that means one reasoned answer for each of the thirteen requirements in Annex I Part I point 2, plus the chapeau in point 1.
No format is prescribed. And because the harmonised standards are not available to cite yet, this document is currently the whole of your argument that the product meets the essential requirements — which makes it the most consequential thing in the file.
This is the document manufacturers most often produce badly, and the reason is understandable: "assess the cybersecurity risks" sounds like it wants a threat model, a matrix of likelihood against impact, and a methodology. It does not particularly want any of those. It wants to know, for each thing the regulation requires of a product, what you did about it in this product.
What Annex VII point 3 actually asks for
Point 3 of Annex VII requires the technical documentation to contain an assessment of the cybersecurity risks against which the product is designed, developed, produced, delivered and maintained — and it binds that assessment to Article 13 and to Part I of Annex I specifically.
That last detail is worth pausing on, because it tells you the shape of the document. Annex I has two parts: Part I is the properties of the product, and Part II is the vulnerability-handling process. Point 3 points at Part I. Part II is documented separately, as process, and it turns up in Annex VII point 2 alongside the SBOM and the disclosure policy.
So the risk assessment is about the product. Thirteen requirements, one reasoned answer each.
Why it carries more weight than it should
In a mature CE-marking regime this document is often thin, because a manufacturer cites a harmonised standard and gets a presumption of conformity for the requirements that standard covers. The standard does the arguing.
The CRA's harmonised standards are still in development, and the published schedules for them have already moved once. Until they are cited in the Official Journal, there is nothing to cite — and Annex VII point 5 expressly contemplates that case, asking instead for a description of the solutions adopted where no standard was applied.
Which produces the position manufacturers should understand clearly: right now the risk assessment is not a supporting document. It is the argument. If an assessor wants to know why you believe this product meets Annex I, this is the only document that answers.
Two consequences. First, it is worth more of your attention than the technical file around it, which is largely an index. Second, when the standards do land, this document is the one that has to be revisited — so write it in a way that makes updating a row cheap.
The thirteen requirements, and what a good answer looks like
The requirement wording below is our own faithful paraphrase, not the Official Journal text. Read the annex itself; the value here is in the second column.
| Point | What it requires | What a good answer says |
|---|---|---|
| 1 | An appropriate level of cybersecurity based on the risks identified — the chapeau the thirteen sit under | Which risks you identified, and how they drove the design. Two or three paragraphs. This is the only part that resembles a conventional risk assessment |
| 2(a) | Made available without known exploitable vulnerabilities | The step that establishes this before each release, and when it runs. "Dependency scan and advisory review in the release pipeline; a build with an unresolved critical finding does not ship" beats "we scan regularly" |
| 2(b) | A secure by default configuration, including the possibility to reset to the original state | What the defaults are, and how a reset works. If there is no default password, say so — it is the single most useful sentence in this row |
| 2(c) | Vulnerabilities addressable through security updates, where applicable automatic by default, with a clear and easy-to-use opt-out | How an update is delivered and installed, whether automatic is the default, and exactly where a user opts out or postpones |
| 2(d) | Protection from unauthorised access by appropriate control mechanisms, including authentication and access management, and reporting on possible unauthorised access | The authentication mechanism, the authorisation model, and — the half people forget — how a possible unauthorised access is detected and surfaced |
| 2(e) | Confidentiality of stored, transmitted and processed data, such as by encrypting relevant data at rest or in transit with state of the art mechanisms | Named algorithms and key lengths, and what is not encrypted and why. "TLS 1.3 for all network traffic; configuration at rest with AES-256-GCM; telemetry counters unencrypted, containing no user data" |
| 2(f) | Integrity of stored, transmitted and processed data, commands, programs and configuration against unauthorised manipulation, and reporting on corruptions | Signed firmware, secure boot, signed configuration, checksums — whichever apply — and how a detected corruption is reported rather than silently tolerated |
| 2(g) | Processing only data that are adequate, relevant and limited to what is necessary for the intended purpose | A list of what the product processes with a one-line justification each. Short lists are good answers here |
| 2(h) | Availability of essential and basic functions, including after an incident, with resilience and mitigation against denial of service | Which functions you have declared essential, and what keeps them working when the network, the cloud service or a dependency is gone |
| 2(i) | Minimising the negative impact on the availability of services provided by other devices or networks | Rate limits, exponential backoff, bandwidth ceilings, retry caps. This is the requirement the botnet-participation case sits under |
| 2(j) | Designed, developed and produced to limit attack surfaces, including external interfaces | The interfaces and ports that are open and why, and — more persuasively — what was deliberately closed, removed or disabled |
| 2(k) | Reducing the impact of an incident using appropriate exploitation mitigation mechanisms and techniques | Privilege separation, sandboxing, ASLR, stack protection, a memory-safe language choice. Name the mechanisms, not the intention |
| 2(l) | Providing security-related information by recording and monitoring relevant internal activity, with an opt-out for the user | Which events are logged, where the logs go, how long they are kept, and how a user opts out. The opt-out is part of the requirement, not a courtesy |
| 2(m) | Allowing users to securely and easily remove all data and settings permanently, and where data can be transferred to other products, that this is done securely | The factory-reset path, what it actually erases, and how an export or migration is protected. This row also answers the decommissioning part of your user instructions |
The one statement everything else rests on
Before the thirteen rows, record the security environment the product is designed for. This is also required as part of the user information under Annex II point 4, so it is written once and used twice.
It matters more than its length suggests. Every conclusion in the assessment is conditional on it. "Deployed on a segmented operational network behind a firewall, not directly reachable from the internet" makes a whole set of design decisions reasonable. The same product, assessed on the assumption that it is internet-facing, would need different answers to (d), (h), (i) and (j).
Assuming an environment you do not control. If nothing in the product enforces the assumption and nothing in the instructions states it, an assessor may reasonably ask what the assumption is doing in the document. Where the environment matters, say so in the user information under Annex II point 5 as foreseeable misuse — "exposing the management interface directly to the internet" — so the assumption and the warning match.
Writing it so broadly that it assumes nothing. An assessment that assumes a hostile network, a hostile local user and a hostile supply chain has to answer every requirement at the highest level, which for most products is neither achievable nor proportionate. The regulation asks for an appropriate level based on the risks identified, and identifying them narrowly and honestly is the point.
When a requirement does not apply
Some will not. A product with no user-facing data storage has little to say about secure deletion; a device with no network interface has little to say about impact on other networks.
The right answer is a reasoned not-applicable, not a blank. Annex VII's opening words ask for the listed elements "as applicable", so a statement that a requirement is not relevant, with the reason, is a legitimate entry. A blank row is not, because a reader cannot tell a considered exclusion from an oversight — and the assessor's next question will be which of the two it was.
Be careful with "not applicable" on the requirements that are almost always applicable: (a), (b), (c) and (f) are hard to escape for anything with software in it.
Part II is a process, not a property
Worth keeping separate in your head, because conflating them produces a document that answers neither well.
| Annex I Part I | Annex I Part II | |
|---|---|---|
| About | The product's properties | The manufacturer's process |
| Answered by | The risk assessment, requirement by requirement | The vulnerability-handling documentation, the SBOM and the disclosure policy |
| Lands in the file at | Annex VII point 3 | Annex VII point 2 |
| Changes when | The product changes | Rarely — but it must be running continuously, which is the harder discipline |
Note also that Annex VII point 6, the test reports, covers both parts. Evidence that your vulnerability-handling process actually runs — advisories published, reports triaged within the time your policy promises — belongs in the file as much as a penetration test does.
If you already run 27001 or 62443
Much of the underlying analysis is reusable and none of the output is. The difference is the addressee and the unit of analysis.
- ISO/IEC 27001 assesses risks to an organisation's information and produces a set of controls and a statement of applicability. The CRA assessment is about one product, and its addressee is a market surveillance authority asking about that product.
- IEC 62443-4-1 and -4-2 are much closer in substance, and a manufacturer working to them will find most Part I requirements already answered somewhere in their secure-development evidence. But note that these standards are not expected to be cited in the Official Journal as harmonised standards for the CRA, so working to them does not give you a presumption of conformity. Cite them as what they are: the technical references you followed, part of the description of the solutions adopted under Annex VII point 5.
The practical move is to write the thirteen rows as a mapping into evidence you already hold rather than as new prose. A row that says "addressed by control X in our 62443-4-1 practice, evidence at Y" is a better answer than a paragraph written from scratch, and it is cheaper to keep true.
An honest note on confidence: the count, lettering and substance of Annex I Part I's thirteen requirements and Part II's eight duties were each confirmed against two independent reproductions of the annex, which agreed. The requirement wording in the table above is our paraphrase, not the Official Journal text. The second column is our own view of what a persuasive answer contains and is not derived from any regulator's guidance — treat it as engineering advice rather than a compliance statement. The claim that IEC 62443 is not expected to be cited as a harmonised standard comes from published commentary on the standardisation request rather than from the Commission, and could change. Nothing here is legal advice.
Thirteen boxes, with the requirement above each one
Conformance House asks you about each Annex I Part I requirement in turn, with the requirement and a prompt in front of you, and builds the assessment from your answers — then flags it as incomplete, and refuses to generate a declaration of conformity, while any row is unaddressed.
Not sure you are in scope, or which class you are in? Take the two-minute check first.