For manufacturers of connected devices, figuring out how the Cyber Resilience Act (CRA) and the Radio Equipment Directive (RED) fit together is now a critical task. The core difference is one of scope. RED’s cybersecurity rules are specific to radio equipment, while the CRA casts a much wider net, covering nearly all products with digital elements. This creates a significant overlap that demands a unified compliance strategy.
Comparing CRA and RED High-Level Requirements
For businesses placing products on the EU market, navigating the cybersecurity requirements of the CRA versus RED can feel like untangling a complex web. The Radio Equipment Directive has long governed radio-enabled products, but the Cyber Resilience Act introduces a broader, more demanding security framework that now sits alongside it.
Understanding how they interact is the first step toward building a compliant product strategy that won’t get you into trouble with market surveillance authorities.
The RED’s cybersecurity articles—specifically 3.3(d), (e), and (f)—are focused on a narrow set of risks associated with radio devices. These articles zero in on preventing network harm, protecting personal data and privacy, and ensuring safeguards against monetary fraud. For instance, this means a Bluetooth speaker must not be designed in a way that could bring down a home Wi-Fi network.
In stark contrast, the CRA establishes a horizontal framework covering the entire lifecycle of any product with digital elements (PDE). It mandates a secure-by-design approach, ongoing vulnerability management, and transparent reporting, regardless of whether the product uses radio waves. A practical example here would be a children’s toy with a simple LCD screen and a button; even without connectivity, its firmware falls under the CRA’s security requirements.
Key Differences at a Glance
The main distinction boils down to their primary focus and the breadth of their applicability. While RED is vertical and targeted, the CRA is horizontal and all-encompassing.
The simplest way to look at it is this: RED is concerned with the risks created by a product’s radio connectivity, while the CRA is concerned with the overall cybersecurity resilience of the product itself. This means many modern devices will need to comply with both.
This breakdown offers a clearer comparison of the CRA vs RED cybersecurity requirements:
| Criterion | Radio Equipment Directive (RED) | Cyber Resilience Act (CRA) |
|---|---|---|
| Primary Focus | Securing radio equipment to protect networks, personal data, and prevent fraud. | Ensuring cybersecurity for all products with digital elements across their entire lifecycle. |
| Product Scope | “Radio equipment”—products that intentionally transmit or receive radio waves. | “Products with digital elements”—any software or hardware product and its remote data processing solutions. |
| Lifecycle Stage | Primarily focused on requirements at the point of being placed on the market. | Covers the entire lifecycle from design and development to post-market support and end-of-life. |
| Security Approach | Addresses specific, defined cybersecurity objectives (Articles 3.3 d, e, f). | Mandates a holistic, secure-by-design and by-default approach with continuous vulnerability handling. |
A practical example makes this crystal clear. A new smart watch uses Bluetooth, so its radio module falls directly under RED’s jurisdiction. This means the manufacturer must ensure the Bluetooth connection doesn’t disrupt other devices and that personal data transmitted over it is protected.
However, its operating system, the companion mobile app, and how it handles user health data are all governed by the CRA’s extensive security and reporting obligations. For example, under the CRA, the manufacturer must ensure the watch ships with a secure default configuration (no “1234” PIN), has a process for delivering security updates, and provides a Software Bill of Materials (SBOM) for its app. Manufacturers must therefore prepare for both regulatory frameworks simultaneously to ensure complete and undisputed market access.
Defining Product Scope and Applicability
Figuring out which regulation applies to your product is the first hurdle in securing EU market access. The line between the Cyber Resilience Act (CRA) and the Radio Equipment Directive (RED) comes down to a product’s core function and its digital components, so a detailed scope analysis isn’t just a good idea—it’s essential.
The RED’s cybersecurity articles are aimed at a very specific category: ‘radio equipment’. This means any product that intentionally sends or receives radio waves for communication or radiodetermination. If your device uses Wi-Fi, Bluetooth, 5G, or any other radio technology, it’s in the RED’s crosshairs. A practical example is a wireless microphone system; its sole purpose involves radio waves, placing it squarely under RED.
In contrast, the CRA’s net is cast far wider. It covers all ‘products with digital elements’ (PDEs), which is almost any piece of hardware or software that can process data, unless another law specifically carves it out. For instance, a USB stick with encryption software is a PDE and falls under the CRA, even though it has no radio components. You can get into the finer details of what counts as a PDE in our deep-dive on CRA applicability.
Differentiating RED and CRA Applicability
The fundamental difference is straightforward: the RED is vertical, targeting radio-specific risks. The CRA is horizontal, setting a baseline for the general cybersecurity of all digital products. This immediately creates an overlap where a huge number of modern connected products must comply with both.
For manufacturers, the clock is ticking. The RED Delegated Act (RED-DA) becomes mandatory on 1 August 2025, forcing all new radio equipment to meet Articles 3.3(d) for network protection, 3.3(e) for personal data privacy, and 3.3(f) for fraud prevention. This single deadline affects over 80% of connected products sold in the EU. Missing it means an immediate market lockout.
This simple decision tree clarifies how to determine if the CRA or RED applies based on a product’s digital makeup.
As the diagram shows, the moment a product has any digital component, it falls under the scope of either the CRA, the RED, or—very often—both.
The key takeaway is that the CRA establishes a foundational cybersecurity layer. Even if a product satisfies the RED’s radio-specific rules, it must also meet the CRA’s broader obligations for secure design, vulnerability management, and lifecycle support if it contains digital elements.
A Practical Example: A Smart Thermostat
Let’s break it down with a common IoT device: a smart thermostat.
- RED Applicability: Its Wi-Fi module, which it uses to connect to your home network and the internet, intentionally transmits and receives radio waves. This radio function is squarely in the RED’s scope and must comply with Articles 3.3(d), (e), and (f). This means ensuring its Wi-Fi connection is stable and doesn’t hog network resources in a harmful way.
- CRA Applicability: The thermostat’s operating system, the mobile app you use to control it, its connection to a cloud backend, and the mechanism for receiving firmware updates are all ‘digital elements’. These aspects fall under the CRA’s comprehensive requirements for secure development, vulnerability handling, and providing security patches. For example, the manufacturer must have a documented process for fixing a vulnerability discovered in the thermostat’s firmware and pushing an over-the-air update to all users.
This dual-track compliance is where many manufacturers get tripped up. The table below lays out the key differences in scope to help you map your obligations.
CRA vs RED At a Glance: Scope and Applicability
| Criterion | Radio Equipment Directive (RED) | Cyber Resilience Act (CRA) |
|---|---|---|
| Product Scope | Products that intentionally transmit or receive radio waves (e.g., devices with Wi-Fi, Bluetooth, cellular). | Any product with digital components, including its hardware, software, and remote data processing functions. |
| Primary Focus | Protecting networks, personal data, and preventing fraud specifically related to the use of the radio spectrum. | Ensuring end-to-end cybersecurity resilience across the entire product lifecycle, from design to end-of-life. |
| Key Applicability | Based on the presence of a radio interface for communication or radiodetermination. | Based on the presence of any digital element, whether it’s connected to a network or not. |
Understanding this dual applicability is critical. A single product often requires two parallel compliance efforts. You can’t assume that meeting the RED’s requirements is enough if your product also qualifies as a PDE under the Cyber Resilience Act.
Comparing Core Security Requirements
Once you get past the question of which regulation applies, the real work begins: understanding the specific security obligations each one imposes. The difference between the CRA and RED isn’t just in scope; it’s in their entire security philosophy.
The Radio Equipment Directive’s cybersecurity articles—3.3(d), (e), and (f)—are highly targeted. They focus on concrete outcomes: preventing network disruption, protecting personal data, and safeguarding against payment fraud. They define what a product must not do. For example, under 3.3(f), a connected point-of-sale terminal must incorporate features that prevent fraudulent payment transactions.
In contrast, the Cyber Resilience Act mandates a comprehensive, end-to-end security framework. It’s not just about preventing specific harms but about building and maintaining a resilient product from the ground up, covering the entire lifecycle. For that same point-of-sale terminal, the CRA would require the manufacturer to follow a secure coding process and provide security patches for its operating system for at least five years.
Secure by Design and by Default
A core principle of the CRA is that products must be secure by design and by default. This isn’t just a suggestion; it’s a legal mandate that makes security a foundational part of product development, not an afterthought.
In practice, this means manufacturers must integrate security from the earliest design phase. Key requirements include:
- Shipping products with secure default configurations, meaning no more universal “admin” passwords. For example, a new router must force the user to create a unique password during setup instead of using a default like “password123”.
- Minimising the attack surface by shipping with only essential functions and ports enabled. A smart TV, for instance, should have developer-mode ports disabled by default.
- Ensuring data is protected both at rest and in transit using appropriate encryption. A fitness tracker must encrypt the health data it stores on the device and when it syncs with a mobile app.
The RED doesn’t explicitly mandate a “secure by design” philosophy. Its requirements are more focused on the product’s final state when placed on the market. For example, a RED-compliant device must not harm the network, but the regulation is far less prescriptive about how a manufacturer achieves this during development.
Lifecycle Security From Development to Post-Market
This is where the CRA and RED diverge most sharply. The CRA’s obligations stretch far beyond the point of sale, demanding a formalised Secure Development Lifecycle (SDL). Implementing robust secure software development best practices becomes a non-negotiable part of compliance, involving activities like threat modelling, code reviews, and penetration testing.
You can dive deeper into these steps in our complete guide to building a CRA-compliant Secure Development Lifecycle (SDL).
Let’s take a connected security camera as an example:
- Under RED: The camera’s Wi-Fi module must not cause interference or disrupt networks. It also needs basic safeguards for the personal data it transmits (like the video stream).
- Under the CRA: The manufacturer must also prove it followed a secure development process. This means conducting threat modeling to identify potential attacks (like hijacking the video feed), performing code analysis to find bugs, and ensuring the camera can be securely updated. The camera has to ship without known exploitable vulnerabilities, feature a secure and reliable update mechanism, encrypt stored video footage, and be delivered without a default password like “1234.”
The CRA effectively codifies lifecycle security as a legal requirement. It transforms security from a static, pre-market check into a continuous, dynamic process of vigilance and maintenance.
Vulnerability Handling and SBOMs
The CRA’s detailed requirements for vulnerability handling and supply chain transparency are another major differentiator. The Act requires manufacturers to have a structured, public process for receiving and addressing vulnerability reports from security researchers and users.
More importantly, the CRA mandates the creation and provision of a Software Bill of Materials (SBOM)—a formal, machine-readable inventory of all software components and dependencies in a product. This is a direct response to the massive impact of supply chain attacks, where a single flaw in an open-source library can compromise thousands of downstream products. A practical example is a manufacturer of a smart fridge providing a list that shows it uses a specific version of the OpenSSL library for encryption, allowing customers to track vulnerabilities associated with that library.
While the harmonised standard EN 18031, which supports RED, mentions the need for an SBOM to monitor vulnerabilities, the CRA elevates it to a mandatory legal obligation. The contrast is stark:
| Security Requirement | Radio Equipment Directive (RED) | Cyber Resilience Act (CRA) |
|---|---|---|
| Development Process | Not explicitly defined; focused on product outcomes. | Mandates a formal Secure Development Lifecycle (SDL). |
| Default Configuration | Implied for protecting data and networks. | Explicitly required to be “secure by default.” |
| Vulnerability Handling | Implied; must fix known exploitable vulnerabilities. | Mandatory, structured process for disclosure and management. |
| SBOM | Recommended by supporting standards (EN 18031). | Mandatory legal requirement for all covered products. |
This means that while a RED-compliant product might need patching if a public vulnerability is found, the CRA demands that the manufacturer have the entire infrastructure in place to proactively find, receive reports on, manage, and fix vulnerabilities throughout the product’s entire supported lifetime. A product’s cybersecurity obligations don’t simply vanish once it hits the market. This post-market phase is precisely where the differences between the CRA and RED become most stark. While the Radio Equipment Directive (RED) implies a need for ongoing security, the Cyber Resilience Act (CRA) makes it an explicit, legally binding responsibility.
The CRA fundamentally shifts the manufacturer’s role from passive observer to active guardian of a product’s security. It formalises the duty to maintain a strong security posture long after the initial sale, demanding a major operational overhaul for many organisations.
Security Updates and Product Lifecycles
One of the most significant mandates from the CRA is the provision of free and timely security updates. Manufacturers must supply patches for a product’s expected lifetime or, at a minimum, for five years after it is first placed on the market. This rule is designed to prevent products from becoming insecure liabilities over time. For example, a smart TV sold in 2026 must receive security patches for its operating system until at least 2031, free of charge.
For RED, the obligation is far less direct. A manufacturer must address known exploitable vulnerabilities to keep a product compliant, but the directive never specifies a minimum support period or mandates that updates must be free. The CRA closes this regulatory gap, making long-term support a non-negotiable condition for EU market access.
This heightened awareness of lifecycle duties is forcing urgent action. While RED awareness in the EU’s ‘ES’ region was a high 60% in 2023, awareness of the CRA’s deeper implications shot up from just 20% to 45% in a single year. Projections show CRA awareness will likely hit 70% by 2025, a rise driven almost entirely by its demanding lifecycle requirements. You can discover more insights about these trends and what they mean for the future on cclab.com.
Vulnerability Reporting and Coordinated Disclosure
This is where the CRA imposes a significant operational burden compared to the RED. The CRA requires a structured, transparent, and audited process for both receiving and handling vulnerability reports from external sources, like security researchers.
The CRA’s 24-hour reporting rule for actively exploited vulnerabilities is a game-changer. It forces manufacturers to have a well-oiled incident response machine ready to act at a moment’s notice, transforming vulnerability management from a background task into a critical, time-sensitive function.
Under the CRA, if a manufacturer confirms a vulnerability is being actively exploited, they have a strict 24-hour window to report it to ENISA (the European Union Agency for Cybersecurity). This is a world apart from the RED, which has no equivalent time-bound reporting mandate.
Consider a real-world scenario:
- The Situation: A smart door lock manufacturer discovers a critical firmware flaw that hackers are actively using to gain unauthorised entry.
- Under RED: The manufacturer would need to develop and issue a patch to maintain compliance, but there are no specific rules on how or when to notify authorities.
- Under the CRA: The manufacturer must not only create and deploy a patch but also notify ENISA of the actively exploited vulnerability within 24 hours. They are also obligated to inform their users about the threat and the available fix without undue delay.
This single requirement fundamentally changes how companies must prepare for security incidents. If you’re looking for more detail, you can learn more about the specific CRA reporting obligations and what they mean for your team. Building this proactive security posture requires a serious investment in both processes and people.
Navigating Conformity Assessment and Documentation
Proving compliance is just as important as achieving it, and this is where the paths for the Cyber Resilience Act (CRA) and the Radio Equipment Directive (RED) really start to split. The formal processes for declaring a product compliant—what we call conformity assessment—and the technical files needed to back up that claim are worlds apart.
For years, manufacturers of products under RED have had a relatively straightforward path. Most could perform a self-assessment, meaning they could internally check their product against Articles 3.3(d), (e), and (f), compile the technical file, and slap on the CE mark with their own Declaration of Conformity. For example, a maker of consumer Bluetooth headphones could conduct its own tests to verify compliance.
The CRA throws a spanner in those works. It brings in a more rigorous, risk-based model that completely changes the game.
The CRA’s Risk-Based Assessment Model
While the CRA does allow self-assessment for many products, it carves them up by risk level, creating entirely different routes to conformity. This adds a layer of complexity that just doesn’t exist in RED’s one-size-fits-all approach.
Products are now sorted into these categories:
- Default Risk Products: This is the bucket for the vast majority of consumer electronics and software. For a simple fitness tracker, manufacturers can stick with an internal control procedure (Module A), which feels a lot like the old RED self-assessment.
- Critical Class I Products: These are higher-risk products, all listed out in Annex III of the CRA. Examples include home automation controllers or network management systems. They often demand a third-party Notified Body to get involved, unless the manufacturer follows the relevant harmonised standards to the letter.
- Critical Class II Products: For the highest-risk gear, like hardware security modules (HSMs) or smart card readers, there’s no way around it. These products must undergo a third-party conformity assessment by a Notified Body. No exceptions.
This tiered system means a manufacturer’s journey to the CE mark can look drastically different from one product to the next.
The shift from RED’s broad self-assessment model to the CRA’s risk-based conformity paths is one of the biggest operational hurdles for manufacturers. A product that was previously self-declared for RED may now face costly and time-consuming third-party audits under the CRA.
Comparing Documentation Requirements
The difference in approach bleeds directly into the paperwork. The technical documentation needed for CRA versus RED cybersecurity requirements are night and day in terms of the detail you’ll have to provide. When it’s time to document your security controls, resources like a practical SOC 2 compliance checklist can offer a good structural starting point for demonstrating proof of compliance.
A RED technical file is pretty focused. It’s all about proving compliance with its specific articles, and usually includes:
- Test reports showing the product doesn’t mess with communication networks.
- Proof of safeguards for personal data and privacy.
- Paperwork on measures taken to stop monetary fraud.
The CRA’s technical file, on the other hand, is a much heavier lift. It needs to tell the complete, transparent story of your product’s entire security posture and lifecycle management. Key elements must now include evidence of a secure development lifecycle, detailed vulnerability management procedures, and a full Software Bill of Materials (SBOM). If you need to dig into the nuts and bolts of this new process, you can find more detail on the CRA conformity assessment procedures.
A Practical Example: A Home Automation Gateway
Let’s think about a smart home gateway—the kind that controls your locks, lights, and cameras.
Under RED, the manufacturer could simply self-declare its Wi-Fi and Zigbee radios as compliant. The technical file would centre on radio performance and the basic security measures tied to Article 3.3.
Now, under the CRA, this very same product gets classified as ‘Critical Class I’. Suddenly, the compliance path is a much steeper climb. The manufacturer now must:
- Bring in a Notified Body for a third-party conformity assessment (unless they perfectly implement harmonised standards).
- Put together an exhaustive CRA technical file that proves a secure development process was followed from start to finish. This would include evidence like threat modeling diagrams and penetration test reports.
- Include a detailed SBOM listing every single firmware and software component, from the operating system kernel to the open-source libraries used in its web interface.
- Document the entire process for handling and reporting vulnerabilities post-launch, including the contact point for security researchers.
This comparison really drives home how the CRA fundamentally raises the burden of proof. It moves the goalposts from a focused, self-managed process under RED to a comprehensive, often externally-audited system for any product the EU considers critical.
Building Your Unified Compliance Roadmap for 2026
With deadlines for both the RED Delegated Act and the Cyber Resilience Act looming, a unified compliance strategy has moved from a good idea to an absolute necessity. The key is to turn regulatory uncertainty into a structured, step-by-step plan.
This roadmap breaks down the complex comparison of CRA vs. RED cybersecurity requirements into a series of manageable actions.
Following this plan is your best bet for placing products on the EU market confidently, without staring down the barrel of costly delays or penalties.
Phase 1: Portfolio Assessment
Your first job is to get a complete, honest picture of your product portfolio. You need to map out precisely which products fall under the RED, which fall under the CRA, and—most commonly—which are caught by both.
Take a company that makes smart lighting systems and industrial sensors. Their Wi-Fi-enabled smart lights are clearly subject to both RED and CRA. The wired industrial sensors, however, only fall under the CRA, as they have digital elements but no radio interface. This initial inventory is the foundation for everything that follows.
Phase 2: Gap Analysis
Once you know which regulations apply to which products, you have to benchmark your current security practices against what RED and the CRA demand. Use the latest harmonised standards, like EN 18031 for RED, to pinpoint exactly where your processes fall short.
This analysis must cover your entire process, from your Secure Development Lifecycle (SDL) all the way to your post-market vulnerability handling. For example, a practical step is to review your current product development handbook and see if it includes mandatory security checkpoints like threat modeling or static code analysis. If not, that’s a major gap. The goal is to walk away with a concrete list of deficiencies that need fixing to satisfy both regulations.
A thorough gap analysis is what separates the prepared from the panicked. It turns dense regulatory text into a practical to-do list, showing you exactly where to invest your resources for maximum impact before the 2026 and 2027 deadlines hit.
For example, you might find your development team doesn’t have a formal threat modelling process, a non-negotiable part of the CRA’s secure-by-design mandate. Or you might realise your RED-focused vulnerability response plan can’t meet the CRA’s strict 24-hour reporting window for actively exploited flaws.
Phase 3: Product Classification
With your list of CRA-applicable products in hand, the next critical step is to determine their risk classification. This is a major fork in the road because it dictates your entire conformity assessment path.
You have to categorise each product into one of two buckets:
- ‘Default’ Risk: The vast majority of products will land here. These can go through an internal self-assessment.
- ‘Critical’ Risk (Class I or II): These products, which are listed in Annex III of the CRA, demand a third-party assessment from a Notified Body.
A smart speaker might be deemed ‘Critical’, forcing you into expensive third-party audits. In contrast, a simple connected toothbrush would almost certainly be ‘Default’. Getting this wrong can invalidate your CE marking and lead to a forced market withdrawal.
Phase 4: Process Implementation and Documentation
This is where the plan becomes action. Using your gap analysis as a guide, you must establish and formalise the required procedures. This means implementing a robust SDL, creating a public-facing vulnerability disclosure policy, and setting up an incident response team that can meet ENISA’s reporting timelines. A practical first step could be to create a “security@company.com” email address and a documented procedure for how incoming reports are triaged, verified, and escalated.
At the same time, you need to start compiling the mountain of technical documentation required by both regulations. Begin gathering your Software Bill of Materials (SBOM), evidence from security testing, and the detailed justifications for your risk assessments. Assembling this documentation proactively is the key to a smooth conformity assessment and makes you ready for any inspection by market surveillance authorities.
Frequently Asked Questions About CRA and RED
When comparing the Cyber Resilience Act and the Radio Equipment Directive, manufacturers often run into the same critical questions. Here are the clear, operational answers you need.
If My Product Is RED Compliant, Do I Need to Worry About the CRA?
Yes, without a doubt. Achieving compliance with RED Articles 3.3(d), (e), and (f) is a necessary step, but it’s only a starting point. The CRA introduces a completely new set of obligations that span the entire product lifecycle, areas the RED simply doesn’t cover.
Think of it this way: your smart home hub’s RED compliance ensures its radio functions correctly and doesn’t interfere with other networks. The CRA, however, governs the security of its operating system, mandates it ships without guessable default passwords, and requires you to provide security updates for a minimum of five years. Your RED assessment is a foundation, but it must be supplemented with a full CRA assessment.
RED compliance covers specific, point-in-time radio security risks. The CRA demands continuous cybersecurity resilience for the entire product and its software components. One does not replace the other.
What Is the Difference Between a Default and a Critical Product Under the CRA?
The CRA classifies products into risk-based tiers, and the main difference is how you prove conformity.
- ‘Default’ products are the standard classification, covering the vast majority of consumer electronics and software. For these, manufacturers can typically perform a self-assessment against harmonised standards. A video game or a photo editing software would be a clear example.
- ‘Critical’ products (split into Class I and Class II) carry higher security implications. Think industrial controllers, network hardware, or home assistants with privileged access. These products demand a more rigorous conformity assessment, which almost always involves a third-party Notified Body.
A connected toothbrush is a perfect example of a ‘Default’ product. In contrast, a networked industrial pump controller that could impact critical infrastructure would almost certainly be classified as ‘Critical’, mandating a costly and time-consuming external audit before it can receive its CE mark.
How Can I Prepare for Both RED and CRA Deadlines Effectively?
The most effective strategy is to treat compliance as a single, unified project and start immediately. Use the nearer RED deadline as a catalyst to build foundational security practices that will also satisfy your future CRA obligations.
Your first move should be a gap analysis against harmonised standards that bridge both regulations. From there, focus on implementing a Secure Development Lifecycle (SDL) and establishing a formal, documented vulnerability management process. For example, start by generating an SBOM for one of your flagship products using an open-source tool. This practical exercise will reveal supply chain risks and prepare you for the CRA’s mandatory SBOM requirement. This approach breaks the monumental task into a manageable, step-by-step plan, ensuring you meet the RED deadline while being well-prepared for full CRA enforcement.
Navigating these complex regulations can be daunting. Regulus provides a clear path forward, generating a tailored requirements matrix and ready-to-use templates to streamline your CRA compliance journey. Gain clarity and confidently place your products on the EU market by visiting https://goregulus.com.
