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 CRA 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 is the one that concerns the risk assessment. It sets out four principles, a risk-based approach, security by design, secure by default and transparency, and then describes a product risk management process built from six activities. Establish the product context, define risk acceptance criteria, assess the risks through asset identification, threat identification, risk estimation and risk evaluation, treat the risks, communicate them, and review them for as long as the product is supported. It also describes the secure development lifecycle activities that consume the assessment's output, and it maps its requirements to the Annex I essential requirements so that following the process produces evidence against the regulation.
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, so none of them confers a presumption of conformity today, and commentary on the series notes that the principles-level part may serve as a foundation for the requirement-level parts rather than as a conformity claim on its own. The reason to align with it now is practical. The process structure, the terminology and the evidence trail it asks for are stable enough to build on, and a manufacturer who runs this process in 2026 will meet the harmonised versions with the paperwork already in the right shape, well before the regulation applies in full on 11 December 2027.
Classification frames the assessment
Every product record in CRA Portal starts with a classification. The product is default, important under Annex III Class I or Class II, or critical under Annex IV, and the workspace stores a written justification alongside the class. Classification never appears in the assessment itself, but it controls the conformity route under Article 32 and therefore how much scrutiny the assessment must survive. A default product can self-assess under Module A. An important or critical product is heading toward harmonised standards applied in full, a notified body, or certification, which raises the bar for how defensible each judgement in the assessment needs to be. The recorded justification lands in the technical file, because the classification decision is the first thing a reviewer checks.
Product context and risk acceptance criteria
The draft standard's process begins with clause 6.2, the product context, and the workspace follows it. Before any threat is named, the product record collects the functional use cases, the user types, the market segment and comparable products as a state-of-the-art reference, the architecture or data flow diagram with every interface, and the product's existing functions. It also collects a remote data processing dependency map, because the CRA treats the product and any remote processing it relies on as one system, so each function that depends on a backend service records the operator, the data exchanged, the trust and authentication in place, and what happens when the connection degrades.
This is where Article 13(3)'s wording gets its content. The regulation requires the analysis to be based on the intended purpose and reasonably foreseeable use, the conditions of use, and the expected lifetime. The product context is the documented answer to all three, and every later judgement in the assessment traces back to it.
Clause 6.3 then fixes the yardstick before any risk is measured. From the legal requirements that apply to the product and the contractual and stakeholder expectations around it, the workspace derives the product's risk acceptance criteria and the documented assessment and treatment methodology. Both are recorded as artifacts in their own right. Deciding what counts as acceptable before scoring anything sounds like bureaucracy and is in fact the discipline that makes the later acceptance decisions defensible, because a risk accepted against pre-agreed criteria reads very differently in a review than a risk accepted because the release date had arrived.
Threats, scores and the applicability table
Clause 6.4 is the assessment proper, and the workspace runs it in the four steps the draft standard names. Assets are identified from the product context. Threats are identified per asset, with STRIDE applied systematically and seeded from a threat catalogue built for CRA product categories, so the boring threats get recorded along with the interesting ones. Each threat becomes a risk with an estimated likelihood on a five-step scale from rare to almost certain and an estimated impact from negligible to catastrophic. The product of the two scores bands the risk as low, medium, high or critical, and the workspace tracks the inherent score, the residual score after controls, and the reduction between them.
The outputs match the draft standard's list. A register of all identified risks with likelihood and impact estimates, and a register of evaluated risks with a justification wherever a risk is accepted.
Then comes the step that makes the exercise a CRA assessment rather than a generic one. Article 13(3) requires the assessment to state whether and how each product security requirement in Annex I Part I applies. The workspace generates an applicability table covering Part I(2)(a) through (m), and each row is either applicable with a reference to where the implementation is described, or not applicable with a written risk-based justification. Part I(1) and the whole of Part II are treated as always applicable, which reflects how the regulation is built. The generator refuses to produce the table while any not-applicable row is missing its justification, so a silent omission, the gap a market surveillance authority is trained to find, cannot make it into the file.
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 gets a treatment decision with a justification, whether that is a control implemented in the design, a planned mitigation, or a recorded acceptance against the criteria from 6.3. Under clause 6.6 the treatment information is documented for stakeholders, and the user-relevant slice flows into the user information the product ships with, which is how the assessment stays consistent with the Annex II sheet instead of drifting away from it.
Clause 6.7 handles the obligation that most teams underestimate. Article 13(3) requires the assessment to be updated as appropriate during the support period, and "as appropriate" needs a definition. The workspace records a determined review cadence and, alongside it, event triggers of three kinds. A change in the threat landscape, a cybersecurity issue such as an incident or a vulnerability report against the product, and a change in risk exposure such as a new interface or a new market. Each trigger prompts a review of the assessment, and each review is recorded, which turns "kept up to date" from an intention into evidence.
Artifacts, evidence grounding and self-review
Everything above produces documents, and the draft standard is specific about which ones. Each process step defines required inputs and outputs, and the workspace tracks nearly ninety of them across the risk management clauses, the secure development lifecycle activities from planning through decommissioning and third-party due diligence, and the conformity documents, the EU Declaration of Conformity under Annex V and the Annex VII technical documentation index.
The artifacts split into two kinds. Deterministic ones, the methodology, the applicability table, the conformity documents, are assembled directly from the workspace data with no generative step, because a document whose content is fully determined by recorded decisions should be produced mechanically. The remaining artifacts are drafted by the platform's assistant from the workspace state, and two safeguards keep the drafting grounded. First, drafts are anchored in the manufacturer's own evidence. Uploaded documents go through an analyse, review and confirm flow, and only confirmed documents feed the drafting, with the assistant instructed to cite the source file and to invent nothing beyond it. Second, each draft can be self-reviewed. A gap analysis scores the draft for completeness, lists what is missing, and revises the draft once if it scores poorly, with the score shown to the reviewer. A human accepts every artifact before it is recorded against the product for the Annex VII file, so the assistant drafts and the manufacturer decides.
The vulnerability handling side stays connected
A risk assessment that never hears from the field goes stale on schedule. CRA Portal's coordinated vulnerability disclosure side, the public intake portal, triage with suggested severity, CVSS vector and vulnerability type, and the Article 14 tracking for the 24-hour early warning, the 72-hour notification and the final report, feeds the product side directly. A report that reveals a threat the model missed is exactly the cybersecurity-issue trigger that clause 6.7 defines, so the disclosure programme becomes the live input that keeps the assessment current, a connection we covered in depth in linking vulnerability reporting to product risk management. The vulnerability handling process itself maps to the companion draft standard prEN 40000-1-3, and the platform documents that mapping clause by clause on the EN 40000-1-3 standard page.
Snapshots and the ten-year record
Article 13(4) gives the assessment a long tail. The technical documentation must be retained for ten years or the support period, whichever is longer, and for any unit an authority can ask which version of the assessment covered it. The workspace answers this with immutable snapshots. When a product is placed on the market, and again at any substantial modification, the full assessment state is frozen and kept, so the answer to "what did you know and decide when this unit shipped" is a retrievable record rather than an archaeology project through a wiki's edit history.
What this means for manufacturers
The regulation tells you what the risk assessment must achieve. The draft standard tells you what process produces it, and it is the process the harmonised standards will eventually formalise. Running it today means establishing the product context, fixing acceptance criteria, assessing risks per asset and threat with recorded estimates, deciding Annex I applicability with a justification for every exclusion, treating and communicating the risks, and reviewing the whole thing on a defined cadence with defined triggers. CRA Portal operationalises each of those steps and records the inputs and outputs the draft standard names, so the same work that manages your product's risk also assembles the evidence that Article 13 and Annex VII ask for. The standard will finish its journey to the Official Journal on its own schedule. The manufacturers who aligned their process with it early will be the ones for whom that event changes nothing.