Product Security

Cybersecurity Risk Assessments & The EU CRA

How to run a CRA-ready cybersecurity risk assessment. The mandatory requirements, a step-by-step process, the tools, and how to keep it defensible across your product's life.

Doc McConnell

Doc McConnell

Head of Policy and Compliance

January 24, 2026
TL;DR A Cyber Resilience Act risk assessment is the analysis manufacturers must run to find and fix cybersecurity risks in a connected product before it ships. The CRA makes it mandatory, ties it to how your product is actually used, and requires you to document it and keep it current. Done right, it isn't a one-time form. It's a living analysis grounded in what you actually ship.

The EU Cyber Resilience Act raised the stakes for connected device manufacturers. It sets binding cybersecurity requirements for products with digital elements, and the risk assessment is where compliance starts. Get the assessment right and the rest of your EU Cyber Resilience Act work has a foundation. Get it wrong and everything downstream inherits the gap.

Most guides on this topic hand you a generic three-step checklist and call it done. The CRA doesn't work that way. The regulation ties the assessment to your product's intended use, runs it across the whole lifecycle, and expects you to keep it current. A risk assessment copied from a template and filed away isn't compliance. It's a liability waiting for an audit.

This guide covers what the CRA actually requires, how to run the assessment step by step, which tools help, and how to keep it defensible over time.

What is a cybersecurity risk assessment under the CRA?

A Cyber Resilience Act risk assessment is a structured review of the security risks in a connected product across its lifecycle, used to decide which protections you build and how you prove them.

It does two jobs. First, it identifies the vulnerabilities and threats an attacker could exploit. Second, it drives the mitigations that reduce that risk before the product ships and throughout its supported life. The assessment isn't a side document. Under the CRA, it informs how you design, develop, and maintain the product, which means it shapes the engineering work rather than describing it after the fact.

The shift here is real. A risk assessment shouldn't be a last-mile scramble before launch. It should be a continuous analysis, grounded in what you actually ship, that produces evidence as a byproduct of building the product well.

Does the EU Cyber Resilience Act require a risk assessment?

Yes. The CRA makes a cybersecurity risk assessment mandatory for every product with digital elements, and you must document it inside the technical documentation you keep for authorities.

This isn't optional or best-practice guidance. Article 13 of the regulation requires manufacturers to perform the assessment before placing a product on the market, and Annex VII requires it to live in the technical documentation that market surveillance authorities can request [verify before publishing]. If your product connects to a network or another device, the obligation applies. No documented risk assessment, no defensible path to the CE marking.

What are the mandatory risk assessment requirements for manufacturers under the EU Cyber Resilience Act?

The CRA requires a documented risk assessment scoped to your product's intended use, covering its full lifecycle, mapped to the essential requirements, and kept current throughout the support period.

The regulation is specific about what the assessment has to do. It isn't enough to list a few generic threats. The assessment has to be based on how the product is actually used and maintained, and it has to connect directly to the essential cybersecurity requirements in Annex I. Here's the summary manufacturers can work from.

RequirementWhat it means in practiceCRA reference
Perform a risk assessmentAnalyze cybersecurity risks based on the product's intended purpose, reasonably foreseeable use, and operating environmentArticle 13(3)
Cover the full lifecycleFactor the assessment into planning, design, development, production, delivery, and maintenanceArticle 13
Map to essential requirementsShow whether and how the Annex I security requirements apply, and how you implemented themArticle 13(3), Annex I
Address vulnerability handlingShow how you handle vulnerabilities across the support periodAnnex I, Part II
Exercise supply-chain due diligenceEnsure third-party and open source components don't compromise the product's securityArticle 13
Document itInclude the risk assessment in the technical documentation, available to authoritiesArticle 13(4), Annex VII
Keep it currentUpdate the assessment through the product's support period as risks changeArticle 13

The thread running through every row: the assessment is tied to your product and your lifecycle. A defensible CRA risk assessment can't be generic, because the regulation asks how the requirements apply to this specific product in its real operating conditions.

How do you conduct a CRA risk assessment, step by step?

Run a CRA risk assessment in five steps: inventory your components, identify threats, analyze weaknesses, plan mitigations, then document everything as evidence and keep it current.

The process is straightforward once you treat each step as producing a piece of evidence, not just an activity. Here's the sequence and what each step should leave behind.

StepWhat you doWhat it produces
1. InventoryCatalog every digital component: hardware, firmware, software, and third-party and open source dependenciesA ground-truth software inventory / SBOM
2. Identify threatsMap the threats that target those components in the product's intended useA threat list scoped to the product
3. Analyze weaknessesExamine code, architecture, and supply chain for exploitable gapsPrioritized vulnerability findings
4. Plan mitigationsBuild a fix or control for each real riskA mitigation plan mapped to findings
5. Document and maintainFile the assessment in your technical documentation and update it over timeAudit-ready, current evidence

A bit more detail on the middle steps, since that's where assessments usually go thin.

Identifying threats. Start with the attacks most connected products face: unauthorized access through weak passwords, data breaches through insecure storage, and denial-of-service through unprotected endpoints. Scope the list to how your product is actually deployed.

Analyzing weaknesses. Look in three places. In the code, for insecure coding practices and outdated libraries. In the architecture, for gaps in the security design. In the supply chain, for risky third-party and open source components. Common IoT weak points include outdated encryption protocols, hardcoded credentials, and insecure firmware updates. This is where a ground-truth software inventory earns its place, because you can't analyze a component you didn't know you shipped.

Planning mitigations. For every real risk, build a concrete fix: encryption upgrades to protect data in transit, regular security updates to patch vulnerabilities, and access controls to restrict unauthorized entry. Tie each mitigation back to the finding it addresses so the documentation tells a clean story.

What tools and resources help with CRA risk assessments?

Use automated binary and SBOM analysis, penetration testing, and recognized compliance frameworks to find real vulnerabilities, prioritize them by exploitability, and produce audit-ready evidence.

The right tools turn a manual slog into a repeatable process. Three categories do most of the work.

Automated analysis. Tools that analyze firmware and binaries, not just source code, detect known vulnerabilities and build the component inventory the assessment depends on. The hard part isn't finding vulnerabilities, it's finding the ones that matter. Reachability analysis cuts the noise by focusing on the vulnerabilities that are actually exploitable in your product, so your team works on real exposure instead of a wall of theoretical findings.

Penetration testing. Binary-level penetration testing simulates real attacks on what you actually shipped, validating whether the weaknesses you found are exploitable and whether your defenses hold.

Compliance frameworks. Use guidance from recognized bodies like the EU Agency for Cybersecurity (ENISA) to confirm you've covered the regulatory requirements. When it's time to assemble everything into a submission, our guide to the CRA's SBOM and technical documentation requirements walks through what authorities expect to see.

How often do you need to update a CRA risk assessment?

A CRA risk assessment isn't one-and-done. You update it as threats change, new vulnerabilities emerge, or new product versions ship, across the product's whole support period.

The CRA treats security as a continuous obligation, not a launch gate. That means the work doesn't stop when the product ships. Manufacturers have to keep monitoring products for emerging vulnerabilities, refresh the assessment when threats evolve or versions change, and track regulatory updates so the process adapts. A risk assessment that's accurate at launch and stale six months later isn't defensible.

What separates a defensible CRA risk assessment from a checklist?

A defensible CRA risk assessment is grounded in what you actually shipped and scoped to real, reachable risk, not a generic checklist copied across every product in your portfolio.

This is the difference that holds up under audit. A checklist tells an assessor you went through the motions. An assessment built on an accurate inventory, prioritized by exploitability, and tied to your product's real operating conditions tells them you understand and control your risk. The first is a formality. The second is proof. Build the second, and CRA compliance stops being a scramble and starts being a report you can generate on demand.

Conclusion

A Cyber Resilience Act risk assessment is the foundation of CRA compliance, and the manufacturers who do it well treat it as continuous, not one-time. Inventory what you ship. Find the risks that are real. Mitigate, document, and keep it current.

Do that, and you don't just satisfy a regulation. You strengthen your security posture and ship safer, more reliable products. In a connected market, that's what earns trust.

Ready to build a risk assessment process that holds up? Talk to our experts for tailored guidance and a clear path to audit-ready evidence.

Doc McConnell

Doc McConnell

Head of Policy and Compliance

Hannah is Content Marketing Manager at Finite State, where she brings her SaaS startup experience to drive SEO-focused content across blogs, web, email, and social. With a background in copywriting and design, she blends creativity with strategy to grow organic reach and brand engagement.

Ready to Level Up Your Security Knowledge?

Join thousands of security professionals learning from the best in the industry

Start Learning TodayStart Learning Today
Finite StateFinite State

Finite State is the Product Security Automation Platform that functions as an autonomous Product Security OS: design → verify → prove, grounded in what you ship.

Platform

Platform Overview
Ground Truth Inventory
Exploitability-Based Prioritization
Design-Time Architecture Security
Automated Evidence-Backed Compliance

Solutions

Device Manufacturers
Automotive
Medical Devices
Energy & Utilities
Government
Industrial

Resources

Blog
Resource Library
Webinars & Videos
Events
Documentation

Company

About Us
CareersHIRING
Press & News
Contact Sales
Media Inquiries
X

© 2026 Finite State. All rights reserved.

Privacy PolicyTerms of UseCustomer Terms and Conditions
Finite StateFinite State
Finite StateFinite State