Conformity Assessments: Understanding the EU Cyber Resilience Act Requirements
Learn about the EU Cyber Resilience Act's conformity assessments. Discover how IoT manufacturers can ensure compliance based on product risk categories.

Doc McConnell
Head of Policy and Compliance
TL;DR A CRA conformity assessment is how you prove a connected product meets the EU Cyber Resilience Act's security requirements before it goes on sale. Your product's risk category, Default, Important Class I, Important Class II, or Critical, decides whether you can self-assess or need a third party. Every route asks for the same continuous, defensible evidence, so the smart move is to build that proof as you ship, not scramble for it at the end.
The EU Cyber Resilience Act changes how connected device manufacturers prove their products are secure. It makes conformity assessment mandatory: before a product with digital elements reaches the EU market, you have to show it meets a defined set of cybersecurity requirements.
Most coverage of this topic stops at "here are the four categories." That misses the point. The category you land in only decides which door you walk through. The evidence sitting behind every door is the same: a defensible record of what you shipped, the risks you found, and the fixes you made. Treat conformity assessment as the output of continuous work, not a last-mile scramble, and it stops being a fire drill.
This guide walks through what a conformity assessment is, who it affects, how product categories map to assessment routes, and how to get ready. It's the final installment in our six-part series on the EU Cyber Resilience Act.
What is a CRA conformity assessment?
A CRA conformity assessment is the formal process of proving a product with digital elements meets the Cyber Resilience Act's essential cybersecurity requirements before you place it on the EU market.
Think of it as the evidence step. The CRA sets out a baseline of security requirements that every in-scope product must meet, covering secure design, vulnerability handling, and security updates across the product's supported life. Conformity assessment is how you demonstrate you've actually met that baseline, either by assessing the product yourself or by bringing in an accredited third party. When you pass, you issue an EU Declaration of Conformity and apply the CE mark. No assessment, no market access.
Here's the part that matters for how you work. The assessment checks both the product and the processes behind it, across the whole lifecycle. That means the proof can't be assembled the week before launch. It has to be grounded in what you actually ship and maintained as the product changes.
Who is affected by the EU Cyber Resilience Act requirements?
The CRA applies to manufacturers, importers, and distributors of almost any product with digital elements sold in the EU, including companies based outside the EU whose products reach the EU market.
If your hardware or software connects to a device or network, you're likely in scope. That covers the obvious connected gear and the components inside it: firmware, embedded software, operating systems, and the open source libraries you depend on. The manufacturer carries the heaviest load, since you're the one declaring conformity. Importers and distributors have their own duties to verify that what they're selling carries the right marking and documentation.
Location doesn't get you out of it. If you ship into the EU from the United States, Asia, or anywhere else, the CRA applies the moment your product hits the EU market. For most global manufacturers, that makes CRA conformity a condition of doing business in Europe, not a regional edge case.
How does the EU CRA impact businesses operating in the EU?
The CRA turns product cybersecurity from a voluntary practice into a market-access requirement, with binding obligations, documented evidence, and real fines for getting it wrong.
For businesses, the practical impact lands in three places. First, you need a continuous vulnerability handling process, not a one-time audit, because the obligation runs for the product's whole support period. Second, you need cybersecurity technical documentation maintained for every product you sell. Third, you need a path to the CE cybersecurity marking through conformity assessment. The companies that feel this most are the ones managing large portfolios, since each product needs its own evidence and its own documentation.
This is where the old way breaks down. Security shouldn't be a last-mile scramble before a launch. It should be a continuous, evidence-backed workflow that produces compliance proof as a byproduct of building the product well.
How does the CRA classify products into risk categories?
The CRA sorts products into four risk tiers, Default, Important Class I, Important Class II, and Critical, and the tier decides how rigorous your conformity assessment has to be.
The logic is simple: scale the scrutiny to the risk. A Bluetooth speaker doesn't need the same oversight as a firewall protecting an industrial network. So the CRA defines categories and matches each to a proportionate assessment route. The Commission estimates the lowest-risk Default tier covers around 90% of products [verify before publishing], with the higher tiers reserved for products whose failure would ripple outward.
One thing that's easy to miss: every category, from Default to Critical, has to meet the same set of essential cybersecurity requirements in Annex I. Your category doesn't change what you must achieve. It only changes how you prove it. That's the through-line of this whole regulation, and it's why the evidence work matters more than the category you fall into.
The four categories at a glance
Default (lowest risk). Around 90% of products [verify before publishing]. Examples: smart home devices, printers, Bluetooth speakers, and media player software.
Important Class I. Products performing a security-relevant function. Examples: password managers, identity management systems, operating systems, and routers, modems, and switches intended to connect to the internet.
Important Class II. Higher-impact products whose compromise could affect many others. Examples: firewalls, tamper-resistant microprocessors and microcontrollers, and intrusion detection and prevention systems.
Critical (highest risk). Examples: hardware devices with security boxes, smart cards, and smart meter gateways.
What conformity assessment route does each product category use?
Default and most Important Class I products can self-assess. Important Class II and Critical products must bring in an accredited third-party body. The route follows the risk.
The CRA's assessment procedures come from Annex VIII and map to standard EU "modules." In plain terms: self-assessment means you do the work and declare conformity on your own responsibility. Third-party assessment means an independent notified body examines your product, your technical documentation, and your vulnerability handling processes before signing off. Here's how the categories line up.
| Product category | Conformity assessment route | Who verifies | Example products |
|---|---|---|---|
| Default | Internal control / self-assessment (Annex VIII, Module A) | You (the manufacturer) | Smart home devices, printers, Bluetooth speakers, media players |
| Important Class I | Self-assessment if you apply a harmonized standard, common specification, or European cybersecurity certification scheme; otherwise third-party assessment | You, or a notified body if no scheme applies | Password managers, identity management, operating systems, routers, modems, switches |
| Important Class II | Third-party assessment required (EU-type examination, Module B + C, or full quality assurance, Module H) | Notified body | Firewalls, tamper-resistant microprocessors, intrusion detection/prevention systems |
| Critical | European cybersecurity certification scheme; where unavailable, the third-party routes above | Accredited certification body / notified body | Hardware security modules, smart cards, smart meter gateways |
A few details worth holding onto. For Default products, the self-assessment protocol is laid out in Annex VIII, and you prepare technical documentation covering the product description, a risk analysis, and the measures you took to address those risks. For Important Class I, the self-assessment door stays open only if a harmonized standard, common specification, or certification scheme fully covers the requirements. Specific harmonized standards for the CRA are still being developed [verify before publishing], so this route may be narrower in practice than it looks on paper. For Important Class II and Critical, plan for a notified body from the start, because third-party involvement is mandatory regardless of which standards you've applied.
Whichever route applies, the technical evidence underneath it is the same: a complete, accurate SBOM and technical documentation set that proves what's in your product and how you handle its risks.
Are there specific sectors more impacted by the EU Cyber Resilience Act?
The CRA is horizontal, so it applies across sectors, but the impact is heaviest where products fall into higher risk tiers: industrial, medical, automotive, and critical infrastructure.
The regulation doesn't single out an industry by name. It classifies by what a product does and what happens if it fails. That means sectors shipping security-critical or safety-critical products carry more of the third-party assessment burden. Makers of industrial control components, network security gear, and identity or authentication systems are more likely to land in Important Class II or Critical, where the bar is highest.
That said, plenty of CRA-affected products sit alongside other sector rules you may already be meeting. Medical device makers work with FDA cybersecurity expectations. Automotive suppliers work with ISO 21434 and UN R155. The CRA doesn't replace those, it adds a separate EU market-access requirement on top. The teams that handle this well treat all of it as one connected evidence problem rather than a stack of separate audits.
How can organizations prepare for the EU CRA requirements?
Start by inventorying every product with digital elements, classifying each into its CRA tier, and identifying the evidence gaps now, well before the December 2027 deadline.
You can't prove conformity for products you haven't mapped. So preparation starts with a system of record: what you ship, what's inside it, and which tier each product falls into. From there the work is concrete and sequential. Here's a practical starting sequence. For a deeper walkthrough, see our guide on how to prepare for the EU CRA.
| Step | What to do | Why it matters |
|---|---|---|
| 1. Inventory | Build a complete list of products with digital elements and their components | You can't assess what you can't see |
| 2. Classify | Map each product to Default, Important I/II, or Critical | The tier sets your assessment route |
| 3. Generate SBOMs | Produce a current, machine-readable SBOM per product | Required evidence; surfaces hidden component risk |
| 4. Analyze risk | Identify and prioritize real, reachable vulnerabilities | Annex I requires documented risk handling |
| 5. Build documentation | Assemble the technical documentation each route needs | This is what an assessor or notified body reviews |
| 6. Stand up vulnerability handling | Put a continuous process in place for the product's life | The obligation doesn't end at launch |
The thread running through all six steps: don't wait. Most of this work pays off whether or not an auditor ever asks. A clean inventory, an accurate SBOM, and a documented risk process make your products more secure today and produce conformity evidence as a side effect. That's the difference between a continuous workflow and a scramble.
What resources are available to help understand the EU Cyber Resilience Act?
The most authoritative resources are the European Commission's official CRA pages and the regulation text itself, backed by practitioner guides that translate the legal language into engineering steps.
Go to the primary sources first. The European Commission's Cyber Resilience Act policy page lays out scope, obligations, and timeline, and its implementation factpage tracks milestones like notified-body readiness. For the binding detail, the regulation text, Regulation (EU) 2024/2847, contains the essential requirements (Annex I), the product categories (Annex III and IV), and the conformity assessment procedures (Annex VIII).
From there, the practical questions are usually about how to produce the evidence. Our own library covers the building blocks: security by design under the CRA, the SBOM and documentation requirements, and how to focus triage with reachability-based vulnerability prioritization. When you're ready to turn preparation into an audit-ready package, our certification acceleration services assemble the technical evidence mapped to CRA requirements.
Conclusion
CRA conformity assessment raises the cybersecurity bar for connected products, and it scales the effort to the risk. Default products self-assess. Critical products go through certified third parties. But the category is just the route. The evidence is the constant.
So build that evidence into how you work. Make your software inventory, your risk analysis, and your documentation continuous and grounded in what you actually ship. Do that, and conformity assessment becomes a report you can generate, not a deadline you dread.
Want to see what audit-ready CRA evidence looks like in practice? Request a CRA walkthrough and we'll show you.


