Running the CRA Risk Assessment in Practice: CVD Portal and Draft prEN 40000-1-2

Two earlier posts on this blog covered the CRA cybersecurity risk assessment as a method and as a link in the documentation chain. The working methodology showed how structured threat modelling and likelihood and impact scoring produce the analysis Article 13 demands, and the artifact chain showed where the result sits between classification and the technical file. This post covers the operational version. It walks through how the assessment is actually performed in CVD Portal's products workspace, step by step, and maps each step to Regulation (EU) 2024/2847 and to draft prEN 40000-1-2, the horizontal European standard being written for exactly this process.

The legal frame is short. Article 13(2) requires manufacturers to assess the cybersecurity risks of a product with digital elements and to take the outcome into account across planning, design, development, production, delivery and maintenance. Article 13(3) requires the assessment to be documented, kept up to date during the support period, and to state which of the essential requirements in Annex I apply and how they are implemented. Article 13(4) puts the result in the Annex VII technical documentation. Everything below is an implementation of those four sentences.

Where draft prEN 40000-1-2 fits

The EN 40000 series is the first horizontal set of European standards written specifically for the CRA, developed by CEN and CENELEC in JTC 13 Working Group 9 under the Commission's standardisation request. Part 1-1 defines vocabulary. Part 1-2 describes the principles and processes of cyber resilience. Part 1-3 covers vulnerability handling, and further parts with generic and product-specific security requirements are in preparation.

Part 1-2 covers the risk assessment. It sets out four principles: a risk-based approach, security by design, secure by default, and transparency.

The standard defines a product risk management process built from six activities:

1. Establish the product context.
2. Define risk acceptance criteria.
3. Assess risks through asset and threat identification, risk estimation, and risk evaluation.
4. Treat identified risks.
5. Communicate risks to stakeholders.
6. Review risks throughout the support period.

It also describes secure development lifecycle activities that consume the assessment output. It maps these requirements to Annex I essential requirements. Following this process generates direct compliance evidence.

One caveat belongs up front. prEN 40000-1-2 is a draft in the CEN enquiry process. No standard in the EN 40000 series is yet cited in the Official Journal. None of them confers a presumption of conformity today.

Aligning with the draft standard remains practical. The process structure, terminology, and evidence trail are stable. A manufacturer running this process in 2026 prepares paperwork in the expected format well before the regulation takes full effect on 11 December 2027.

Classification frames the assessment

Every product record in CVD Portal starts with classification. A product is classified as default, important under Annex III (Class I or Class II), or critical under Annex IV.

The workspace stores a written justification for the classification. Classification controls the conformity assessment route under Article 32. It determines the level of scrutiny the assessment must pass.

Default products can self-assess under Module A. Important or critical products require harmonised standards, a notified body, or formal certification. The recorded justification is stored in the technical file for audit review.

Product context and risk acceptance criteria

The process begins with clause 6.2 for product context. Before identifying threats, the record collects functional use cases, user types, and market segment details. It captures architecture diagrams with every interface and existing product functions.

The workspace also creates a remote data processing dependency map. The CRA treats the product and its backend services as a single system. For every connected backend service, the workspace records the operator, data flows, authentication mechanisms, and fallback behavior.

This satisfies Article 13(3). The regulation requires analysis based on intended purpose, foreseeable use, operating conditions, and expected lifetime. The product context documents all four factors.

Clause 6.3 establishes acceptance criteria before measuring risk. The workspace derives risk acceptance criteria and assessment methodology from legal requirements and stakeholder expectations.

Deciding acceptable risk levels in advance ensures objective evaluation. A risk accepted against pre-agreed criteria withstands regulatory review far better than one accepted under release pressure.

Threats, scores and the applicability table

Clause 6.4 covers the core risk assessment in four steps:

1. Identify assets from the product context.
2. Identify threats per asset using STRIDE and CRA threat catalogues.
3. Estimate likelihood and impact on 5-point scales.
4. Calculate inherent and residual risk scores.

The outputs match the draft standard: a full risk register and an evaluated risk register with justifications for accepted risks.

Next, the workspace builds the CRA applicability table required by Article 13(3). The table covers Annex I Part I(2)(a) through (m). Each row is marked as applicable with implementation references, or not applicable with a risk-based justification.

Part I(1) and Part II apply universally. The workspace requires justifications for all excluded rows before generating the final table.

The mapping between the draft standard's process and the platform looks like this.

prEN 40000-1-2 process step	In the products workspace	CRA anchor
6.2 Product context	Use cases, users, architecture, interfaces, remote processing map	Art. 13(3) intended purpose and conditions of use
6.3 Risk acceptance criteria	Criteria and documented methodology from legal and stakeholder inputs	Art. 13(3) documented assessment
6.4 Risk assessment	Assets, STRIDE threats, 5x5 scoring, evaluated risk register	Art. 13(2) analysis of risks
6.4 output	Annex I Part I(2)(a) to (m) applicability table	Art. 13(3) and (4)
6.5 Risk treatment	Treatment decision with justification per risk	Annex I Part I controls
6.6 Risk communication	Stakeholder documentation and user-facing expectations	Annex II user information
6.7 Risk review	Review cadence plus recorded trigger events	Art. 13(3) kept up to date

Treatment, communication and review

The remaining clauses close the loop. Under clause 6.5, every evaluated risk receives a treatment decision with justification. This can be a design control, a mitigation plan, or an accepted residual risk.

Under clause 6.6, treatment information is documented for stakeholders. Relevant items flow directly into user instructions under Annex II. This keeps the risk assessment aligned with the documentation shipped to customers.

Clause 6.7 handles ongoing updates. Article 13(3) requires updates to the assessment during the support period. The workspace defines regular review schedules and monitors three types of trigger events:

• Changes in the threat landscape.
• Product vulnerabilities or security incidents.
• Changes in risk exposure such as new interfaces or markets.

Every trigger prompts a recorded review. This turns ongoing maintenance into documented audit evidence.

Artifacts, evidence grounding and self-review

The process produces specific compliance documents. The workspace tracks nearly ninety artifacts across risk management, secure development, and conformity documentation. This includes the EU Declaration of Conformity under Annex V and the Annex VII technical documentation index.

Artifacts divide into two categories. Deterministic documents, such as methodology and applicability tables, are generated directly from workspace records.

Other narrative artifacts are drafted using verified workspace data. Drafts remain grounded in evidence. Uploaded files must be confirmed by the user before drafting begins. The assistant cites source files and avoids inventing facts.

Drafts undergo automated gap analysis to check completeness. A human reviewer approves every artifact before inclusion in the Annex VII technical file.

The vulnerability handling side stays connected

A risk assessment must reflect field reality. CVD Portal connects vulnerability intake directly to product risk management. The intake portal, triage scoring, and Article 14 notification workflows feed live data into the workspace.

New vulnerability reports trigger assessment reviews under clause 6.7. This integration is explained in our guide on linking vulnerability reporting to product risk management. The vulnerability handling process maps to companion draft standard prEN 40000-1-3, detailed on our EN 40000-1-3 standard page.

Snapshots and the ten-year record

Article 13(4) requires manufacturers to retain technical documentation for at least ten years or the duration of the support period, whichever is longer. Authorities can request the specific assessment version covering any shipped unit.

The workspace creates immutable snapshots. When a product is placed on the market or substantially modified, the assessment state is frozen. This provides an exact historical record for auditors.

What this means for manufacturers

The regulation defines the required risk assessment outcomes. The draft standard provides the process to achieve them.

Implementing this process involves six key steps:

1. Establish product context and interfaces.
2. Set clear risk acceptance criteria.
3. Assess risks per asset with structured scoring.
4. Justify all Annex I applicability decisions.
5. Implement controls and document user instructions.
6. Review assessments on regular schedules and trigger events.

CVD Portal structures these steps and produces the required documentation for Article 13 and Annex VII. Aligning with the standard now ensures smooth transition when harmonised standards are published.