CRA 2/5: The Backbone of the CRA: Why Nothing Works Without a Proper Cyber Risk Assessment

In the Cyber Resilience Act, the assessment of cybersecurity risk is not one chapter among many. It is the bracket that spans the entire regulation. It determines the depth and form in which the requirements from Annex I Part I (more on that in our third CRA article) have to be implemented for a specific product. Whether a requirement is applicable at all, by contrast, follows primarily from the product architecture, not from the risk assessment itself. And it is the precondition for a manufacturer to be able to justify, toward market surveillance authorities, why it took certain measures and considered others unnecessary. As simple as the legal text sounds, the three verbs “designed, developed, and manufactured” mark three phases, each with its own requirements.

This article concentrates on the first of them, the design phase, and it begins with the identification of risks. Beyond that, it explains the methodology from the ground up: terms, procedure, tools, typical mistakes.

And it sets out why security by design is not an option that can be retrofitted later.

All CRA cybersecurity risk assessment terms explained

A risk assessment is only as good as the shared language of the team that produces it. That comes down not only to role but also to background: automotive, aviation, and classic software development each speak their own language, and even product security and IT security sometimes use different terms for the same facts.

The following terms are the basic building blocks of every CRA-compliant risk assessment:

• BSI TR-03183 (section 5.8.1.1.1) treats assets as everything worth protecting on the PwDE: the product itself, its components and functions, and all data it collects, stores, or otherwise processes. What matters here is the accompanying limitation: the asset list should contain nothing outside the PwDE, because the product cannot directly protect it, and every relevant external value has a corresponding asset inside the product anyway. This boundary is often disregarded in practice. The point is not every conceivable value the product somehow influences, but what the product itself contains, processes, or controls, and can therefore protect.

TR-03183 distinguishes three asset types that have proven to be a workable structure for most products:

• Data assets are all data the product generates, stores, transmits, or processes, from personal data (PII) through configuration data to telemetry without any personal reference. For each data type, TR-03183 provides ready-made C/I/A baseline values (scale 1 to 5) as a starting point for the impact assessment.
• Functional assets are the core functions, meaning what the product was built for. A router has the routing function; a password manager has the secure storage and retrieval of access credentials. Functional assets are primarily relevant in the availability dimension.
• Security assets are mechanisms and data that protect other assets: keys, certificates, credentials, cryptographic mechanisms, authentication functions. Their impact derives from that of the protected assets. A key that secures the confidentiality of health data (impact confidentiality: 4) carries the same confidentiality impact as the health data itself.

Pros may keep scrolling: the CIA model explained quickly, three protection dimensions per asset

Every asset is assessed along three axes:

• Confidentiality: may the asset be accessible only to authorized parties? A loss means unauthorized access to data or functions, through data leaks, intercepted communication, or compromised credentials.
• Integrity: may the asset be changed only when authorized? A loss means unauthorized manipulation of data, configurations, or firmware, through tampering, man-in-the-middle attacks, or compromised update channels.
• Availability: must the asset remain reliably usable? A loss means that functions or data are no longer accessible, through denial-of-service attacks, ransomware, or attack-induced hardware failures.

The point often overlooked in practice: a single asset can require protection in all three dimensions at once. And each dimension may call for its own, different protective measures.

Take user credentials in a connected device:

• Confidentiality: stored passwords must not be read out

→ encryption of credential storage, protection against memory read-out

• Integrity: the password must not be altered without authorization

→ access controls on credential management, audit logging of changes

• Availability: the login mechanism must keep working even under load or attack

→ rate limiting against brute force, resilience against DoS on the authentication endpoint

A single mechanism, say strong encryption alone, addresses only confidentiality. Security by design means systematically thinking through all three dimensions for every asset and backing them with suitable measures.

In practice, the CIA triad is often extended by a fourth dimension: authenticity, the certainty about the genuineness of a data source or a communication partner. Precisely when cryptographic keys are exchanged, it is decisive that the sender’s identity can be trusted; depending on the use case, non-repudiation (the provability that an action really originated from a specific actor) is added. The CRA text does not carry authenticity as a separate category, but addresses it through the requirements on integrity and access protection. In methodological frameworks, by contrast, it is usually listed explicitly as its own protection dimension.

What are threat, risk, and incident in the Cyber Resilience Act? Three terms, three functions

The CRA risk assessment works with three core terms defined in the legal text (see Art. 3) that have to be kept methodically separate.

A brief aside: engaging with these cybersecurity fundamentals is long since more than compliance. Cybersecurity is evolving from a downstream cost factor into a product feature. Whoever masters it gains an advantage that reaches well beyond meeting minimum regulatory requirements.

So, explained once:

• A threat, under Art. 3(46) (in conjunction with Art. 2(8) of Regulation (EU) 2019/881), is any potential situation, event, or action that could damage, disrupt, or otherwise adversely affect a network and information system, its users, or other persons. It describes the potential for a negative outcome, without any statement about probability or magnitude. It is the starting point of the analysis, not its result. This legal definition comes from the Cybersecurity Act and is aimed at network and information systems. In the CRA context, it is to be read against the product: the threat is directed at the PwDE, its components, functions, and data. Closer to the product is ISO/SAE 21434, which (strictly speaking, for the threat scenario) describes the potential cause of the compromise of cybersecurity properties of one or more assets. This is exactly the asset-centric way of thinking that holds up in the product context.
• A risk, under Art. 3(37), is the potential for loss or disruption caused by a security incident, expressed as a combination of the magnitude of the loss and the probability of occurrence. Risk is thus the product of impact and likelihood, and it is precisely this combination that decides whether it has to be treated or can be accepted.
• An incident, under Art. 3(43), is an event that has actually occurred with a negative effect on the security of network and information systems. The incident is the trigger of the CRA reporting obligations from Article 14, meaning the realization of a risk, not the risk itself.

The distinction has operational consequences: a known vulnerability in a component in use is initially a threat. Whether and how urgently it has to be treated follows from the risk assessment (impact × likelihood). If it is actively exploited, it becomes an incident, and triggers the CRA reporting obligation under Art. 14(1) (introduced in our first CRA article).

The three terms also lie apart in time: threats and risks are considered prospectively, beginning during development and continuing across the entire lifecycle. An incident, by contrast, is only spoken of once a risk materializes on the delivered product in the field, and it is precisely this transition into the field that triggers the reporting obligation.

STRIDE: structured threat identification

For the systematic identification of threats, a structured model is advisable. The most widespread in practice is STRIDE, originally developed by Microsoft and today a standard of threat modeling:

• Spoofing (identity spoofing): an attacker poses as a legitimate user, system, or service
• Tampering (manipulation): unauthorized alteration of data, code, or configuration
• Repudiation (deniability): an actor can dispute an action because sufficient audit logs are missing
• Information Disclosure (data leak): access to data not intended for the attacker
• Denial of Service (availability attack): impairment or failure of functions through overload or targeted sabotage
• Elevation of Privilege (privilege escalation): an attacker obtains higher permissions than they are entitled to

STRIDE gives development teams a fast, complete checklist: for every component and every interface, the team works through which of the six attack classes is relevant. It is no substitute for a deep threat analysis, but an effective starting point that keeps a fundamental threat class from being overlooked.

The bridge to the CIA triad follows almost by itself: spoofing and information disclosure primarily hit confidentiality; tampering and repudiation hit integrity; denial of service hits availability; elevation of privilege can affect all three dimensions, because extended permissions are what make the exploitation of all remaining vulnerabilities possible in the first place. The value of the STRIDE model lies exactly here: it thinks from the attack inward and thereby systematically reveals which paths can be used to violate which CIA property.

Enter DIN EN 40000: the coming family of standards, and why it already counts now

Anyone implementing the CRA risk assessment in practice will, in the medium term, come up against the EN 40000 family of standards, the first horizontal European set of standards emerging directly under the CRA standardization request M/606 from CEN/CENELEC.

Two parts are especially relevant for the risk assessment:

• EN 40000-1-2 defines the overarching risk management principles and lifecycle activities. This is the methodological core, conceptually identical to what this article describes.
• TR 40000-1-5 is a supplementary technical report on threats and security objectives for the risk assessment, a support document for the practical application of EN 40000-1-2. Unlike the other parts, it is a Technical Report, not a normative standard: it establishes no presumption of conformity and, as things currently stand, exists only as a draft, without a published version.

Once EN 40000-1-2 is referenced in the EU Official Journal, applying it establishes a presumption of conformity under Art. 27. That sounds complicated but ultimately means only this: whoever applies the standard no longer has to prove separately that their risk assessment meets the CRA requirements; it is presumed.

All parts of the EN 40000 series are still drafts, but at different stages: 1-1 through 1-3 already exist as commentable drafts (having passed public enquiry), while 1-4 and the TR 1-5 are at an earlier point. None has yet been referenced in the EU Official Journal, and thus none is yet effective for the presumption of conformity.

Until finalization, the BSI TR-03183: Cyber Resilience Requirements for Manufacturers and Products, published by the BSI, is the most pragmatic working basis, and the substantive distance between the two is small enough that a later switch does not mean reinventing anything.

So, onward, with the goal in mind:

Understanding the fundamentals of the CRA cybersecurity risk assessment

Let us start with the simple question: what is even supposed to be assessed? Or, put more formally: the object of assessment has to be defined.

Before the assessment begins, it has to be settled what is being assessed at all. Even seasoned teams stumble at this more often than one would assume, simply because developers, product managers, and security officers define fundamentally differently what “the product” even is.

The starting point is a context diagram that shows the product as a black box in its environment. It answers the central question of the entire risk assessment: what belongs to the object of assessment, and what does not? These boundaries are called item boundaries.

The rule here: all data-capable interfaces are captured, physical as well as logical, whether used or not. With bought-in COTS components in particular, debug ports, unused radio interfaces, or services open by default are easily overlooked, and thus become an unrecognized attack surface.

For clarity, here are concrete boundary decisions that generally have to be made explicitly:

• Does the manufacturer’s OTA update server belong to the PwDE? That depends on the modeling, and is not conclusively settled in regulatory terms. What does mandatorily belong to the PwDE is the update interface in the product itself: the mechanism that fetches updates, transmits them via TLS, checks signatures, and prevents rollbacks (Annex I Part I, integrity). The server behind it can cleanly be treated as an external endpoint beyond the product boundary. Its security is then captured not through the product scope but through the obligation to secure update distribution mechanisms (Annex I Part II No. 7) and, where applicable, NIS2. The server only becomes a full RDPS, and thus part of the product boundary, once it carries an operational core function beyond mere update delivery (for example device management or functionally necessary remote processing) without which the product does not work.
• Does the web interface for product configuration belong to it? If developed by the manufacturer and necessary for configuration, yes.
• Does the network infrastructure over which the product communicates belong to it? No. It lies outside the manufacturer’s responsibility and thus outside the item boundaries.
• Do third-party apps that users install themselves belong to it? The app code itself never. But it depends on where it runs: on a foreign device (a phone) → only the communication interface is in scope; on the product itself → the product is the execution platform, and sandboxing, isolation, permission model, and local APIs belong fully in the assessment. What is owned is not the app, but the isolation around it.

What matters: there is no general right or wrong here in the item definition.

But the decisions have to be made, documented, and applied consistently. A market surveillance authority reviewing the technical documentation expects traceable justifications at this point too, not implicit assumptions.

On the basis of the context diagram, the product architecture is described: which components does the product contain, over which interfaces do they communicate internally and externally, which communication relationships exist with RDPS components? A functional diagram adds the core functions and their dependencies. This does not require every implementation detail, but enough to identify attack paths.

At least as important is the description of the operating environment: in what context and under what conditions does the product run? An industrial controller in a sealed-off OT environment without an internet connection, operated by trained personnel, has a fundamentally different risk profile than the same hardware in a consumer home network, connected to a Wi-Fi router and operated by a layperson. These environmental parameters feed directly into the likelihood assessment.

What the CRA envisions about how a product is used: intended purpose, reasonably foreseeable use, and misuse

The CRA recognizes three usage scenarios with different implications for the assessment.

• The intended purpose is the use foreseen by the manufacturer, defined by the instructions for use, marketing material, technical documentation, and manufacturer declarations (see Art. 3(23)). The assessment has to cover all risks that arise under intended
• The reasonably foreseeable use does not necessarily match the intended purpose, but likely results from foreseeable human behavior or technical processes (see Art. 3(24)). Example: an industrial device intended for a secured OT environment is accidentally connected to the corporate network. Not the intended purpose, but foreseeable, and the manufacturer has to account for the associated risks.
• The reasonably foreseeable misuse does not match the intended purpose and can result from foreseeable behavior or interactions with other systems (see Art. 3(25)). The decisive difference: foreseeable misuse has to be documented by the manufacturer in the user documentation, but the manufacturer is not obliged to secure the product against intentional abuse. Jailbreaking, deliberate deactivation of security functions, or the use of a consumer device in a military environment do not fall within its responsibility.

For practice, this means: the risk analysis has to cover intended purpose and reasonably foreseeable use; reasonably foreseeable misuse is to be documented, but not fully mitigated.

We keep preaching it: the cyber risk assessment is not a one-off

A widespread, and false, idea is that the assessment is produced once before placing on the market and then filed away.

The CRA makes the opposite explicit.

Art. 13(3) obliges manufacturers to document and, where relevant, update the risk assessment.

“Where relevant” means in practice:

• with every product-relevant change,
• with newly known vulnerabilities,
• with a changed threat situation.

Art. 13(8) links this to the support period: the assessment runs across the entire support period, meaning at least five years.

What that can mean concretely for the cybersecurity risk assessment:

• A new CVE in an open-source library in use

→ update the assessment for the affected component, evaluate the effects on the overall product

• A firmware update with new functions

→ extend the assessment for the new functions and their interfaces

• A new attack method relevant to the product category

→ update the threat catalog, reassess the affected risk scenarios

The risk assessment is thus not a project artifact but a living document that maps the security situation across the entire product life.

End of software support vs. decommissioning: an often overlooked cyber risk moment

The support period (see Art. 13(8)) is measured by the product’s expected use time and is at least five years: less if the expected use is shorter, more if the expected use is longer. The five years are therefore a lower bound, not a default value.

Devices often keep running for years or decades without security updates, from the smartphone whose operating system drops out of support to industrial and medical technology with even longer lifecycles.

Possibly convenient for the user. But from a cybersecurity standpoint, it is usually critical: from the end of support, known vulnerabilities remain permanently unpatched. The product thereby becomes a static attack surface. It then endangers not only its operator but potentially all systems and networks it is connected to.

The CRA addresses this on two levels:

1. Manufacturers have to inform users in good time about the end of support (see Art. 13(19))
2. and, where technically possible, enable a secure deletion of all user data (see Annex I Part I(m)). A minimum requirement, not a complete solution.

For the risk assessment, it follows that the entire product lifecycle, including the planned end of support and foreseeable continued operation afterward, belongs in the risk considerations from the start.

Anyone bringing a product to market with an expected life of ten years and a support period of five years should account for the risks of the last five years without updates already in the product concept, and communicate transparently which risks users bear themselves after the end of support.

Practical procedure in the CRA cyber risk assessment: step by step

We have already met BSI TR-03183. And also the EN 40000 series, which correctly is still called prEN 40000 for now (from the French projet de norme européenne, the official status marker for draft status).

So, for the cyber risk assessment under the CRA, the important question comes first:

TR-03183 vs. prEN 40000-1-2 or ISO/SAE 21434: which methodology as the basis for the CRA risk assessment?

Before the start comes the question of method. The CRA is expressly and deliberately method-neutral with respect to the cybersecurity risk assessment.

That is, it prescribes no specific approach, as long as asset identification, threat analysis, and risk acceptance are documented in a traceable way.

At the present time, two reference documents appear decisive for this:

• BSI TR-03183 (v1.0.0, as of July 2026) is the pragmatic entry point: developed by the BSI, oriented toward ISO 31000, with concrete asset catalogs including ready-made C/I/A baseline values, defined likelihood indicators, and a fully worked practical example (a network camera). It establishes no presumption of conformity, but is today the most accessible and most fully elaborated tool.
• prEN 40000-1-2 is the emerging European horizontal standard under M/606. Conceptually it is identical to TR-03183: both follow ISO 31000, both structure into identification, analysis, evaluation, and treatment. The difference lies in the normative precision: EN 40000-1-2 defines input and output requirements per lifecycle activity and offers an explicit mapping to Annex I. Once referenced in the Official Journal, applying it establishes a presumption of conformity under Art. 27. The distance to TR-03183 is small. Whoever works with it today does not start from scratch at the later transition.

For the thousands of manufacturers that produce for the automotive industry and vehicle development and already work with TARA under ISO/SAE 21434: the methodology is conceptually transferable and accepted by the CRA. The differences lie in the focus (TARA targets vehicle systems) and in the granularity of the attack potential rating (ISO/SAE 21434 is considerably finer than the TR-03183 indicators). Whoever has mastered TARA is well positioned for the CRA: safety, operational, and privacy are already assessed by TARA through its SFOP impact scheme, and financial is covered as well. What has to be added, at its core, is only the systemic and societal (“public interest”) dimension. That is, the effect on other devices, networks, and essential entities, a dimension that is less prominent in the classic automotive business (with its focus on damage to the vehicle and its users and surroundings).

The cyber risk assessment process as the CRA requires it, in overview

The process follows an iterative four-step model that underlies TR-03183 and EN 40000-1-2 alike.

1. Step 1: Risk identification, identify assets and threats. First, all assets are identified and categorized (data, functional, security assets), as discussed above. Then, for each asset, the relevant threats are identified, structured via STRIDE or a comparable approach. The result is a list of risk scenarios: combinations of asset, threat class, and affected environmental context.
2. Step 2: Risk analysis, assess likelihood and impact. For each scenario, potential impact and likelihood are assessed. The impact follows from the C/I/A values of the affected assets. TR-03183 provides baseline values (scale 1 to 5) for defined asset types: a leak of generic personal data (PII.Generic) has a confidentiality baseline of 3, a leak of health data (PII.Important) one of 4. Amplifiers can raise these values, for instance with very many affected records or long-lasting damage. TR-03183 approximates the likelihood via three environmental indicators: interface restriction (from physical through local and known network to external network), access restriction (from restricted to non-restricted), and user capability (from skilled through instructed to layman). From this comes an environmental indicator that maps the protective effect of the operating environment. Example: a product accessible only physically and operated by trained staff has a fundamentally different risk situation than a consumer product with internet access.
3. Step 3: Risk evaluation, decide on acceptance. For each analyzed risk, a decision is made: acceptable or in need of treatment? TR-03183 provides qualitative acceptance criteria: risks with moderate or higher impact under network access by unknown actors are generally not acceptable; likewise risks with moderate or higher impact under misconfiguration by layperson users. These criteria are a starting point, not a fixed requirement. They are meant to be adapted to the specific product context. (This is why a conscientious cyber risk assessment, despite AI and software solutions, still requires expertise, domain knowledge, and experience.)
4. Step 4: Risk treatment, select and implement measures. Risks that are not accepted have to be treated. The CRA prescribes no specific measures. Measures are derived consistently from the risk assessment, not chosen by gut feeling. Otherwise, high costs quickly arise that are invested past the actual risk. The essential requirements from Annex I Part I set the frame within which the manufacturer selects controls. (More on that in the third article of this series.) TR-03183 works with Adaptable Risk-Based Controls (ARC): every security measure is tied to a risk scenario and applies only if the product actually operates in that scenario. An automatic update mechanism as standard, for instance, is required only if the product processes assets with moderate or higher impact over an external network and is operated by layperson users. Risks the manufacturer cannot bear alone can be shared: with suppliers via compliance requirements or contractual clauses, with users via transparent communication and documentation of the residual risks (provided these lie within the scope of reasonably foreseeable user expectation).

The common CRA practical example: the network camera “Simple Network Camera (SNC) X5 – Everyday Made Easy”

Under Annex C, BSI TR-03183 contains a fully worked example for the risk assessment of a PwDE, a simple consumer network camera:

• The product captures video and audio data,
• stores them on an SD card,
• and streams them over a Wi-Fi home network.
• It has no manufacturer backend connection: no RDPS, no cloud service.

The asset identification yields, among others:

• video and audio data (PII.Generic, C:3/I:2/A:3),
• Wi-Fi access credentials (Security.Secrets.NetworkCredentials, C:4/I:3/A:3),
• configuration data (Other.Configuration, C:1/I:3/A:1),
• and the essential streaming function (Functions.Essential, A:3).

The operating environment is clear: layperson users, restricted home area (restricted), known network (home network with shared devices). The resulting environment indicator flags network risks as real: the home network is not an isolated, dedicated network but shared and potentially populated with other compromised devices.

The risk evaluation shows: risks to assets with moderate or higher impact over the home network, meaning video/audio data and Wi-Fi credentials, are not acceptable. From this follow concrete controls that become required: TLS encryption for the web interface and the streaming protocol, strong authentication without default passwords, protected storage for Wi-Fi credentials with exclusive read access for the Wi-Fi service.

The example shows the methodology in miniature. The transfer to more complex products can follow the same steps. Only with more assets, more interfaces, and more risk scenarios.

Common mistakes in the CRA risk assessment for products with digital elements

Since the assessment of cyber risks (for example in automotive and vehicle development projects) has been standard for many years already, recurring patterns and potential error sources can be derived from it, and from the first CRA-specific implementations:

1. Mistake 1: solutions before risks. Teams discuss concrete measures before risk and risk cause are understood. The result is technically correct but misses the actual problem. The question “do we need a firewall?” must not be raised before “which assets do we have to protect against which threats?” is answered. The consequence is not only protection gaps but also high costs for measures that were not needed at all from a security standpoint.
2. Mistake 2: complexity instead of conservatism. An overly granular, in-depth assessment of individual attack scenarios loses the big picture and turns the risk assessment into a months-long project. TR-03183 expressly recommends a conservative, general approach as the starting point. Better to overestimate a risk and implement an unnecessary measure than to underestimate a risk and leave a critical vulnerability open. Experience from automotive development work shows that very elaborate, deeply detailed TARAs all too often lead to the same measures as a lean, conservative assessment. The additional depth then costs mainly time, without changing the result.
3. Mistake 3: poor asset choice. Too many assets (every data point individually), too few (only “the data” as a category), or wrongly delimited ones (assets outside the product that cannot be directly protected) render the entire subsequent threat analysis useless. Assets need neither map the whole system architecture nor be arbitrarily abstract. They have to describe the units worth protecting at a level of granularity at which meaningful protective measures can be defined. Double-counting is also common: carrying the same element as both a data asset and an interface. Cleaner: the signal is the asset, the interface is the attack vector. Duplicate listing inflates the assessment and, with the complexity, raises the risk of error.
4. Mistake 4: impact assessment without a business perspective. The damage is assessed technically (data leak = impact 3) but not mirrored against the actual significance for the company. Can the company survive a reputational hit of this size? Does the incident draw regulatory consequences, such as GDPR fines on top of the CRA? The impact criteria have to be calibrated with business realities from the start, not just with abstract damage classes. In practice, this calibration does not belong to the security function alone: the cybersecurity engineer assesses the technical damage level but often has no insight into reputational, contractual, and regulatory consequences, or the comparison to other company risks. Legal, data protection, and product/risk ownership should therefore share in the impact classification.

The underestimated connection between organizational security measures and product security

Not every relevant protective measure is technical in nature. Organizational measures already implemented can directly influence the likelihood assessment in a positive way, because they restrict attack paths or make their exploitation harder. Among them:

• Cybersecurity awareness training lowers the probability of successful phishing attacks, which can lead to the unintended outflow of keys, credentials, or source code
• Access management for development systems, build infrastructure, and production data limits which systems and data are reachable in the event of a compromise, and lowers the possible damage effect
• Classification and labeling of sensitive data enables targeted, risk-based protection instead of blanket protection of all data equally

In the process, this means: whoever demonstrably operates and documents such measures can set the probability of occurrence of certain scenarios lower on justified grounds.

“Demonstrably” is the key term. An awareness training carried out once three years ago does not lower the likelihood durably. Regularly conducted, documented measures, by contrast, are a legitimate factor.

We also recommend our follow-up article on this: Why the Cybersecurity Concept (ISO/SAE 21434) Cannot Be Limited to the Vehicle Alone: Considerations for Cybersecurity Managers

Advantages of re-use and impact analysis in the CRA risk assessment: scalability through modularity

A full assessment from the ground up for each individual product is neither scalable nor necessary.

In practice, a modular approach is advisable. Shared components, platforms, or architectures (a reused communication layer, a shared RDPS backend, a common authentication component) are assessed once and used as a baseline for all products built on them. The assessment of this base component does not have to be repeated per product, only referenced and checked for currency.

For new product variants or follow-up versions, a targeted impact analysis then suffices: what has changed? Which new assets or interfaces are added? Which existing assessments are affected? Is the likelihood of known attacks still plausible at today’s state of technology?

That is considerably less effort than a fresh assessment, and it keeps the assessment current at the same time.

Important with re-use: market surveillance authorities expect traceability, not copy-paste documentation without justification. Whoever takes over parts of an existing assessment has to document which parts were taken over on what basis and why they remain valid for the new product.

When do I do the CRA risk assessment? Why the risk assessment has to run along from the start

The CRA deliberately uses three verbs: products have to be designed, developed, and manufactured so that they ensure an appropriate level of cybersecurity (Annex I Part I No. 1). They describe three phases of the product creation process in which cybersecurity has to be actively considered: not after development, not as the last step before release, but in design, development, and manufacturing.

The reason lies in an often underestimated dependency: many technical cybersecurity measures presuppose hardware or system prerequisites that cannot be retrofitted later.

Secure boot is the classic example: accepting only cryptographically signed firmware at startup cannot be effectively implemented without a trusted hardware base, such as a Hardware Security Module (HSM) or a Trusted Platform Module (TPM). Whoever wants to implement secure boot but has not provided for an HSM faces a hardware revision that is expensive or practically impossible in production.

Second example: the cryptographic signature check when flashing software achieves nothing if internal access to the firmware files is not controlled. Can arbitrary employees access the build pipeline without logging and an authorization process? Then the signature check at the end user is ineffective, because the attacker starts earlier.

This dependency between product security and internal infrastructure security is a typical blind spot that can only be addressed in the early design phase.

Whoever recognizes these dependencies only after the fact faces a binary choice: expensive hardware revisions or ineffective security measures on an unsuitable base. Both are avoidable if risk assessment and architecture decisions are thought through together from the start.

CRA risk assessment and the question: what about products already on the market?

For most manufacturers, the case is this: their CRA-obligated products have long been developed and sold. Security by design from the first design phase is no option for them, but rather a retroactive requirement on architecture decisions already made.

This is one of the greatest practical challenges of the CRA, and it would be dishonest to claim a simple solution.

But there is a pragmatic path: not a restart, but a structured gap analysis on the basis of a retroactive risk assessment. It looks like this:

1. Carry out a risk assessment for the existing product: what are the most critical assets, what are the most probable and most consequential threats?
2. Identify which risks can still be mitigated with justifiable effort: software updates can close known vulnerabilities, configuration changes can reduce the attack surface, organizational measures can lower the likelihood.
3. Identify which risks cannot be fully mitigated due to hardware limitations, and document these as justified residual risks and communicate them transparently to users.

Not every hardware gap can be closed on the software side. That is acceptable, provided the decision is documented, justified, and traceable.

An honest, documented risk assessment with justified acceptance decisions is more defensible in regulatory terms than no documentation at all.

For existing products, an important exception applies: products placed on the market before December 11, 2027, are subject to the full CRA requirements only if they are substantially modified after that date (see Art. 69(2)).

That creates room to maneuver, but no free pass.

The CRA reporting obligations under Art. 14 already apply from September 2026 for all products in scope (as described in the first article of this series), regardless of the point of placing on the market.

And a risk assessment is the precondition for being able to judge at all whether a security event is reportable.