What it is, and why everything else hangs off it
Article 13 requires you to assess the cybersecurity risks of the product and to take the outcome into account through planning, design, development, production, delivery and maintenance. It is not a separate compliance exercise sitting beside the product. It is the document that decides which of the essential requirements apply to you and how you meet each one.
That is why it matters more than its length suggests. The technical file points to it, the declaration of conformity rests on it, and an assessor reading your file will use it to test whether the rest is coherent. A weak risk assessment does not fail on its own — it makes every other artefact unverifiable.
The minimum contents
The Regulation does not prescribe a format or a methodology, but it does set a floor. The assessment must be documented, kept up to date for the support period, and cover at least the following.
| Element | What the text requires | In practice |
|---|---|---|
| Purpose and use | An analysis based on the intended purpose and the reasonably foreseeable use of the product. | Include foreseeable misuse. "Our customers only run it on an internal network" is an intended use; running it on the open internet is a foreseeable one. |
| Conditions of use | The conditions of use, such as the operational environment and the assets to be protected. | Name the assets: credentials, customer data, device control, the update channel. A threat with no asset attached is not analysable. |
| Time in use | Account taken of the length of time the product is expected to be in use. | This is where the support period is reasoned from. A controller in the field for ten years faces different threats in year eight than on launch day. |
| Security requirements | Whether, and in what manner, each Annex I Part I point 2 requirement applies, and how it is implemented. | Thirteen rows, one per requirement, each either implemented with evidence or excluded with a reason. This is the core of the document. |
| General obligation | How the manufacturer applies Annex I Part I point 1 — an appropriate level of cybersecurity based on the risks. | The link between your risk ratings and your controls. Why this much protection and not more or less. |
| Vulnerability handling | How the manufacturer applies the vulnerability handling requirements in Annex I Part II. | Point to your SBOM process, disclosure policy, update mechanism and advisory practice. Short, but it must be there. |
Would rather not write the Article 13 risk assessment from scratch? CRA Bureau drafts it from your own product, free to start.
Try it freeThe thirteen requirements you must map
Annex I Part I point 2 lists the security properties a product must have "on the basis of the cybersecurity risk assessment and where applicable". The two qualifiers are what make the risk assessment necessary: it is the place you establish what is applicable.
| Point | Requirement | When exclusion is arguable |
|---|---|---|
| (a) | Placed on the market without known exploitable vulnerabilities. | Almost never. This one applies to everyone. |
| (b) | Secure-by-default configuration, with the ability to reset to the original state. | Rarely. A library can argue its defaults belong to the integrator; an application cannot. |
| (c) | Vulnerabilities addressable through security updates — automatic by default where applicable, with an opt-out. | Automatic updates can be excluded where an integrator or administrator controls deployment. Updates themselves cannot. |
| (d) | Protection from unauthorised access: authentication, identity and access management. | A single-user offline tool with no network surface and no stored secrets. |
| (e) | Confidentiality of stored, transmitted and processed data, for example by encryption. | Only where the product genuinely handles no data worth protecting — rarer than it sounds. |
| (f) | Integrity of data, commands, programs and configuration, and reporting of corruption. | Rarely. Update integrity alone brings most products in. |
| (g) | Data minimisation — only data adequate, relevant and limited to the intended purpose. | Products that process no personal or operational data at all. |
| (h) | Availability of essential functions, including resilience against denial of service. | Hard to exclude for anything networked. |
| (i) | Minimising negative impact on the availability of other devices and networks. | Standalone software with no network behaviour. |
| (j) | Limiting attack surfaces, including external interfaces. | Never excluded outright; the question is how far you went. |
| (k) | Reducing the impact of an incident through exploitation mitigation. | Rarely. Memory-safe languages and platform hardening are how this is usually met, not avoided. |
| (l) | Recording and monitoring security-relevant internal activity, with a user opt-out. | Simple components where there is no meaningful internal activity to log. |
| (m) | Letting users securely remove all data and settings, and transfer data where possible. | Products that store nothing on behalf of the user. |
A method that holds up
Any recognised method will do — STRIDE, ISO/IEC 27005, IEC 62443-style zones and conduits, or a plain likelihood-and-impact matrix. What an assessor checks is not which method you chose but whether you applied it consistently and whether its output actually drove your design decisions.
- Describe the product boundary: what you ship, what you depend on, what the customer supplies.
- List the assets worth protecting and the interfaces through which they can be reached.
- Identify threats against each asset and interface, including foreseeable misuse.
- Rate each risk before controls, choose a treatment, and rate it again after.
- Tie every treatment to the Annex I point it satisfies. This is the step most registers skip.
- Record the residual risk you are accepting, and who accepted it.
- Justify every requirement you exclude, in the product’s own terms.
Justifying "not applicable"
Third-party components are your risk too
You must exercise due diligence when integrating third-party components, open source included, so that they do not compromise the product’s security. In practice that means your risk assessment has to account for your dependency tree — which is why it should draw on the SBOM rather than being written in isolation from it.
The useful posture is simple: every component is a supply-chain risk you have accepted, and the SBOM plus continuous vulnerability monitoring is the control. Name both in the assessment.
When to update it
The assessment must be kept up to date during the support period. A version dated the week before launch and never touched again is exactly what an assessor expects to find, and exactly what they will ask about.
- A new feature, interface or deployment mode.
- A new or substantially changed third-party component.
- An actively exploited vulnerability or severe incident — the Article 14 report and the risk assessment should tell the same story.
- A change to the intended purpose, or evidence of a foreseeable use you had not considered.
- On a fixed cycle regardless — at least annually, and before each major release.
The mistakes that get it sent back
- Submitting the company’s ISO 27001 risk register. That assesses the organisation; Article 13 assesses the product.
- Listing risks with no link to the Annex I requirements. The mapping is what the document is for.
- Ignoring foreseeable misuse because the documentation says not to do it.
- Rating risks without saying what the rating scale means.
- Dating it once and never revising it.