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 complete 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 the product’s expected lifetime or a minimum of five years, and you must be transparent about the support period. | Late 2027 |
| Breach & Vulnerability Reporting | You must notify ENISA of any actively exploited vulnerabilities within 24 hours and inform your users of serious incidents without undue delay. This obligation starts earlier than others. | Mid-2027 |
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: starting in 2027, any non-compliant products will be 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, by carrying your company's branding.
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 their components are covered by specific UNECE regulations.
- 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 existing UNECE automotive regulations, which have their 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 racing to meet regulatory deadlines. The new CE marking process demands a structured conformity assessment that could literally make or break their market access. According to official timelines, full CRA obligations apply from 11 December 2027, but the preparation needs to start now. With over 500,000 digital products imported annually into the ES region, Spanish authorities will be scrutinising CE marks under the CRA, 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 two main buckets. The vast majority of products land in the ‘Default’ or non-critical category. A smaller, more sensitive group gets labelled ‘Critical’. The dividing line is simple: what’s the potential for widespread damage if the product’s security fails? 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 squarely in the ‘Critical’ camp.
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 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 Critical Products in Class I and Class II
'Critical' products are a different beast entirely. These are specifically listed in Annex III of the CRA and are broken down into two further sub-categories: Class I and Class II, where Class II represents the highest level of risk. We’re talking about products whose failure could disrupt critical infrastructure, threaten public safety, or trigger massive data breaches.
The criteria for a 'critical' designation are all tied to the product's core function. If your product does any of the following, it’s almost certainly going to be considered critical:
- Security Functions: This includes products like password managers, antivirus software, and virtual private networks (VPNs).
- Network Control: Think routers, modems, firewalls, and industrial switches.
- System Administration: This covers products used to manage operating systems, servers, or other high-privilege environments.
- Industrial Automation: This bucket includes industrial control systems (ICS), SCADA systems, and programmable logic controllers (PLCs) running factories and power plants.
For these high-stakes products, a self-assessment is off the table. They demand a far more stringent conformity assessment procedure that involves an external, independent auditor.
Practical Example of a 'Critical' Product:
A tech firm in Barcelona builds industrial firewalls to protect factory networks. Because this product is a core security component for critical infrastructure, it falls squarely into the 'Critical' category defined in Annex III. 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. If they place a non-compliant product on the market, they are held responsible as if they were the manufacturer 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:
- Verify the manufacturer has actually performed a conformity assessment.
- Confirm that a complete technical file exists and can be made available upon request by authorities.
- Obtain and check the EU Declaration of Conformity to ensure it is correctly filled out and signed.
- 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 at least 10 years after the product is first sold, 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): A complete inventory of all your software components, from open-source libraries to commercial modules. 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 project management tool 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 Critical products), 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. Even sooner, the obligation to report actively exploited vulnerabilities kicks in.
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.
-
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 automotive systems. -
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’ or does it fall into one of the ‘Critical’ categories (Class I or II) as defined in Annex III? 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 notifying ENISA within 24 hours of discovering an actively exploited vulnerability. 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.
-
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. -
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. This provides a clear cut-off point for legacy devices.
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. 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 minimum of five years after placing a product on the market. 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. It must provide security patches for at least five of those years. 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 mandates that an SBOM be included as part of your technical documentation. 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 provides a software platform designed to simplify CRA compliance. Our solution unifies applicability assessments, product classification, and requirements mapping, generating a tailored roadmap to help you confidently place compliant products on the EU market. Learn more about how Regulus can help your business prepare for the CRA.
