How to obtain a CE certificate for the CRA: A practical guide

Getting your product CE certified under the Cyber Resilience Act (CRA) might seem daunting, but it’s a journey with a clear, logical path. This guide is your practical roadmap, designed to turn the CRA’s complex legal requirements into a straightforward, actionable plan for manufacturers.

Your Practical Roadmap to CRA CE Certification

The Cyber Resilience Act fundamentally changes what it means to sell hardware or software in the European Union. That CE mark on your product no longer just covers electrical safety or radio interference; it’s now a declaration that your product meets some of the world’s strictest cybersecurity standards, right from the design phase through to its end of life.

This guide walks you through the entire process, step-by-step. We’ll start with the most basic question—does the CRA even apply to you?—and then map out every milestone on the road to full compliance.

The Core Milestones of Your Journey

Successfully getting that CE mark is not a one-off task. It’s a continuous process that weaves security deep into your product development and post-market support. Each stage builds on the last, creating a solid evidence file that proves your product is secure.

Here’s a look at the essential stages involved:

• Applicability Check: First things first, you need to confirm if your product is a ‘product with digital elements’ under the CRA’s definition.
• Product Classification: Next, you’ll figure out if your product is in the default ‘Important’ class or the more stringent ‘Critical’ class. This decision shapes your entire assessment strategy.
• Conformity Assessment: This is where you execute the right procedure. It might be a self-assessment for lower-risk products or a mandatory third-party audit by a Notified Body for critical ones.
• Documentation Assembly: You’ll need to create a comprehensive Technical File and an EU Declaration of Conformity. This is your proof of compliance.
• Post-Market Surveillance: Finally, you must have solid processes for ongoing vulnerability management, reporting incidents to authorities, and shipping security updates throughout the product’s entire support period.

The CRA elevates technical documentation from a bureaucratic chore to the legal bedrock of your market access. Without a detailed, living, and accurate file, achieving and maintaining CE marking is simply not possible.

Let’s walk through a quick example to see how this works in the real world. Imagine you manufacture a smart home thermostat.

First, you’d confirm the CRA applies (it definitely does). Then, you’d classify it. Since it likely doesn’t handle highly sensitive data or control critical infrastructure, it would fall into the default class, which means you can perform a self-assessment. From there, you’d compile all the required technical documentation—including a thorough risk assessment and a Software Bill of Materials (SBOM)—before you can formally declare conformity and apply the CE mark.

This table summarises the essential stages you’ll navigate.

Key Milestones for CRA CE Certification

Milestone	Objective	Key Action
Applicability & Scope	Determine if the CRA applies to your product.	Analyse product features against the definition of 'products with digital elements'.
Product Classification	Classify the product as Default or Critical.	Assess the product's function and potential impact based on CRA criteria.
Conformity Assessment	Choose and execute the appropriate assessment procedure.	For Default Class, prepare for internal control (self-assessment). For Critical Class, engage a Notified Body.
Documentation	Create the required technical file (Annex II) and DoC (Annex VII).	Compile risk assessments, SBOM, design documents, and test reports.
Post-Market Activities	Establish ongoing vulnerability management and reporting.	Implement a vulnerability disclosure policy and a secure update mechanism.

Understanding this full journey from the outset is crucial. It helps you allocate the right resources, budget effectively, and build compliance into your workflows from day one, not as an afterthought. For a detailed breakdown of the timeline, check out our guide on CRA deadlines between 2025 and 2027.

Does the CRA Apply to Your Product?

Before you even think about CE certificates and conformity assessments, the first and most critical question is simple: does the Cyber Resilience Act even apply to your product?

Getting this wrong is a huge risk. You could waste months and significant budget on compliance you don't need. Worse, you could completely miss mandatory obligations and face serious penalties down the line. The CRA’s scope is massive, so a methodical check is non-negotiable.

The entire regulation hinges on one key phrase: 'products with digital elements' (PDEs). This term was deliberately made broad to capture the sheer variety of modern tech. It covers any software or hardware product—and its remote data processing solutions—that connects, either directly or indirectly, to another device or network.

This definition is a net that catches almost everything. It’s not just for the obvious culprits like smartwatches or security cameras. It also pulls in standalone software, firmware, and even individual components that get baked into a larger system.

Identifying a Product with Digital Elements

Let's make this real. A smart thermostat that talks to your home Wi-Fi is a textbook PDE. An industrial sensor sending data back to a control system? Also a clear-cut case.

But the CRA’s reach extends further. What about the less obvious scenarios?

• Standalone Software: That photo editing app you sell online? It’s a PDE. It might not be a physical gadget, but it's a software product with digital elements placed on the EU market, and that’s what matters.
• Firmware: The code running a modern washing machine—the part that enables smart cycles and app connectivity—is covered. The manufacturer of that firmware (or the washing machine itself) has CRA duties.
• Embedded Components: A tiny Bluetooth module you sell to other companies to build into their own products is a PDE in its own right. As the module maker, you’re on the hook for ensuring it meets CRA requirements.

The rule of thumb is this: if your product has software or can connect to a network—even indirectly through another device—you should work on the assumption that the CRA applies. The bottom line is that CE marking now extends to the digital elements of your product, demanding a whole new level of diligence.

Understanding Key Exemptions

While the scope is wide, the CRA isn't trying to reinvent the wheel. It carves out specific exemptions to avoid piling on new rules where solid cybersecurity regulations already exist.

The most important exemptions are for products where cybersecurity is already handled by other sector-specific EU laws. This is a practical move to stop manufacturers from getting tangled in two different sets of rules for the same security goals.

Here are the big ones:

• Medical Devices: Anything covered by the MDR (Regulation (EU) 2017/745) and IVDR (Regulation (EU) 2017/746) is out. For example, a connected insulin pump regulated under the MDR would be exempt from the CRA.
• Aviation: Civil aviation gear falling under Regulation (EU) 2018/1139 has its own framework.
• Automotive: Vehicles and their components covered by Regulation (EU) 2018/858 are also exempt. For instance, the infotainment system in a new car is governed by automotive-specific regulations, not the CRA.

You have to be absolutely sure your product is fully covered by one of these existing laws. If it is, the CRA doesn’t apply. If there’s any ambiguity, you need to proceed as if you’re in scope. For a more detailed breakdown, check out our guide on Cyber Resilience Act applicability.

There’s one more important nuance: open-source software. If software is developed or supplied completely outside of any commercial activity, it’s generally exempt. But the second that open-source component gets integrated into a commercial product, the manufacturer of that final product takes on full responsibility for its compliance under the CRA. Nailing this determination is the bedrock of your entire CE certification strategy.

Classifying Your Product: Important vs. Critical

Once you’ve confirmed the Cyber Resilience Act applies to your product, you face the single most important decision on your compliance journey: classification.

This choice dictates your entire conformity assessment path, determining whether you can self-declare or must involve a third-party auditor. Getting it right is fundamental to successfully obtaining a CE certificate for the CRA.

The regulation neatly splits products into two main categories. The vast majority will fall into the default ‘Important’ class (Class I). A smaller subset of higher-risk products is categorised as ‘Critical’ class (Class II).

This decision tree gives you a high-level view of the initial CRA applicability questions that lead you to the classification stage.

As the flowchart shows, after confirming your product has digital elements and is sold in the EU without being exempt, classification becomes your immediate priority.

Understanding the Default ‘Important’ Class

Most products with digital elements will belong to Class I. This is the default category for items that don't perform the high-risk functions listed in the more stringent Critical class criteria.

The key benefit here is huge: manufacturers can typically use a self-assessment process known as Module A (internal production control).

Think of a consumer-grade smart speaker. While it has digital elements and connects to a network, its failure doesn't typically cause systemic disruption or widespread harm. Other examples of likely Class I products include:

• Smart home appliances like refrigerators or coffee makers.
• Standalone productivity software for general office use, such as a word processor or a calendar app.
• Connected fitness trackers and smartwatches.

For these products, the manufacturer is responsible for the cybersecurity risk assessments, compiling the technical documentation, and issuing the EU Declaration of Conformity—all without mandatory third-party oversight.

Identifying a ‘Critical’ Class Product

The Critical class, or Class II, is reserved for products whose failure could have a significant negative impact on society, critical infrastructure, or public safety. The criteria for this class are explicitly defined in Annex III of the regulation.

If your product falls into any of these categories, you must engage a Notified Body for a third-party conformity assessment. This is a much more rigorous and costly process, often involving an EU-type examination (Module B) followed by conformity to type based on internal production control (Module C).

The distinction between Important and Critical isn't about the product's quality or complexity; it’s about its function and the potential impact of its failure. A simple component in a power grid has far greater systemic risk than a feature-rich video game.

Here are some practical examples of products that would almost certainly be classified as Critical:

• Network Equipment: Routers, modems, and network switches that form the backbone of internet connectivity.
• Industrial Control Systems (ICS): Components like programmable logic controllers (PLCs) used in manufacturing plants or power grids.
• Security Hardware: Hardware Security Modules (HSMs) and smartcards that protect cryptographic keys.
• Operating Systems: General-purpose operating systems for desktops and servers are considered critical due to their foundational role.

A Practical Checklist for Classification

To guide your decision, ask these direct questions about your product's function and intended use. The answers will point you toward the correct classification.

1. Does my product function as a core network component? (e.g., router, firewall, modem)
2. Is it a component of an Industrial Control System or SCADA system?
3. Does it manage identities or provide authentication services? (e.g., password managers, identity providers)
4. Is it a general-purpose operating system or hypervisor?
5. Does it function as a public key infrastructure (PKI) or certificate-issuing system?

If you answer "yes" to any of these, your product is likely in the Critical class. This determination is the pivot point for your entire strategy to obtain a CE certificate for the CRA, defining the timeline, budget, and resources required.

Choosing Your Conformity Assessment Path

Once you’ve pinned down your product's classification, it's time to tackle the conformity assessment. This is where you formally prove that your product meets the CRA's essential cybersecurity requirements—it's a make-or-break stage for getting your CE certificate. The path you take is decided entirely by your product's classification: Class I or Class II.

For the vast majority of products falling into Class I, the journey is more direct. You can use an internal control procedure, which is detailed in Module A of the regulation. Think of it as a self-assessment; you take full responsibility for testing your product, compiling all the evidence, and formally declaring it conforms.

Things get tougher for Class II products. Because they carry a higher systemic risk, the process demands mandatory involvement from a third-party auditor, known as a Notified Body. This usually means a combination of procedures, like an EU-type examination (Module B) followed by an internal production control process (Module C).

The Path for Class I Products: Internal Control

If your product is Class I, you're in the driver's seat for the conformity process. This doesn't mean it’s easy—far from it. But it does mean you avoid the time and cost of an external auditor for the assessment itself. The responsibility to be diligent and rigorous rests entirely on your team.

Your workflow needs to be methodical and meticulously documented. Here’s what that looks like in practice:

• Establish Solid Security Processes: Implement and document your secure development lifecycle (SDL) practices, vulnerability management procedures, and quality assurance checks.
• Conduct Robust Security Testing: Test your product thoroughly against the essential requirements in Annex I of the CRA. This isn't just a simple check; it involves penetration testing, code reviews, and vulnerability scanning.
• Compile the Technical Documentation: This is your evidence locker. Build the comprehensive technical file required by Annex II, making sure it includes your cybersecurity risk assessment, all test reports, and a complete SBOM.
• Issue the EU Declaration of Conformity: This is the final step where you formally declare that your product meets all CRA obligations, referencing the standards you've applied.

Let's say your company develops a photo editing application—a classic Class I product. Your internal team would run static and dynamic security tests, document every result, compile a full SBOM, and write a detailed risk assessment. Once all this evidence is gathered in their technical file, they can sign the Declaration of Conformity and proudly affix the CE mark.

The Route for Class II Products: Involving a Notified Body

If you’ve classified your product as Class II—think network routers or operating systems—self-assessment is off the table. You must bring in a Notified Body, which is an independent organisation designated by an EU Member State to assess certain products before they hit the market.

Choosing the right Notified Body is a strategic move. Don't just pick the first one you find; look for one with proven expertise in cybersecurity and your specific product category. Your engagement will almost certainly follow the Module B + C procedure.

Module B (EU-Type Examination): The Notified Body digs into your technical documentation and product samples to verify that the design truly meets CRA requirements. If you pass, they issue an EU-type examination certificate.

Module C (Conformity to Type): After that, you implement an internal production control process to ensure every single product you manufacture consistently meets the approved type.

Although regional or country-specific data such as manufacturer demographics, market penetration, and compliance timelines for Spain are not available, the Cyber Resilience Act compliance framework addresses obligations across the entire EU market. This means the choice of a Notified Body is not limited by geography, but by their designated scope and expertise.

Preparing for a Notified Body Assessment

When you're gearing up for a Module B assessment, remember that the Notified Body will scrutinise every piece of evidence. They won't just take your word for it; they need cold, hard proof.

Imagine you manufacture an industrial firewall, a clear Class II product. Your submission package has to be airtight. You'd need to provide:

• Complete Technical Documentation: This means detailed architectural diagrams, your full cybersecurity risk assessment, and a clear rationale for your design choices. For the firewall, this would include diagrams of packet inspection flows and access control logic.
• A Complete SBOM: The Notified Body will want to see a full inventory of all software components to properly assess supply chain risk.
• Verification and Validation Reports: This is your crucial evidence. It should include results from penetration tests, secure code reviews, and functional security tests, ideally conducted by a reputable third party.
• Process Documentation: You need to show evidence of your secure development, vulnerability handling, and quality assurance processes in action. For example, you would provide change logs, code review records, and minutes from security review meetings.

The Notified Body’s role is to be an impartial judge, confirming that you’ve done the work to secure your product according to the law. A well-organised, complete submission is your best bet for a smooth and successful assessment. You can explore more about these procedures by reading our detailed article on CRA conformity assessments.

Pulling Together Your Technical File and EU Declaration

Claiming your product is compliant is one thing; proving it is another. Under the Cyber Resilience Act, your CE mark is only as credible as the evidence you have to back it up. This proof comes in two key forms: the comprehensive Technical Documentation file and the formal EU Declaration of Conformity.

Think of the technical file as the complete casebook for your product's security—every decision, test, and risk assessment meticulously recorded. The declaration, on the other hand, is your official, legally binding statement that you've done the work.

Don't treat this as a simple box-ticking exercise. Market surveillance authorities can request your technical file years after your product is on the market. If it's incomplete, outdated, or can't be produced, you're looking at a serious breach, potentially leading to fines and recalls. This documentation is the very foundation of your CE certification effort.

Crafting the Technical Documentation

The technical documentation, detailed in Annex VII of the CRA, isn't a one-and-done report. It's a living file that must be created before your product ever hits the market and kept up-to-date throughout its entire support period. Getting it right is a team sport, requiring tight collaboration between your engineering, security, and legal teams.

Let's make this real. Imagine you're a manufacturer of an IoT-enabled smart lock. Your technical file would need to be organised with military precision to prove compliance.

Here’s a breakdown of what that file would absolutely need to include:

• General Product Description: This isn't just a marketing blurb. It details the lock's intended purpose, its core functions, the specific hardware model, and all firmware versions. It also needs to explain how the lock connects to a home network and interacts with its companion mobile app.
• Design, Development, and Production Details: Time to show your work. This section would include architectural diagrams illustrating how components talk to each other, a full rundown of the secure development lifecycle (SDL) you followed, and key details about your manufacturing process.
• Cybersecurity Risk Assessment: This is the heart of the file. Here, you document the threats you've identified (like brute-force attacks, unauthorised access, or denial-of-service attempts), assess their potential impact, and clearly outline the mitigation measures baked into the lock's design.
• Support Period Justification: You can't just pick a number out of thin air. You must justify your product's support window (say, five years), explaining how you landed on that figure based on factors like user expectations and the hardware's expected lifespan.
• Software Bill of Materials (SBOM): You need a complete inventory of every single software component in your product. This includes all the open-source libraries used in the lock's firmware and the mobile app. It's non-negotiable for tracking and responding to new vulnerabilities. To get this right, it's wise to follow established technical documentation best practices.
• Test Reports and Validation: This is your proof. The file must contain the results from penetration tests, vulnerability scans, and secure code reviews that verify the lock meets the essential security requirements laid out in Annex I.

A well-maintained technical file is more than just a regulatory headache; it's a strategic asset. It signals maturity to potential partners, creates a single source of truth for your internal teams, and becomes your first line of defence in a market surveillance audit.

For a deeper look at how to structure all this information, check out our guide on the CRA technical file structure.

The EU Declaration of Conformity Explained

If the technical file is the detailed evidence, the EU Declaration of Conformity (DoC) is the one-page summary statement that puts your name on the line. By signing it, you, the manufacturer, are taking full legal responsibility for your product’s compliance with the CRA.

Don't underestimate this document. It’s not just another form to fill out; it's the formal instrument that links your specific product to your technical documentation and justifies the CE mark you've placed on it.

Your DoC must contain several key pieces of information:

1. Unique Product Identifier: A model or serial number that leaves no doubt as to which product is being declared.
2. Manufacturer's Details: Your company’s official name and address.
3. Statement of Responsibility: A clear sentence stating the declaration is issued under the sole responsibility of the manufacturer.
4. Object of the Declaration: A description of the product sufficient for traceability.
5. Declaration Statement: A formal assertion that the product conforms to the Cyber Resilience Act (Regulation (EU) 2024/2847).
6. References to Standards: A list of any harmonised standards or common specifications you’ve used to demonstrate conformity.
7. Notified Body Information (If Applicable): For Class II products, you must include the name and number of the Notified Body involved and a reference to the EU-type examination certificate they issued.
8. Signature and Date: The document must be physically or digitally signed by an authorised person from your company.

Finally, this declaration needs to be translated into the required languages of the EU member states where you plan to sell. It’s the last, crucial piece of the puzzle before you can legally and confidently affix the CE marking to your product.

Life After Certification: Your Post-Market Responsibilities

Getting your CE certificate isn't the finish line; it’s really just the start of your ongoing duties under the CRA. The regulation shifts the focus from a one-time product approval to continuous, lifecycle-long security vigilance. The work you do after the product launch is just as critical as everything you did to get certified in the first place.

This means you’re on the hook for actively monitoring new vulnerabilities throughout your product's entire support period, which could be as long as five years. You are also legally required to set up clear, secure channels so security researchers and users can report any issues they find.

Managing Vulnerabilities and Hitting Reporting Deadlines

The moment a vulnerability is reported or discovered, a clock starts ticking. The CRA imposes some very strict notification timelines that demand a swift, organised response.

Let's imagine a security researcher finds a flaw in your connected doorbell and reports it. Your team must have a rock-solid process to acknowledge, investigate, and triage that report. If that same vulnerability is then found to be actively exploited in the wild, you have just 24 hours to report it to the European Union Agency for Cybersecurity (ENISA).

This reporting obligation is one of the most significant post-market responsibilities. The Cyber Resilience Act itself enters into force in December 2024, with full application required by December 2027. You can get familiar with all the key dates in the official EU policy on the Cyber Resilience Act.

A strong Coordinated Vulnerability Disclosure (CVD) policy is no longer just a best practice; it's a legal requirement. It must clearly define how you receive reports, your timelines for validation and fixes, and how you communicate with the person who found the issue.

A Practical Disclosure Workflow

To manage these responsibilities without chaos, your process needs to be clear and repeatable. Here’s what a practical workflow for handling a vulnerability report should look like:

• Acknowledge Receipt: Immediately confirm you’ve received the report. For example, an automated email reply stating, "Thank you for your report. Our security team will review it and respond within 48 hours."
• Triage and Validate: Assess the severity of the vulnerability and confirm it's real.
• Develop a Patch: Your engineering team gets to work creating and testing a security update.
• Notify Authorities (if needed): If the issue is actively exploited, you submit your initial report to ENISA within that 24-hour window.
• Release the Update: Deploy the security patch to all affected users without delay. For a smart device, this would mean pushing a mandatory over-the-air (OTA) update.

Building these kinds of sustainable security practices into your product lifecycle is absolutely essential. It's the only way you'll maintain your CE certificate for the CRA long after the product has launched.

A Few Common Questions About the CRA CE Certificate

As you get deeper into the CRA, a few common questions always pop up, especially around products that are already out there and how the rest of the supply chain fits into the picture. Let’s tackle some of the most frequent ones.

What About Products Already on the Market?

This is a big one. What happens to products you sold before the CRA fully kicks in? The rule is actually pretty straightforward: if a product was placed on the market before the full application date (that's in 2027), it’s generally exempt.

But there’s a critical exception. If an existing product goes through a “substantial modification” that could change how it complies with cybersecurity rules, it gets treated as a brand-new product. That means it has to meet all the CRA requirements from scratch.

So, what counts as "substantial"? A minor firmware update that adds a new feature to a smart speaker from 2025 probably won't trigger this. However, an update adding new cloud connectivity or remote control functions almost certainly would, pushing it back into a full conformity assessment.

What’s the Role of Importers and Distributors?

While manufacturers carry most of the weight, importers and distributors aren’t just passive players. They’re the gatekeepers for the EU market, and they have specific verification duties.

• Importers: You must check that the manufacturer has done their job. This means verifying they’ve completed the right conformity assessment, created the technical file, and put the CE mark on the product. You also need to make sure your own contact details are on the product.
• Distributors: Your job is to perform a final check. Before you sell anything, you need to confirm the product has the CE marking and comes with all the required documents and instructions in the right language.

Let's take a practical example. A distributor in Germany receives a shipment of smart cameras from a non-EU manufacturer. Before putting them on shelves, they must verify the CE mark is present on the product and packaging, and that the instruction manual is available in German. If not, they cannot legally sell the product. The bottom line is simple: if you bring a non-compliant product into the EU, you share the responsibility. You can't just pass the buck back to the manufacturer.