Your Guide to CRA CE Marking Requirements

For years, the CE mark on a product has been a quiet symbol of trust. It tells you a device meets the EU’s essential health, safety, and environmental standards. But with the Cyber Resilience Act (CRA), that familiar mark is getting a major cybersecurity upgrade.

Think of the new CE mark as a cybersecurity passport for any product with digital elements you sell in the EU. It’s your formal declaration that the product is secure by design, has a solid plan for managing vulnerabilities, and comes with clear, transparent security information for users. Without this passport, your product simply won’t be allowed into the market.

What Are the CRA CE Marking Requirements?

The Cyber Resilience Act fundamentally transforms the CE mark from a general safety promise into a legally binding statement about your product’s digital security. Where a CE mark on an IoT device once signified electrical safety or electromagnetic compatibility, it will now also prove the product meets a tough set of cybersecurity rules.

This isn’t a small change. It means manufacturers can no longer afford to treat security as a feature or an afterthought. It has to be baked into the product from day one. More importantly, compliance isn’t a one-off task you can tick off a list; it’s a continuous commitment that lasts for the entire product lifecycle.

To get a better sense of the core requirements, we’ve put together a quick summary table. This breaks down the main pillars you’ll need to build your compliance strategy on.

Core Pillars of CRA CE Marking at a Glance

Pillar	What It Means for You	Key Deadline
Secure by Design & Default	Your product must be developed with security built-in, not bolted on. This includes minimising the attack surface and ensuring it ships with a secure configuration out of the box.	Late 2027
Technical Documentation	You need to maintain a detailed technical file, including a cybersecurity risk assessment and a Software Bill of Materials (SBOM), ready for inspection by authorities.	Late 2027
Vulnerability Management	You must have a public, structured process for receiving, assessing, and fixing security vulnerabilities. This isn’t optional; it’s a core operational requirement.	Late 2027
Lifecycle Support	You are legally obligated to provide security updates for a support period that reflects how long the product is expected to be in use: at least five years, unless the expected time of use is shorter. You must be transparent about the support period.	Late 2027
Breach & Vulnerability Reporting	You must send an early warning of any actively exploited vulnerability or severe incident within 24 hours of becoming aware of it, through the single reporting platform to the coordinating CSIRT and ENISA, and inform affected users. This obligation started earlier than the others.	11 September 2026

Ultimately, achieving CE marking under the CRA is about proving you have a handle on these five pillars. Each one represents a critical part of your product's journey to the EU market.

Make no mistake: from 11 December 2027, non-compliant products can be withdrawn from the market or stopped at the border. This isn't just about avoiding hefty fines; it's a fundamental issue of market access. For any tech company selling in Europe, this has become a top business priority.

Getting this right involves a structured process, from risk assessment to final declaration. You can learn more about how to obtain a CE certificate for the CRA and what the full journey looks like. In the end, the new CE mark is designed to send a clear signal to everyone—from individual consumers to large enterprises—that your product can be trusted in our deeply connected world.

Does the CRA Apply to Your Products

The very first question on any Cyber Resilience Act compliance roadmap is simple: does this regulation even apply to my products? Getting this right from the start is absolutely critical. It stops you from wasting time and money on compliance for exempt items and lets you focus your resources where they’re actually needed.

The CRA’s scope is intentionally broad, designed to bring a baseline of cybersecurity to almost every piece of modern hardware and software sold in the EU. The regulation targets products with digital elements (PDEs), which is a straightforward term for any product containing software or firmware that can connect, either directly or indirectly, to another device or network. This definition casts an incredibly wide net, capturing a huge range of items that go far beyond what you might think of as a typical "IoT device."

Defining Products with Digital Elements

To get a handle on the scope, don't think in rigid categories. Instead, think about capabilities. If your product has any processing power and communicates digitally, it’s almost certainly in scope. That connection doesn't even have to be to the internet—a simple Bluetooth link between a device and a smartphone app is more than enough to qualify.

Here are a few practical examples of what falls under the PDE definition:

• Smart Home Devices: This covers everything from smart TVs and connected baby monitors to intelligent thermostats and home security cameras.
• Computer Hardware & Peripherals: Laptops, routers, and even computer mice with configurable software are all included.
• Standalone Software: A downloadable productivity app, a mobile game, or a photo editing program all count as products with digital elements.
• Industrial Components: Programmable Logic Controllers (PLCs), industrial sensors, and other operational technology (OT) used in manufacturing settings are firmly in scope.

This broad reach means you really need to audit your entire product line. It isn't just about what you sell, either. Even products you offer for free are covered by the CRA if they are provided as part of a commercial activity, for example, when they are monetised or tied to a paid product or service.

The core principle is straightforward: if you place a product with digital elements on the EU market, the CRA’s rules apply. It doesn't matter if your company is based in Berlin or Boston; selling into the EU is the trigger.

Understanding Key Exemptions

While the scope is wide, it isn't limitless. The CRA rightly acknowledges that some sectors are already covered by their own robust cybersecurity regulations. To avoid creating a confusing mess of overlapping legal duties, certain product categories are explicitly excluded.

Key exemptions from the CRA include:

• Medical Devices: These are already governed by the Medical Devices Regulation (MDR).
• In-vitro Diagnostic Medical Devices: These fall under the In-vitro Diagnostic Regulation (IVDR).
• Automotive: Vehicles, and the systems and components designed for them, that are type-approved under Regulation (EU) 2019/2144. Aftermarket devices sold separately are not excluded.
• Aviation: Products certified under existing aviation safety rules are exempt.
• Purely Open-Source Software: Software developed and supplied completely outside of any commercial activity is not covered. However, that exemption disappears the moment you integrate that software into a commercial product you're placing on the market.

Practical Example of an Exemption:
A German company develops an advanced driver-assistance system (ADAS) that it sells to car manufacturers across the EU. Although this system is a product with digital elements, it is exempt from the CRA because it falls under the EU vehicle type-approval framework, Regulation (EU) 2019/2144, which has its own cybersecurity requirements. The company must comply with the automotive rules, not the CRA.

For instance, in Spain's bustling tech hubs like Barcelona and Madrid, IoT vendors are already preparing for the regulatory deadlines. The new CE marking process demands a structured conformity assessment that could make or break their market access. Full CRA obligations apply from 11 December 2027, but the preparation needs to start now. From then on, market surveillance authorities will check CE marks against the CRA too, adding a whole new cybersecurity layer to existing directives. You can read more about how to prepare for CRA certification deadlines and the necessary steps.

Navigating Product Risk Classification

Once you’ve confirmed the Cyber Resilience Act applies to your products, your next critical move is to classify them. The CRA doesn’t treat all products the same; it splits them into risk categories that will dictate your entire compliance strategy, budget, and timeline. Getting this right isn't just a box-ticking exercise—it's the strategic fork in the road for your CE marking journey.

At its heart, the CRA creates four categories. The vast majority of products land in the ‘Default’ category. A smaller group whose core function is listed in Annex III is labelled ‘Important’, split into Class I and Class II, and three categories listed in Annex IV are ‘Critical’. Think of it like a smart home: a connected light bulb is a ‘Default’ product, but the central security hub managing your door locks and alarms is an important Class I product, because home security products are listed in Annex III.

This decision tree can help you visualise the first few steps in figuring out if your product falls under the CRA's scope, which then leads directly into this classification process.

As the flowchart shows, the key questions are straightforward. If you sell a digital product in the EU and it’s not specifically exempt, the CRA applies. Your next job is risk classification.

Distinguishing Default from Important and Critical Products

Most products with digital elements will be considered 'Default'. These are items that, on their own, don't pose a systemic cybersecurity risk. The good news here is that these products can usually follow a much simpler and more cost-effective path to compliance.

For products in the 'Default' category, manufacturers can perform a self-assessment of conformity. This lets you internally verify and document that your product meets all the essential security requirements laid out in Annex I of the Act.

This route involves rigorous internal testing, creating all the required technical documentation, and signing the EU Declaration of Conformity yourself. It gives you more control but also puts the full weight of compliance squarely on your shoulders.

Practical Example of a 'Default' Product:
A company in Valencia develops a smart garden watering system. Its device connects to a mobile app via Bluetooth to let users schedule watering times. A security failure would be annoying, for sure, but it’s highly unlikely to cause widespread harm. The company can therefore self-assess its product against the CRA's security rules, build its technical file, and affix the CE mark without involving a third-party auditor.

Identifying Important Products (Class I and Class II) and Critical Products

'Important' products are a different beast entirely. These are specifically listed in Annex III of the CRA and are broken down into two sub-categories: Class I and Class II, where Class II carries the stricter assessment. Above them, Annex IV lists three 'critical' categories: hardware devices with security boxes, smart meter gateways, and smartcards or similar devices, including secure elements.

The criteria are all tied to the product's core function, not to the sector it is sold to. If your product's core function is one of the following, it's almost certainly going to be considered important:

• Security Functions: This includes products like password managers, antivirus software, and virtual private networks (VPNs).
• Network Control: Think routers, modems and managed switches (Class I), and firewalls and intrusion detection or prevention systems (Class II).
• Identity and System Management: This covers identity and access management, including privileged access, network management systems and operating systems (Class I), and hypervisors and container runtimes (Class II).
• Smart Home and Toys: This bucket includes smart door locks, security cameras, baby monitors and alarm systems, along with connected toys with social interaction or location features (Class I). Industrial control systems such as PLCs or SCADA are not listed, unless their core function is one of the above.

For Class I products, a self-assessment is only possible if you apply harmonised standards, common specifications or a European cybersecurity certification scheme in full; otherwise an external, independent auditor is involved. For Class II products, self-assessment is off the table, and critical products may also need a European cybersecurity certificate.

Practical Example of an 'Important' Product:
A tech firm in Barcelona builds industrial firewalls to protect factory networks. Because firewalls are listed in Class II of Annex III, this product falls squarely into the 'Important Class II' category. To get its CE mark, the company must hire a Notified Body—an accredited third-party organisation—to conduct an independent audit of the product's design, documentation, and security controls before it can be legally sold in the EU. This external validation adds significant time and cost but provides a much higher level of assurance.

Understanding Your Role in the Supply Chain

Achieving Cyber Resilience Act compliance is a team sport, not a burden that falls on the manufacturer alone. The regulation deliberately spreads responsibility across the entire supply chain, creating a clear chain of custody for cybersecurity. Every economic operator—whether you’re a manufacturer, importer, or distributor—has distinct legal duties to ensure only secure products reach EU consumers.

Think of it like building a house. The manufacturer is the architect and builder, responsible for designing a secure structure from the ground up and proving it meets the code. The importer is the building inspector who verifies the architect's plans and materials before anyone is allowed to move in. And the distributor is the estate agent, checking that the final property has its certificate of occupancy before listing it for sale.

If a single link in this chain fails, the whole structure is at risk, and liability is shared. This principle of collective responsibility is fundamental to the CRA’s CE marking requirements.

The Manufacturer's Core Obligations

As the product’s creator, the manufacturer carries the heaviest load. They are the source of compliance, performing the foundational work that everyone else in the supply chain depends on. Their duties are extensive and form the bedrock of the product’s security posture for its entire lifecycle.

Key obligations for manufacturers include:

• Conducting a Conformity Assessment: This is the formal process of verifying and documenting that the product meets all the essential security requirements laid out in Annex I of the CRA.
• Creating the Technical Documentation: They must assemble a complete technical file, which acts as the evidence binder. This includes the cybersecurity risk assessment, a Software Bill of Materials (SBOM), and all security test results.
• Issuing the EU Declaration of Conformity (DoC): This is the legal document where the manufacturer formally declares that their product is CRA-compliant.
• Affixing the CE Mark: Once the DoC is signed, the manufacturer can place the CE mark on the product, its packaging, or its documentation.

For a deeper dive into managing the security of components within your product, consider exploring the complexities of supply chain software security. Getting this right is crucial for a complete and credible technical file.

The Importer's Crucial Verification Duty

Importers serve as the EU’s first line of defence for products originating outside the Union. They have a legal obligation to be active gatekeepers—they can't just passively assume the manufacturer has done their job correctly. Their role is one of verification, not blind trust.

Before placing any product on the EU market, an importer must confirm that the manufacturer has fulfilled their key obligations.

An importer's liability is significant. They must not place a product on the market if they have reason to believe it does not comply, and if they sell it under their own name or trademark, or substantially modify it, they take on all the manufacturer's obligations themselves. Under the CRA, ignorance is no defence.

Practical Example of an Importer's Role:
Imagine a Spanish importer in Madrid receives a shipment of smartwatches from a manufacturer in Asia. Before these watches can be sold to retailers, the importer is legally required to:

1. Verify the manufacturer has actually performed a conformity assessment.
2. Confirm that a complete technical file exists and can be made available upon request by authorities.
3. Obtain and check the EU Declaration of Conformity to ensure it is correctly filled out and signed.
4. Make sure the CE mark is visibly and correctly affixed to the product or its packaging.

Only after these checks are complete can the importer legally place the smartwatches on the EU market.

The Distributor's Due Diligence

Distributors are the final link in the chain before a product gets to the end-user. While their obligations are less intensive than those of manufacturers or importers, they still play a vital part in market surveillance. Their duty is to exercise due care.

A distributor must act with the diligence expected of a professional in their field, which means performing some basic but important checks. Before making a product available for sale, a distributor has to verify that:

• The product clearly bears the CE marking.
• It comes with the required documentation, including user instructions, in a language easily understood by consumers in that Member State.

Practical Example of a Distributor's Role:
An electronics retail chain in France receives a batch of new connected security cameras for its stores. Before putting them on the shelves, the manager must verify that each camera's box has a CE mark and that the instructions inside are written in French. If the CE mark is missing, the distributor cannot sell the cameras and must notify the importer who supplied them.

If a distributor has any reason to believe a product isn't compliant, they must not sell it. Instead, they are obligated to inform the manufacturer or importer and, if the risk is serious, the national market surveillance authorities. This final check helps ensure non-compliant products are caught before they ever reach a customer’s hands.

Preparing Your Technical Documentation and EU Declaration

Think of your technical documentation as the official evidence file for your product’s cybersecurity. It’s where you prove, on paper, that you’ve met all the CRA CE marking requirements. This isn’t about just writing another user manual; it's about systematically building a compelling case that your product is secure, resilient, and ready for the EU market.

This process is what turns abstract compliance goals into concrete, auditable proof. For market authorities, it’s the first place they’ll look to verify your claims. For you, it’s the master record of your due diligence, showing that security was baked in from the very first line of code.

You’ll need to keep this technical documentation for 10 years after the product is placed on the market, or for the support period if that is longer, ready for inspection by market surveillance authorities at any time.

What Goes into the Technical File

The CRA, in Annex VII, is quite specific about what this documentation must contain. It’s a comprehensive collection of reports, assessments, and records that tell the full story of your product's security journey from concept to deployment.

Key components you’ll need to have in order are:

• A Detailed Product Description: This should cover the product's intended purpose, design, hardware and software versions, and clear user instructions.
• Cybersecurity Risk Assessment: You have to document every cybersecurity risk you identified and, just as importantly, the steps you took to mitigate them. This is the absolute cornerstone of your file.
• Software Bill of Materials (SBOM): An inventory of your software components, from open-source libraries to commercial modules, in a commonly used, machine-readable format covering at least the top-level dependencies. This is non-negotiable under the CRA and provides critical transparency.
• Evidence of Security Testing: This includes the results from all your vulnerability scans, penetration tests, and secure code reviews. Show your work.

To properly fulfil the technical documentation requirements, you need to embed robust software security best practices for resilience into your development lifecycle, ensuring your product meets the CRA's essential security standards from the ground up.

Practical Example: A Software Company's Technical File
Imagine a software development firm in Seville preparing its new downloadable project management app for the EU market. Its technical file would include a threat model analysing potential data breaches, a full SBOM generated in CycloneDX format, and penetration test reports from a third-party security firm. They’d also document their own secure coding standards and the results of static analysis security testing (SAST) scans run during development.

The Final Step: The EU Declaration of Conformity

Once your technical documentation is complete and you've successfully passed the right conformity assessment, you reach the final, formal step: signing the EU Declaration of Conformity (DoC). This is much more than just another piece of paper; it’s a legally binding attestation.

By signing the DoC, you—as the manufacturer—take full responsibility for your product’s compliance with the Cyber Resilience Act. It is your official, public statement declaring that the product meets every single essential security requirement.

The EU Declaration of Conformity is the key that unlocks the CE mark. Without a signed DoC, you cannot legally affix the CE marking to your product. It’s the final, definitive step in proving your adherence to the CRA.

This declaration must directly reference the Cyber Resilience Act and list any harmonised standards you used to demonstrate conformity. If a Notified Body was involved in a third-party assessment (as required for Class II products, and for Class I products when harmonised standards are not applied in full), their name and identification number must also be included. Our guide offers more detail on how to prepare the CRA Declaration of Conformity correctly.

After signing the DoC, you can finally affix the CE mark to your product, its packaging, or its accompanying documents. That mark becomes the visible symbol of all the rigorous work you’ve documented, signalling to customers and regulators that your product is built on a foundation of security and trust.

Your Actionable Checklist for CRA Compliance

Let's move from theory to a practical roadmap. With the Cyber Resilience Act deadlines approaching, having a structured plan isn't just a good idea—it's essential for getting your CE marking in order. This checklist breaks down the journey from initial assessment to your final declaration, helping you see where to put your resources and how to track progress.

Waiting until the last minute simply won't work. Imagine you manufacture smart thermostats for the EU market. After the final deadline, your products can't be sold without the correct CE mark under the CRA. The penalties for getting this wrong are severe, with administrative fines reaching up to €15 million or 2.5% of your total worldwide annual turnover, whichever is higher. And the obligation to report actively exploited vulnerabilities has applied since 11 September 2026.

Phase 1: Initial Assessment and Scoping

The first phase is all about understanding where you stand and what's in scope. This foundational work is critical for focusing your efforts where they matter most.

1. Map Your Product Portfolio for CRA Applicability
   Get your legal and product teams in a room to audit every single product with digital elements sold in the EU. Your goal is a master list that clearly shows which items are in scope and which might be exempt under other rules, like those for medical devices or type-approved vehicles.

2. Classify All In-Scope Products by Risk
   Once you know what's covered, your product security team needs to classify each item. Is a product ‘Default’, does it fall into one of the ‘Important’ categories (Class I or II) of Annex III, or is it one of the ‘Critical’ products of Annex IV? This decision steers your entire conformity assessment path.

Phase 2: Gap Analysis and Policy Development

With your products mapped and classified, it's time to find the gaps in your current setup and build the internal processes you'll need. This phase is about creating the organisational muscle for ongoing compliance.

• Conduct a Gap Analysis Against Annex I: Your engineering and security teams need to methodically check your existing product security features against the essential requirements laid out in Annex I. The output will be a clear list of technical debt and new security features to build.
• Establish a Vulnerability Disclosure Policy: Your legal and security teams should work together to draft and publish a clear, public-facing policy for how you receive and handle vulnerability reports. This is a core CRA requirement and the bedrock of your post-market surveillance.
• Design Your Reporting Workflow: You need a rock-solid internal procedure for sending an early warning within 24 hours of becoming aware of an actively exploited vulnerability, through the single reporting platform to the coordinating CSIRT and ENISA. Designate who is responsible and run drills to make sure you can hit that deadline reliably.

A common mistake is underestimating the effort needed for documentation. This isn't just about writing user manuals; it's about building a complete evidence file that proves your due diligence to regulators.

Phase 3: Documentation and Final Declaration

This final phase is where you create the proof of your compliance. You'll assemble all the evidence into the formal documents required by market authorities.

1. Draft Your Technical Documentation
   As you prepare your technical documentation to show conformity, robust security assessments are a must. This often involves methods like cybersecurity penetration testing to really validate your product's resilience. Your engineering team will compile the risk assessment, SBOM, test results, and all other evidence into a complete technical file.

2. Prepare the EU Declaration of Conformity
   With a complete technical file and a passed conformity assessment, your legal team can now draft the EU Declaration of Conformity. This is the final legal step you take before you can affix the CE mark to your product.

This checklist gives you a high-level project plan. For a more granular, step-by-step tool to help manage your compliance journey, you can check out our comprehensive CRA checklist to build your own tailored roadmap.

Frequently Asked Questions About the CRA

As the Cyber Resilience Act comes into force, many manufacturers, importers, and developers are grappling with a new and complex set of rules. To help clear up some of the most common points of confusion, we’ve put together answers to the questions we hear most often about CRA CE marking requirements.

What If My Product Was on the Market Before the CRA Deadline?

The Cyber Resilience Act is not retroactive. If your product was placed on the EU market before the December 2027 compliance date, it isn’t subject to these specific rules. The one exception is the reporting obligation for actively exploited vulnerabilities and severe incidents, which applies to products already on the market too.

However, there's a crucial exception to be aware of. Any existing product that undergoes a “substantial modification” that could change its security posture will be pulled into the CRA's scope. Of course, any new product launched after the deadline must be fully compliant from day one and carry the updated CE mark.

Practical Example: A company launched a smart coffee machine in 2026. This product is not subject to the CRA's product requirements. However, in 2028, the company releases a major firmware update that adds a new cloud connectivity feature. This is a "substantial modification," so the updated coffee machine must now become fully CRA compliant and obtain the correct CE mark.

How Long Must I Provide Security Updates?

Manufacturers have a legal obligation to provide security updates for a support period of at least five years from placing a product on the market, unless the product is expected to be in use for less time. This duty is a cornerstone of the CRA's post-market surveillance requirements, designed to ensure products stay secure long after the initial sale.

If a product's expected lifetime is shorter than five years, the support period can match that shorter duration. The key is that this support period must be clearly communicated to customers in the product's documentation, providing essential transparency.

Practical Example: A company sells a smart home camera with an expected lifetime of seven years. Its support period should reflect those seven years; five years is only the floor. If it sells a simpler connected toy with an expected lifetime of only three years, it is only obligated to support it for those three years.

Can I Use One Declaration of Conformity for Multiple EU Rules?

Yes, you can. If your product is also covered by other EU legislation that requires a Declaration of Conformity—like the Radio Equipment Directive (RED), for example—you are permitted to create a single, consolidated EU Declaration of Conformity. This is a practical measure to help simplify the administrative burden.

This single document must clearly list all the applicable EU acts your product complies with. It serves as your formal statement that the product meets all relevant requirements from each piece of legislation, not just the CRA.

What Is a Software Bill of Materials (SBOM) and Why Do I Need It?

A Software Bill of Materials (SBOM) is a detailed, structured inventory of all the software components, libraries, and modules that make up your product. The simplest way to think about it is as a list of ingredients for your software.

The CRA requires manufacturers to draw up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. Its purpose is to create much-needed transparency in the software supply chain. By maintaining this list, you, your customers, and regulatory authorities can quickly identify and manage potential vulnerabilities found in the third-party code your product depends on.

---

Navigating the complexities of the Cyber Resilience Act can be a major challenge. Regulus is a free platform for manufacturers: it classifies your product, walks you through the Annex I requirements, builds the risk assessment and SBOM, tracks the Article 14 reporting deadlines and generates the technical documentation and declaration of conformity in Word. Learn more about how Regulus can help your business prepare for the CRA.