The CRA risk assessment and technical documentation are not separate end-stage paperwork exercises. The risk assessment drives product security decisions and Annex I applicability, while the technical documentation preserves the product description, architecture, security design, risk reasoning, vulnerability-handling processes, verification evidence and conformity information needed to demonstrate how the manufacturer met the Regulation.
The CRA Makes Cybersecurity Risk Assessment a Manufacturer Obligation
Article 13 requires manufacturers to ensure that products with digital elements are designed, developed and produced in accordance with the essential cybersecurity requirements in Annex I. For that purpose, manufacturers must undertake an assessment of the cybersecurity risks associated with the product. The outcome is not intended to sit unused in a compliance folder. Article 13 requires it to inform planning, design, development, production, delivery and maintenance with the objective of minimising cybersecurity risks, preventing incidents and minimising their impact, including risks relating to the health and safety of users.
- Perform the assessment for the product with digital elements.
- Use the result during the complete product lifecycle.
- Connect identified risks to design and process decisions.
- Use the assessment to inform Annex I implementation.
- Update the assessment when appropriate.
The Risk Assessment Must Follow the Product Lifecycle
A CRA cybersecurity risk assessment should begin early enough to influence architecture and product requirements. Waiting until release can turn it into a retrospective justification exercise. The assessment should remain relevant as the product moves through development, production, delivery and maintenance. New interfaces, dependencies, deployment environments, vulnerabilities and product functions can change the risk picture. Article 13 therefore requires the documented assessment to be updated as appropriate during the support period. Product security governance should define which changes trigger reassessment and who is responsible for approving updated risk conclusions.
- Begin during planning and architecture.
- Review during development.
- Confirm assumptions before release.
- Update after material product changes.
- Update when new vulnerability information changes risk.
Intended Purpose Anchors the Assessment
Article 13 requires the risk analysis to be based on the intended purpose and reasonably foreseeable use of the product, together with its conditions of use. Intended purpose defines what the manufacturer says the product is designed to do, who it is for and the relevant operating assumptions. This matters because the same software component can present very different cybersecurity consequences when used in a consumer device, administrative system or industrial environment. The assessment should therefore describe the intended product function and security-relevant operating assumptions with enough precision that later threat, control and testing decisions can be traced back to them.
- Define the product's intended function.
- Identify intended users and operators.
- Define important deployment assumptions.
- Identify security-relevant dependencies.
- Connect risk scenarios to actual intended use.
Reasonably Foreseeable Use Extends Beyond Perfect Operation
The assessment cannot assume that every user will operate the product exactly as the manufacturer prefers. Article 13 includes reasonably foreseeable use. Product teams should therefore consider predictable deployment patterns, configuration choices, exposed interfaces and operational behaviours that can occur in practice. This does not mean analysing every theoretically imaginable misuse. The objective is to identify uses and conditions that are sufficiently foreseeable to matter to the product's cybersecurity. Later Cluster 8 articles can distinguish intended use from reasonably foreseeable misuse and document the scenarios consistently.
- Consider realistic deployment behaviour.
- Consider predictable configuration choices.
- Consider foreseeable exposure of interfaces.
- Avoid relying only on ideal operating assumptions.
- Document important assumptions and exclusions.
Conditions of Use, Environment and Protected Assets Matter
Article 13 identifies conditions of use as part of the minimum risk-analysis context and gives examples such as the operational environment and assets to be protected. Product teams should therefore identify the systems, information, credentials, functions and connected services whose compromise could create relevant cybersecurity consequences. The operational environment can change attacker access, available protections and consequences. A product expected to operate inside a managed enterprise environment may rely on different assumptions from a directly internet-connected consumer device. Those assumptions should be explicit rather than left implicit in the security architecture.
- Identify the operational environment.
- Identify data and system assets.
- Identify privileged functions and credentials.
- Identify external services and dependencies.
- Document environmental security assumptions.
Expected Product Use Duration Affects Risk Decisions
Article 13 requires the risk assessment to take into account the length of time the product is expected to be in use. This matters because cybersecurity threats, dependencies and vulnerability information change over time. A product expected to operate for many years can need a different update architecture, dependency-maintenance approach and support strategy from a short-lived product. The assessment should connect expected use duration with support-period planning, vulnerability handling, security updates and the manufacturer's ability to maintain the relevant security controls over time.
- Estimate expected product use duration.
- Consider long-term dependency maintenance.
- Consider update capability.
- Consider vulnerability-handling capacity.
- Connect expected use with support-period decisions.
The Assessment Must Address Annex I Applicability
Article 13 requires the cybersecurity risk assessment to indicate whether and, if so, how the security requirements in Annex I Part I point 2 are applicable to the product and how those requirements are implemented as informed by the assessment. It must also indicate how the manufacturer applies the general risk-appropriate cybersecurity requirement in Part I point 1 and the vulnerability-handling requirements in Part II. This makes Annex I applicability part of the risk-assessment record rather than a separate unexplained checklist. Where an essential cybersecurity requirement is not applicable, the manufacturer must include a clear justification in the technical documentation.
- Map Annex I Part I point 2 requirements.
- Record whether each requirement applies.
- Describe how applicable requirements are implemented.
- Explain how Part I point 1 is applied.
- Explain how Part II vulnerability handling is applied.
- Justify non-applicability clearly.
Risk Treatment Should Lead to Product Decisions
Once risks are identified and assessed, the manufacturer needs traceable treatment decisions. Product teams can reduce exposure through architecture, access control, secure defaults, cryptography, resilience, attack-surface reduction, exploit mitigation, logging, monitoring, update mechanisms and other controls appropriate to the product. Some risks can depend partly on environmental or user controls. The important compliance point is that treatment decisions should be connected to the identified risk and the applicable Annex I outcome. A generic statement that industry best practices were followed is weaker than a record showing why a control was selected for a specific product risk.
- Identify the risk requiring treatment.
- Select proportionate controls.
- Record responsible implementation owners.
- Define verification methods.
- Record residual risk and assumptions.
Technical Documentation Is the Evidence Structure Around the Product
Article 31 requires the technical documentation to contain relevant data and details about the means used by the manufacturer to ensure that the product and the manufacturer's processes comply with Annex I. The technical documentation must contain at least the applicable elements in Annex VII. It should therefore bring together product identification, architecture, security design, vulnerability-handling information, the cybersecurity risk assessment, standards or other specifications used, test reports and other required conformity evidence. The technical documentation is broader than the risk assessment, but the risk assessment is one of its central inputs.
- Document the product and relevant versions.
- Document design, development and production information.
- Document vulnerability-handling processes.
- Include the cybersecurity risk assessment.
- Document standards or other technical solutions.
- Include conformity and security test reports.
Annex VII Defines the Minimum Technical Documentation Content
Annex VII lists the minimum technical documentation information applicable to the product. It includes a general product description and intended purpose, software versions affecting compliance, relevant user information, design and development information, system architecture where applicable, production and monitoring processes, vulnerability-handling processes, the cybersecurity risk assessment, support-period information, applicable harmonised standards or other specifications, test reports, the EU declaration of conformity and, where applicable under the Regulation, the software bill of materials. Teams should use Annex VII as a minimum content map while keeping additional evidence needed for their product's risk and conformity route.
- General product description.
- Intended purpose and relevant software versions.
- Architecture and design information.
- Production and monitoring information.
- Vulnerability-handling process documentation.
- Cybersecurity risk assessment.
- Support-period information.
- Standards, specifications and adopted solutions.
- Test reports.
- EU declaration of conformity.
- SBOM where applicable under Annex VII.
Technical Documentation Must Exist Before Market Placement
Article 31 requires technical documentation to be drawn up before the product with digital elements is placed on the market. That timing affects project planning. Security architecture, risk reasoning and test evidence should not be collected only after commercial release. A release-readiness process can verify that the required technical documentation exists, the cybersecurity risk assessment matches the released product, important security tests have completed and unresolved risk decisions have accountable owners. This also provides a stronger basis for the applicable conformity-assessment procedure.
- Prepare documentation before market placement.
- Align documents with the released product version.
- Complete required verification before release.
- Resolve missing or contradictory evidence.
- Use documentation as an input to conformity assessment.
The Documentation Must Remain Current
Article 31 requires the technical documentation to be continuously updated where appropriate, at least during the support period. This complements Article 13, which requires the cybersecurity risk assessment to be updated as appropriate. Manufacturers should therefore define document-change triggers for product architecture, software versions, dependencies, vulnerability-handling processes, security controls, support-period assumptions and test evidence. Version control should make it possible to determine which documentation and evidence correspond to each relevant product release.
- Define documentation update triggers.
- Link documentation to product releases.
- Retain change history.
- Replace or supersede outdated test evidence deliberately.
- Maintain documentation during the support period.
Risk Assessment and Documentation Should Support Conformity Assessment
The risk assessment and technical documentation provide the evidence base for evaluating whether the applicable essential cybersecurity requirements have been met. The exact conformity-assessment route depends on the product and Article 32, but weak traceability creates problems regardless of the route. Reviewers should be able to identify the product, understand the cybersecurity risks, see which Annex I requirements apply, trace those requirements to design and process controls and find the verification evidence supporting the manufacturer's conclusion.
- Identify applicable Annex I requirements.
- Trace requirements to controls.
- Trace controls to verification evidence.
- Maintain version-specific documentation.
- Resolve evidence gaps before conformity assessment.
A Practical Cluster 8 Documentation Model
The rest of this cluster moves from the high-level obligation into the working documents a manufacturer may need. It covers how to perform the cybersecurity risk assessment, what it should contain, intended use, foreseeable misuse, threat scenarios, risk assessment, treatment decisions, Annex VII technical documentation, architecture and security-design records, test evidence, vulnerability-handling documentation, maintenance after product changes, version control and construction of the final technical file. The objective is to keep each page focused on one operational problem while preserving traceability back to Article 13 and Article 31.
- Define the risk-assessment method.
- Document product context and use.
- Analyse threats and cybersecurity risks.
- Record risk treatment.
- Build Annex VII evidence.
- Maintain version and change traceability.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.