The legal minimum gives manufacturers the required subject matter but not one mandatory document template. A practical CRA risk assessment can add product and version identifiers, assets, trust boundaries, threat scenarios, vulnerabilities, risk ratings, controls, residual risk, owners, verification references and change history. These fields help prove how the Article 13 analysis actually influenced the product.
Start With the Article 13 Minimum
Article 13 defines minimum subject matter for the cybersecurity risk assessment but does not prescribe one universal worksheet or risk-register format. Manufacturers should make sure their chosen format captures every required element before adding organisation-specific scoring, workflow and governance fields. The minimum includes intended purpose, reasonably foreseeable use, conditions of use, operational environment or assets to be protected, expected use duration and the application of Annex I requirements. The document should make those elements identifiable rather than leaving them scattered across unrelated engineering records.
- Intended purpose.
- Reasonably foreseeable use.
- Conditions of use.
- Operational environment.
- Assets to be protected.
- Expected product use duration.
- Annex I applicability and implementation.
Identify the Product and Version Covered
A practical assessment should clearly identify the product and relevant version or release baseline. Article 13 links the assessment to a product with digital elements, while Annex VII requires product description and relevant software-version information in the technical documentation. Product identification prevents later ambiguity about whether a risk conclusion applies to the current version, an earlier architecture or a different product edition. Where several variants share one assessment, the document should identify the shared elements and any variant-specific differences that affect cybersecurity risk.
- Product name and model.
- Hardware revision where relevant.
- Software or firmware version.
- Product edition or deployment profile.
- Assessment version and date.
Document Intended Purpose
The assessment should state the product's intended purpose with enough detail to support security reasoning. Identify intended functions, expected users, administrators and deployment context. Intended purpose becomes important when deciding which data are necessary, which interfaces are required, what level of availability is expected and whether environmental controls can reasonably be assumed. A marketing description that says only that the product provides secure connectivity is unlikely to provide enough detail for a defensible cybersecurity risk analysis.
- Core product functions.
- Intended users.
- Administrative roles.
- Expected deployment context.
- Security-relevant functional assumptions.
Document Reasonably Foreseeable Use
Article 13 requires analysis based not only on intended purpose but also reasonably foreseeable use. The assessment should therefore document realistic ways the product may be deployed or operated that affect cybersecurity risk. This can include foreseeable exposure of management interfaces, common configuration choices, connection to external systems or operating practices that differ from the ideal reference architecture. The record should distinguish foreseeable scenarios from highly speculative possibilities so that product teams focus on meaningful security conditions.
- Common deployment variations.
- Foreseeable configuration choices.
- Predictable exposure conditions.
- Likely integration patterns.
- Operational behaviour affecting risk.
Document Conditions of Use
Conditions of use describe the context in which the product operates. They can include network environment, physical environment, platform, administrative model, connectivity, privilege level and dependencies on other security controls. Conditions matter because a risk can change substantially when an interface moves from an isolated network to direct internet exposure or when a product moves from a professionally administered system to consumer self-installation. Important assumptions should be explicit enough that later product or deployment changes can trigger reassessment.
- Network conditions.
- Platform conditions.
- Physical-access conditions.
- Administrative conditions.
- External dependency assumptions.
Describe the Operational Environment
Article 13 gives the operational environment as an example of the conditions that the assessment should consider. A useful record can identify whether the product operates in managed enterprise, industrial, consumer, mobile, cloud, embedded or other relevant environments and which security protections the environment is expected to provide. Environmental assumptions should not be used to avoid reasonable product protections without analysis. If security depends on segmentation, an identity provider or physical access controls, the assessment should make that dependency visible.
- Deployment environment.
- Network exposure.
- Platform security assumptions.
- External security services.
- Environmental control dependencies.
Identify Assets to Be Protected
Article 13 also identifies assets to be protected as part of the risk-analysis context. The assessment should identify information, functions and security state whose compromise matters. Assets can include credentials, personal data, operational data, cryptographic keys, configuration, software integrity, essential product functions, update infrastructure and connected systems. Asset identification provides the link between an attack scenario and its consequence. Without that link, teams can produce generic threat lists that do not explain why a scenario creates cybersecurity risk for the product.
- Data assets.
- Credential and key assets.
- Configuration assets.
- Software and firmware integrity.
- Essential functions.
- Connected systems and services.
Include Expected Product Use Duration
The risk assessment must take into account the length of time the product is expected to be in use. Record the relevant assumption and explain how it affects security maintenance where appropriate. Expected use duration can influence dependency support, cryptographic choices, update capability, vulnerability-management resources and support-period planning. The risk document does not need to duplicate every support-period decision, but it should make clear that long-term security exposure has been considered rather than analysing only the release-day threat environment.
- Expected use duration.
- Long-term dependency assumptions.
- Update and maintenance capability.
- Vulnerability-handling implications.
- Relevant support-period relationship.
Record Annex I Part I Point 2 Applicability
Article 13 requires the assessment to indicate whether and in what manner the security requirements in Annex I Part I point 2 apply to the product. The assessment should therefore contain a requirement-by-requirement applicability view or a reliable reference to one. For applicable requirements, record how implementation is informed by the risk assessment. For requirements considered not applicable, Article 13 requires clear justification in the technical documentation. Leaving a requirement blank does not show whether it was reviewed, overlooked or judged irrelevant.
- Review every Part I point 2 requirement.
- Record applicable or not applicable.
- Map applicable requirements to implementation.
- Record product-specific reasoning.
- Provide clear justification for non-applicability.
Explain Application of Annex I Part I Point 1
Article 13 also requires the risk assessment to indicate how the manufacturer applies the general Annex I Part I point 1 requirement that the product be designed, developed and produced to ensure an appropriate level of cybersecurity based on risk. This is the link between the complete risk analysis and the overall product security posture. The assessment should therefore not be limited to individual point 2 controls. It should show how the collection of controls, architecture and process decisions creates a risk-appropriate level of cybersecurity for the specific product.
- Describe the overall cybersecurity approach.
- Connect security architecture to identified risks.
- Explain important defence-in-depth decisions.
- Record significant residual risks.
- Link the conclusion to product verification.
Explain Application of Annex I Part II
The assessment must also indicate how the manufacturer applies the vulnerability-handling requirements in Annex I Part II. The risk assessment can reference the manufacturer's vulnerability identification, SBOM, security testing, remediation, disclosure, reporting channel and secure-update processes rather than reproduce every operational procedure. The important point is to show that vulnerability handling forms part of the product's continuing cybersecurity strategy and is not disconnected from the risks identified during design.
- Vulnerability and component identification.
- SBOM process.
- Security testing and review.
- Risk-based remediation.
- Coordinated vulnerability disclosure.
- Secure update distribution.
Add Threat and Attack Scenario Records
Article 13 does not prescribe a specific threat-scenario template, but maintaining scenarios is a practical way to demonstrate how product context leads to identified cybersecurity risks. Each significant scenario can identify the attacker or failure condition, entry point, affected component, target asset, preconditions and potential consequence. This makes risk ratings more understandable and gives security testing a concrete target. Future documentation can reference the scenario identifier rather than repeating the complete analysis in every test report or control record.
- Scenario identifier.
- Threat source or failure condition.
- Entry point.
- Affected component.
- Target asset.
- Potential cybersecurity consequence.
Add Risk Evaluation Fields
A practical assessment needs a consistent way to distinguish higher and lower risks. The CRA does not prescribe one universal score. Manufacturers can therefore use a documented qualitative or quantitative approach suited to their product. Useful fields can include likelihood or attack feasibility, impact, existing controls, overall risk rating and rationale. The rationale matters because a number without context can be difficult to defend when threat conditions change. The method should support prioritisation and traceability rather than create artificial mathematical precision.
- Likelihood or attack feasibility.
- Impact.
- Existing controls.
- Risk rating.
- Rating rationale.
- Assessment confidence where useful.
Add Risk Treatment and Residual Risk
For each significant risk, record the treatment decision. This can include design changes, technical controls, process controls, operational assumptions or another justified response. Record the owner and expected verification. After implementation and testing, assess residual risk. This separates the initial risk from the risk that remains after treatment. A treatment field also makes it easier to show how the Article 13 assessment affected product design rather than remaining a descriptive analysis with no engineering consequences.
- Treatment decision.
- Mapped product control.
- Implementation owner.
- Verification method.
- Residual risk.
- Acceptance or escalation decision.
Add Evidence References
The risk assessment becomes more useful when it points to the evidence supporting its conclusions. References can include architecture diagrams, design records, source-review results, penetration tests, vulnerability scans, update tests, resilience tests, configuration verification and process records. Evidence does not need to be embedded physically inside one giant assessment document. It should be controlled and identifiable so that a reviewer can retrieve the record corresponding to the product version and risk decision.
- Architecture evidence.
- Security design evidence.
- Test reports.
- Configuration evidence.
- Vulnerability records.
- Update and release evidence.
Include Change History and Reassessment Status
Because Article 13 requires the assessment to be updated as appropriate during the support period, the record should show its current version and relevant change history. Useful fields include assessment version, product version, review date, reviewer, change reason and affected risk identifiers. The manufacturer can also record reassessment triggers or pending reviews. This provides a controlled trail from an earlier risk conclusion to the current one when architecture, vulnerabilities or operating assumptions change.
- Assessment version.
- Product version.
- Review date.
- Change reason.
- Affected risk records.
- Current approval or review status.
Keep the Legal Minimum and Practical Fields Distinct
It is useful to distinguish what Article 13 expressly requires from the extra structure a manufacturer chooses for effective engineering governance. Threat identifiers, numerical scores, named control owners and specific template columns can be useful, but they are not all prescribed CRA fields. Keeping this distinction clear prevents an internal template from being presented as though the Regulation mandates one exact methodology. The manufacturer remains responsible for ensuring that its chosen method captures the required risk analysis and provides sufficient evidence to support Annex I compliance.
- Label statutory content accurately.
- Label internal methodology fields separately.
- Do not present one template as universally mandatory.
- Ensure the chosen method still covers every Article 13 requirement.
- Maintain traceability into Article 31 technical documentation.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.