Cybersecurity Risk Assessment

A cybersecurity risk assessment is a structured evaluation of the security risks facing a product throughout its lifecycle - from design and development through deployment, operation, and end of life. It identifies assets worth protecting (data, functionality, safety systems), enumerates plausible threat actors and their capabilities, maps attack paths against the product's attack surface, evaluates the likelihood and impact of each threat scenario, and identifies controls that reduce risk to an acceptable level. The process is typically documented and updated iteratively as the product evolves. Common frameworks include ISO/IEC 27005, IEC 62443-3-2, and ETSI EN 303 645.

Article 13(1) of the CRA explicitly requires manufacturers to undertake a cybersecurity risk assessment of their product and to take the outcomes into account during planning, design, development, production, delivery, and maintenance. The risk assessment is not a one-time document: it must be updated whenever new vulnerabilities are identified or when the product's intended use or operating environment changes materially. The assessment forms the analytical foundation for technical documentation (Article 23) and for demonstrating conformity with Annex I essential requirements. Without a documented risk assessment, a manufacturer cannot credibly claim their product meets the CRA's cybersecurity baseline.

A CRA-compliant risk assessment should follow a repeatable methodology and produce documented outputs that can be shared with conformity assessment bodies. Key steps include: (1) defining the scope - the product, its components, data flows, and operational environment; (2) identifying threats using a structured method such as STRIDE or attack trees; (3) evaluating likelihood and impact for each threat scenario, often using CVSS as a reference scoring system; (4) mapping existing controls and identifying residual risks; (5) documenting accepted risks with justification; (6) recording the assessment date and committing to a review schedule. The output should be traceable to specific Annex I requirements.

Manufacturers frequently produce a risk assessment at the start of development and then treat it as immutable, failing to update it when new vulnerabilities emerge in third-party components or when the product's connectivity changes. A second common error is confusing a risk register with a risk assessment: a list of risks without threat modelling, impact analysis, or control mapping does not satisfy the CRA's requirements. Assessments that ignore supply chain risks - for example, risks introduced by open-source components or subcontracted firmware - are increasingly flagged by market surveillance authorities as incomplete.