A Cyber Resilience Act cybersecurity risk assessment is a documented product-security analysis that manufacturers must use throughout planning, design, development, production, delivery and maintenance. It should explain the product context, intended and reasonably foreseeable use, operating conditions and assets to protect, identify relevant cybersecurity risks, show how those risks inform the applicable Annex I requirements, and remain updateable during the support period.
What Article 13 requires
Article 13 of Regulation (EU) 2024/2847 makes the cybersecurity risk assessment part of the manufacturer's product lifecycle rather than a document produced only for conformity assessment.
The manufacturer must assess cybersecurity risks associated with the product and take the outcome into account during planning, design, development, production, delivery and maintenance. The purpose is to minimise cybersecurity risks, prevent incidents and minimise their impact, including possible effects on users' health and safety.
The assessment must be documented and updated as appropriate during the support period. At minimum, Article 13(3) requires the analysis to consider:
- the intended purpose of the product;
- reasonably foreseeable use;
- conditions of use, including the operational environment;
- the assets that need protection; and
- the length of time the product is expected to be in use.
The assessment also needs to show whether the security requirements in Annex I Part I point (2) apply to the product, how applicable requirements are implemented, and how the manufacturer will apply the broader product-security and vulnerability-handling requirements in Annex I.
When the product is placed on the market, the cybersecurity risk assessment becomes part of the technical documentation required by Article 31 and Annex VII. If a manufacturer concludes that a particular essential cybersecurity requirement is not applicable, the technical documentation must contain a clear justification.
Start with the product boundary
A risk assessment cannot be more precise than the product it describes. Before listing threats, define the product boundary closely enough that engineering, security and compliance teams are assessing the same thing.
Record the product family, variants, versions, responsible manufacturer entity, intended purpose and supported deployment models. Identify the hardware, firmware, software, interfaces and remote processing that belong to the product context. Map separately supplied components and important third-party dependencies where they can affect the security analysis.
For an Austrian manufacturer selling into the EU, the same commercial product name may cover materially different technical variants. A connected industrial controller, for example, can have different interfaces, operating assumptions or optional remote services depending on the deployment. Those differences can create different attack paths and treatment decisions even when the marketing name is unchanged.
The useful output is an assessment scope that can be tied to exact engineering facts. If a reviewer cannot tell which architecture, release family or deployment model the assessment covers, later evidence will be difficult to interpret.
Define intended and reasonably foreseeable use
The CRA explicitly requires both intended purpose and reasonably foreseeable use to inform the assessment. That means the manufacturer should not analyse only the ideal deployment described in a product requirement.
Document how the product is expected to be installed, administered, connected and maintained. Then examine foreseeable operating patterns that may differ from the preferred configuration. Examples can include deployment behind a shared gateway, connection to third-party management systems, use of removable media, exposed local interfaces, long-lived credentials, delayed maintenance windows or operation in networks with different trust assumptions.
Reasonably foreseeable use is not a requirement to imagine every theoretically possible misuse. The goal is to capture realistic conditions that can change cybersecurity risk. Product documentation, field experience, integration guides, supported interfaces and known customer deployment patterns can all inform that analysis.
This step should also identify security-relevant assumptions. If a control depends on a trusted administrator, isolated network segment or external identity provider, record that dependency. An assumption that is invisible in the risk assessment is difficult to validate later.
Identify assets and security objectives before scoring threats
Risk scoring is useful only after the team understands what it is protecting. Start with product assets and the security properties that matter to users and product functions.
Depending on the product, assets may include credentials, configuration, user data, safety-relevant parameters, update metadata, cryptographic material, audit records, control commands, service availability or the integrity of software executed by the product.
For each asset or function, define relevant objectives such as confidentiality, integrity, authenticity, availability or controlled access. The CRA's Annex I requirements provide a regulatory frame, but the assessment still needs product-specific reasoning about consequences.
A loss of availability in a casual consumer feature is different from loss of availability in a component used in an industrial process. Likewise, unauthorised modification of a cosmetic preference is different from modification of an access-control rule or security configuration.
This is where health and safety impacts should be considered when they are relevant to the product. Article 13 specifically includes minimising incident impact in relation to users' health and safety, so teams should not isolate cybersecurity analysis from physical consequences where the product can create them.
Model credible threat scenarios
The CRA does not prescribe one mandatory threat-modelling framework or risk-scoring formula. Manufacturers therefore need a repeatable method that fits the product while still producing the information Article 13 requires.
A practical threat analysis can examine:
- exposed interfaces and trust boundaries;
- attacker access and required capabilities;
- misuse of authentication, authorisation or privilege;
- compromise of data in storage or transit;
- manipulation of software, configuration or update paths;
- abuse of remote services or APIs;
- denial of service and resource exhaustion;
- third-party component and supply-chain risks;
- logging, detection and recovery limitations; and
- lifecycle risks created by support, maintenance or decommissioning.
Threat scenarios should be specific enough to support a treatment decision. "Device can be hacked" is not useful. A stronger scenario identifies an interface, precondition, attacker action, affected asset and plausible consequence.
For example, instead of recording "unauthorised access", a team might analyse whether a network-reachable maintenance interface could allow an unauthenticated actor to modify security configuration when the product is deployed in a foreseeable flat network. That scenario can then be connected to an access-control requirement, implementation decision and verification evidence.
Assess risk with documented reasoning
A manufacturer can use a qualitative or quantitative method, provided the method is consistent and the result supports product decisions. Common factors include likelihood, exploitability, exposure, impact, detectability, affected user population and the difficulty of recovery.
The important control is not the arithmetic. It is the reasoning behind the rating. Record the facts, assumptions and uncertainty that produce the result.
A risk register entry should make it possible to answer:
- Which product context does this risk apply to?
- What threat scenario is being assessed?
- Which assets or security objectives are affected?
- Which assumptions influence likelihood or impact?
- What existing controls reduce the risk?
- What treatment is planned?
- Who owns the treatment decision?
- What evidence will show that the treatment was implemented?
- What residual risk remains after treatment?
Avoid using a vulnerability severity score as a substitute for product risk. CVSS or another technical severity measure can be an input when a vulnerability exists, but the CRA risk assessment is broader: it informs design and lifecycle security before and after individual vulnerabilities are known.
Map risks to the essential cybersecurity requirements
The assessment should drive the applicability and implementation of Annex I rather than becoming a parallel document.
Annex I Part I covers product security properties such as an appropriate level of cybersecurity based on risk, secure-by-default configuration, protection from unauthorised access, confidentiality and integrity of relevant data, data minimisation, availability and resilience, reduction of attack surfaces, exploitation mitigation, and security logging or monitoring where applicable. Annex I Part II addresses vulnerability handling throughout the support period.
For each relevant risk, map the treatment to one or more applicable requirements and then to the engineering control that implements them. A useful traceability chain looks like this:
product context -> threat scenario -> risk decision -> Annex I requirement -> engineering control -> verification evidence -> residual-risk decision
Not every Annex I requirement will apply identically to every product. When a requirement is not applicable, Article 13(4) requires a clear justification in the technical documentation. That makes "not applicable" a decision that needs evidence, not an empty checkbox.
Include third-party components in the analysis
Article 13 requires manufacturers to exercise due diligence when integrating third-party components, including free and open-source software components. The risk assessment should therefore account for dependencies that can affect the product's security objectives.
This does not mean reproducing the supplier's complete internal security analysis. It means understanding the dependency in the manufacturer's own product context: what function it provides, which privileges it has, how it is updated, whether it is exposed to untrusted input, what happens if it is compromised, and how vulnerability information reaches the product team.
An SBOM can support this work by identifying components and versions, but it is not itself a risk assessment. Teams still need to connect component presence to product exposure, threat scenarios, treatment decisions and release evidence.
Changes in important dependencies are also natural reassessment triggers. Replacing an authentication library, adding a cloud SDK or introducing a new privileged service can change the threat model even if the visible product feature changes only slightly.
Define verification evidence while choosing controls
A treatment decision is stronger when the team decides at the same time how it will be verified. Security requirements should therefore link to planned evidence rather than being marked complete on implementation alone.
Evidence can include architecture reviews, threat-model records, security test results, configuration validation, static or dynamic analysis, dependency checks, penetration-test findings, fuzzing results, access-control tests, update tests, vulnerability decisions or release approvals, depending on the risk and control.
The CRA does not require every product to use every test technique. The assessment should justify why the selected controls and assurance activities are proportionate to the risks of the product.
For high-impact risks, evidence may need to demonstrate several layers: the preventive control, its verification, any detection or recovery mechanism, and the residual-risk decision. For a lower-impact scenario, a simpler control and test may be proportionate.
Update the assessment when the product context changes
Article 13(3) requires the documented assessment to be updated as appropriate during the support period, and Article 13(7) requires relevant cybersecurity aspects to be documented systematically. A practical process therefore needs explicit reassessment triggers.
Useful triggers include:
- new interfaces, protocols or remote services;
- significant architecture or trust-boundary changes;
- new product variants or supported environments;
- substantial changes to authentication or authorisation;
- important third-party component changes;
- newly discovered vulnerabilities that change an existing threat assumption;
- exploitation evidence or incidents affecting the product;
- changes in intended purpose or reasonably foreseeable use;
- security controls that fail verification; and
- support or maintenance changes that alter exposure or recovery capability.
Do not silently overwrite the previous assessment. Preserve decision history so a reviewer can understand what was known for a particular release and why the assessment later changed.
Use one assessment record across engineering and technical documentation
The technical documentation needs the cybersecurity risk assessment, but creating a separate compliance-only copy introduces drift. A better operating model is to keep one controlled assessment record and reference the engineering evidence that supports it.
The record should identify its product scope, version or lifecycle context, authors and reviewers, assessment date, methodology, risks, treatment decisions, requirement mappings, evidence references, residual risks and reassessment triggers. Release processes can then check whether the assessment is current for the product being released.
This is also a strong product-relevance point for lifecycle tooling. Risk assessments become difficult to maintain when requirements, evidence and decisions drift into separate systems as the product changes. AA-sec is designed around traceability between requirements, security evidence, decisions and exact product or lifecycle context, which can help keep assessment rationale connected to the evidence that supports it. The manufacturer still owns the risk judgement and the legal conformity decision.
Use external guidance without confusing it with the law
The European Commission published non-binding CRA implementation guidance on 27 July 2026 that includes practical clarification on risk assessment. Manufacturers should use that guidance alongside the Regulation and continue to monitor later Commission material as implementation develops.
The German Federal Office for Information Security, BSI, also publishes TR-03183, "Cyber Resilience Requirements for Manufacturers and Products". Part 1, "General Requirements", is currently published as preliminary version 0.9.0 and is being revised after a community comment period. It can be useful as technical implementation guidance, but it is not a replacement for Regulation (EU) 2024/2847 or future harmonised standards.
For Austrian organisations, that distinction is important when building internal procedures: authoritative legal obligations should be traced to the CRA and applicable EU acts, while technical guidance can help make the engineering process more concrete.
A practical assessment workflow
A first implementation does not need an elaborate scoring platform. It needs a repeatable sequence and accountable evidence.
- Define the product boundary. Record the exact product, variants, manufacturer role, intended purpose, interfaces and supported environments.
- Describe use and assumptions. Capture intended use, reasonably foreseeable use, operating conditions and security dependencies.
- Identify assets and objectives. Define what must be protected and which security properties matter.
- Model threat scenarios. Analyse realistic attacker paths, trust boundaries, third-party dependencies and lifecycle risks.
- Assess and prioritise risk. Use a consistent method and document assumptions, uncertainty and rationale.
- Map Annex I requirements. Identify applicable requirements and justify any non-applicability decisions.
- Define treatments and evidence. Connect controls to owners, implementation work and verification evidence.
- Record residual-risk decisions. Preserve accountable acceptance, further treatment or release-blocking decisions.
- Publish the controlled assessment into technical documentation. Keep the compliance view connected to the engineering source of evidence.
- Reassess on defined triggers. Update the record when architecture, dependencies, use conditions, vulnerabilities or support assumptions materially change.
What good looks like before 2027
The CRA's main obligations apply from 11 December 2027, so manufacturers can use the remaining implementation period to make risk assessment part of normal product engineering. The goal is not to produce a perfect document once. It is to establish a controlled process that remains useful as the product evolves.
Select one representative product and test whether the team can move from product boundary to threat scenarios, Annex I applicability, treatment decisions and verification evidence without reconstructing information from unrelated documents. Then change one product assumption, such as adding a remote interface or replacing an authentication component, and verify that the reassessment process identifies what needs review.
A mature Cyber Resilience Act cybersecurity risk assessment should let a later reviewer understand what product was assessed, which risks mattered, how those risks shaped security requirements, what evidence supports the implemented controls, what residual risks were accepted, and why the assessment changed over time. That is the level of traceability needed for a lifecycle process rather than a one-time conformity exercise.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Cyber Resilience Act - Manufacturers — European Commission
- Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission
- BSI TR-03183: Cyber Resilience Requirements for Manufacturers and Products — BSI