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:

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

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:

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:

1. Bring in a Notified Body for a third-party conformity assessment (unless they perfectly implement harmonised standards).
2. 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.
3. 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.
4. 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.

La entrada CRA vs RED Cybersecurity Requirements: A Clear Comparison for 2026 se publicó primero en Regulus.

The core difference boils down to what each piece of legislation protects. NIS2 is about securing the operational continuity of essential services—think energy grids, banks, and digital infrastructure. The CRA, however, focuses on securing the digital products themselves, like software and connected devices.

Untangling EU Cybersecurity: The CRA vs. NIS2

While both the CRA and NIS2 aim for a more secure digital Europe, they don’t overlap as much as you might think. They are complementary, tackling cybersecurity from opposite ends of the spectrum: one focuses on the organisations providing critical services, the other on the manufacturers building the products those organisations use.

The NIS2 Directive: Securing Critical Service Operations

The NIS2 Directive is all about the resilience of organisations that are vital to our economy and society. It imposes strict security and reporting obligations on entities in sectors like healthcare, transport, and finance to ensure they can withstand and recover from cyber incidents.

For example, a large Spanish hospital is designated an ‘Essential’ entity under NIS2. This means its management team is legally responsible for implementing risk management measures like multi-factor authentication, training staff on phishing, and reporting significant service disruptions (like a ransomware attack taking its patient system offline) to national authorities. NIS2 is concerned with how the hospital operates securely day-to-day.

The Cyber Resilience Act (CRA): Securing Products by Design

In contrast, the Cyber Resilience Act (CRA) is a regulation targeting the security of “products with digital elements.” This covers a huge range of tangible and intangible goods, from smart home devices and industrial controllers to standalone software. If you manufacture, import, or distribute a connected product for the EU market, the CRA applies to you.

To understand how it works in practice, let’s go back to that Spanish hospital. The manufacturer of a networked medical imaging machine used by the hospital must comply with the CRA. This means designing the machine to be secure from the ground up (e.g., no default passwords), providing security updates for its entire lifecycle, and reporting actively exploited vulnerabilities within 24 hours. The CRA is about ensuring the product itself is secure by design and remains so over time. For more background, you can learn about the Cyber Resilience Act in our detailed guide.

The core distinction is clear: NIS2 compels service providers to maintain robust cyber defences for their operations, while the CRA forces product manufacturers to build and maintain secure products throughout their lifecycle.

Core Differences Between CRA and NIS2 at a Glance

This table offers a high-level summary of the key distinctions between the two frameworks, highlighting their different targets, objectives, and scope.

Ultimately, an organisation might fall under both. A cloud provider, for instance, is an ‘Important’ entity under NIS2 and must secure its operations. If it also develops software that customers install (like a desktop sync client), that software product would need to comply with the CRA. The two regulations work in tandem to secure both the services we rely on and the products that power them.

Determining Your Scope and Applicability

Figuring out where you stand with the CRA and NIS2 starts with one crucial question: does your organisation make something, or does it do something? This is the fundamental difference in logic between the two frameworks, creating separate paths for product manufacturers and service providers.

This simple decision tree gets right to the point. Are you providing a service in a critical sector, or are you building a digital product for the market?

As you can see, NIS2 targets the operators of essential and important services. The CRA, on the other hand, zeroes in on the manufacturers of the very products those operators might be using.

How NIS2 Defines Its Scope

The NIS2 Directive identifies entities based on two straightforward criteria: their sector and their size. It lays out explicit lists of 18 sectors, splitting them into ‘Essential’ and ‘Important’ categories.

• Essential Entities: This covers the big ones—organisations in energy, transport, banking, health, and digital infrastructure.
• Important Entities: This category includes other vital sectors like postal services, waste management, and the manufacturing of certain critical goods.

Beyond the sector, NIS2 applies a simple size-cap rule. The directive generally targets medium and large organisations, which means those with over 50 employees or an annual turnover exceeding €10 million. For a practical example, a small, family-owned logistics company with 20 employees would likely be exempt, but a large national postal service falls squarely within the scope as an ‘Important’ entity.

The CRA’s Product-Focused Approach

The Cyber Resilience Act (CRA) comes at this from a completely different angle. It applies horizontally to nearly all ‘products with digital elements’ placed on the EU market. This is a massive net, catching everything from hardware like IoT devices to software like operating systems or mobile apps.

Crucially, the CRA’s applicability has no company size or revenue threshold. A two-person startup in a garage developing a smart thermostat app is just as subject to CRA rules as a multinational corporation building enterprise software. If you make it and sell it in the EU, the CRA applies.

This product-centric versus service-centric divide creates some very clear lines. Take a large German hospital, for instance. It’s an ‘Essential’ entity under NIS2 and is responsible for its own operational cybersecurity. But the manufacturer of the networked infusion pumps that hospital uses? They must comply with the CRA to ensure the pumps themselves are secure by design. You can dig deeper into these specifics by exploring our guide on Cyber Resilience Act applicability.

This distinction is especially sharp in markets like Spain, where regulatory alignment is vital for market access. While NIS2 targets an estimated 1,200 entities in Spain’s key service sectors, the CRA’s universal approach impacts a much broader base. It directly affects the country’s 45,000+ IoT-related enterprises, from multinationals down to the smallest startups, all of which now face immediate product security obligations and must prepare for CE marking requirements by 2027.

Whether your obligations fall under the CRA, NIS2, or both, the first step is always understanding your assets and risks. Using a comprehensive cybersecurity risk assessment checklist is a solid starting point for building out your compliance strategy.

Understanding Your Reporting Obligations and Timelines

When an incident strikes, the clock starts ticking. One of the most significant differences between the CRA and NIS2 is what triggers that clock and how you must respond. These reporting timelines aren’t just procedural details; they define your organisation’s response under pressure and shape your entire incident management strategy.

At a high level, NIS2 is reactive to service disruptions, while the CRA is proactive about product vulnerabilities. For a practical example, think of a major cloud provider, an ‘Essential Entity’ under NIS2, suffering a widespread outage that takes its customers offline. NIS2 gives them 24 hours to submit an ‘early warning’ to their national Computer Security Incident Response Team (CSIRT). This is then followed by a more detailed incident notification within 72 hours.

The CRA’s timeline, however, is triggered by a completely different event.

Different Triggers for the 24-Hour Clock

The CRA’s focus is squarely on product security, specifically when a flaw becomes an active threat. For a manufacturer, the 24-hour reporting duty begins the moment they become aware of an actively exploited vulnerability within their product. This is a critical distinction from NIS2.

Let’s take a practical example. A company manufacturing smart thermostats discovers a flaw in their firmware that attackers are actively using to gain control of devices and join them to a botnet. Under the CRA, they must notify ENISA (the EU Agency for Cybersecurity) and their national CSIRT within 24 hours. The report is about the vulnerability itself, not necessarily any resulting service disruption. We cover this in more detail in our overview of CRA reporting obligations under Article 14.

Key Takeaway: For NIS2, the trigger is a significant incident affecting service continuity. For the CRA, it’s the discovery of an actively exploited vulnerability in a product, demanding rapid, coordinated disclosure to prevent widespread harm.

This difference in triggers really highlights how the two frameworks complement each other. The CRA pushes manufacturers to report and fix exploitable flaws before they can be used to cause the large-scale service disruptions that would then trigger NIS2 reporting.

A Practical Comparison of Reporting Timelines

Getting the reporting timelines right is a common point of confusion, so let’s break down the practical differences. The table below highlights the key differences in what triggers a report, how quickly you must act, and who you need to inform.

CRA vs NIS2 Reporting Requirements At A Glance

While both mandates have a 24-hour deadline, the substance of the report and the required follow-up steps are quite different. As you work to define your incident response plans, it’s also helpful to be aware of global best practices and specific regional requirements, such as those related to cybersecurity incident reporting obligations.

Ultimately, these distinct triggers and timelines require tailored workflows. A product security team must have a process ready for the CRA’s exploited-vulnerability trigger, which is fundamentally different from the broader service-outage focus of NIS2.

Comparing Compliance Paths and Enforcement Penalties

The path to proving compliance—and the penalties for getting it wrong—is where the CRA and NIS2 diverge most sharply. How you demonstrate your security posture is entirely different under each framework.

NIS2 relies on national oversight of your internal processes. The CRA, on the other hand, uses an established EU-wide product conformity framework. Getting this distinction right is critical.

The NIS2 Path: Proving Internal Resilience

For NIS2, the journey is internal and process-driven. As a directive, it is transposed into national law, meaning each Member State enforces it through its own authorities. Compliance means demonstrating robust internal governance, conducting regular risk assessments, and proving board-level accountability.

Under NIS2, an organisation proves compliance by showing, not just telling. National authorities will conduct audits and demand evidence that your security measures are actually in place and working.

Take a large logistics company in Spain, classified as an ‘Important’ entity. Its compliance path would involve:

• Developing and maintaining a comprehensive risk management policy.
• Conducting annual security audits performed by an independent third party.
• Running mandatory training programmes for all employees on cybersecurity hygiene.
• Demonstrating to national auditors that its board of directors has formally approved and oversees its cybersecurity strategy.

Failure to meet these obligations can bring significant fines from national authorities, reaching up to €10 million or 2% of the company’s total global annual turnover, whichever is higher.

The CRA Path: Proving Product Security via CE Marking

The Cyber Resilience Act, as a regulation, is directly applicable across the entire EU without national transposition. It cleverly piggybacks on the well-established New Legislative Framework (NLF), using the CE marking process as its compliance mechanism. This applies a familiar product-safety process to the world of cybersecurity.

The CRA essentially says, “If your product has a digital element, its cybersecurity is now a matter of public safety, just like its electrical or mechanical safety.” It must earn its CE mark by proving it is cyber-resilient.

For a manufacturer, this creates a clear, product-focused path:

1. Conduct a Conformity Assessment: The manufacturer assesses the product against the CRA’s security requirements. For most products, this can be a self-assessment, but higher-risk products demand a third-party notified body.
2. Create Technical Documentation: This file must contain everything from the risk assessment and a Software Bill of Materials (SBOM) to evidence of a secure development lifecycle.
3. Issue an EU Declaration of Conformity: The manufacturer formally declares that the product meets all CRA requirements.
4. Affix the CE Mark: Only then can the product be legally placed on the EU market.

This compliance and enforcement model has huge implications for Spain’s digital product teams. While NIS2 impacts around 8,000 important entities in Spain through nationally transposed laws, the CRA directly hits Spain’s 30,000+ software and firmware makers with its CE marking mandate, completely bypassing company size thresholds.

Enforcement also diverges sharply. CRA violations are policed by Market Surveillance Authorities who can order product recalls and impose EU-wide fines of up to €15 million or 2.5% of global annual turnover—potentially exceeding NIS2 penalties. You can discover more insights about these contrasting frameworks on holmsecurity.com.

For instance, a French company developing a smart home security camera must create a full technical file, prove it has a process to deliver security updates for at least five years, and then affix the CE mark. If a Market Surveillance Authority in Germany later finds the product non-compliant, it can be pulled from shelves across all 27 EU member states.

Navigating the Intersection of CRA and NIS2

Although the Cyber Resilience Act (CRA) and the NIS2 Directive target different things—products versus services—they are not independent. The two frameworks were designed to be complementary, creating a strong, interlocking set of security obligations that reinforce one another across the EU market.

For organisations caught in the middle, understanding this intersection is essential for managing dual obligations and turning complex compliance work into a clear market advantage.

The most important point of overlap is supply chain security. Under NIS2, critical entities have a legal duty to secure their supply chains. The CRA, in turn, provides the very mechanism for them to do just that.

The NIS2 Demand for CRA-Compliant Products

NIS2 forces Essential and Important entities to meticulously vet the security of their suppliers. This single requirement transforms CRA compliance from a manufacturer’s internal problem into a key procurement criterion for a huge market of critical service providers.

Take a practical example: a large Spanish power plant, an ‘Essential’ entity under NIS2, must verify the cybersecurity of its operational technology. When its procurement team needs a new industrial control system (ICS), they won’t just evaluate performance and price; they will demand proof of security.

The manufacturer of that ICS falls directly under the CRA. They are obligated to:

• Build the ICS according to secure-by-design principles.
• Provide a Software Bill of Materials (SBOM) listing all its software components.
• Commit to providing security updates for a defined support period.
• Affix the CE mark as proof of CRA conformity.

This creates an incredibly powerful market dynamic. The power plant will use the manufacturer’s CRA compliance—proven by the CE mark and technical documentation—to fulfil its own NIS2 supply chain security obligations. In practice, NIS2 entities will become major drivers of CRA adoption, creating a strong market preference for CRA-compliant products.

The intersection creates a clear value chain: NIS2 entities must manage supply chain risk, and they will do so by demanding CRA-compliant products. For manufacturers, CRA compliance is no longer just a regulatory hurdle; it’s a market access key.

When One Organisation Has Dual Obligations

Another critical scenario involves organisations that are simultaneously NIS2 entities and CRA manufacturers. This is especially common for digital service providers, particularly Software-as-a-Service (SaaS) companies.

Think about a cloud-based electronic health record (EHR) provider based in Germany. This company is both:

• An ‘Essential’ NIS2 entity because it provides a critical service to the healthcare sector.
• A ‘manufacturer’ under the CRA because it develops and commercialises the EHR software product.

Here, a single security event can trigger obligations under both frameworks. Imagine the company’s security team discovers an unpatched, actively exploited vulnerability in the EHR software’s code that allows unauthorized access to patient data.

1. CRA Obligation Triggered: Because the flaw is actively exploited, the provider must notify ENISA within 24 hours, as required by the CRA.
2. NIS2 Obligation Triggered: If this same vulnerability causes a data breach or service disruption for its hospital clients, it becomes a ‘significant incident’. This triggers the 24-hour early warning and 72-hour detailed incident report required by NIS2.

This dual-trigger scenario shows why a unified compliance strategy is non-negotiable. For organisations in this position, managing product vulnerabilities and operational incidents are two sides of the same coin. The European Commission has provided guidance on this topic, and you can learn more about how to prepare from our analysis of CRA implementation guidance. Ultimately, successfully navigating these overlapping requirements demands a clear understanding of both your role as a service provider and your responsibilities as a product manufacturer.

Developing a Unified Compliance Strategy

Trying to manage CRA and NIS2 requirements with separate spreadsheets and disconnected processes is a recipe for duplicated work. A unified strategy is the only practical way forward, helping you treat both regulations as a single, interlocking compliance challenge instead of two separate problems.

This approach starts with a clear mapping of your obligations. A guided applicability assessment, for example, can immediately clarify whether the CRA, NIS2, or both apply to your products and your customers, giving you a solid starting point.

From Rules to a Roadmap

Once you’ve established applicability, the next step is translating dense legal text into a concrete plan of action. This means generating a requirements matrix based on your product’s specific classification—whether it falls under the default rules or a higher-risk class. This matrix should map specific obligations from the CRA Annexes and give you actionable templates.

For instance, if you manufacture a smart home router, a unified platform can generate a checklist covering:

• Annex I Security Requirements: Specific secure-by-design principles you must implement, like ensuring encrypted communication and having a secure update mechanism.
• Vulnerability Handling Processes: Templates for documenting how you will manage and report discovered vulnerabilities.
• Technical Documentation: A structured outline for your EU Declaration of Conformity and the supporting evidence files.

This turns vague regulations into a concrete roadmap for achieving compliance by the 2026–2027 deadlines.

By centralising documentation, managing vulnerability disclosures, and tracking supplier compliance in one place, you can build a single, efficient programme that satisfies both product and service security demands, ensuring you can confidently serve the EU market.

An Integrated Compliance Example

Consider a SaaS company that provides logistics software to large shipping companies. This company faces dual obligations:

• As a NIS2 ‘Important’ entity: It must secure its own operations and service delivery.
• As a CRA ‘manufacturer’: Its software product must meet CRA’s security-by-design and lifecycle requirements.

Instead of running two parallel compliance projects, a unified approach allows them to use the same evidence for both. The secure software development lifecycle (SSDLC) process documented for CRA compliance also serves as proof of a key risk management measure required under NIS2.

Likewise, the vulnerability disclosure process mandated by the CRA becomes a core component of their NIS2 incident response plan. When a single platform like Regulus manages both the product-level requirements (CRA) and the operational security evidence (for their NIS2 customers), the company avoids duplicating effort. This not only reduces costs but also builds a more robust and defensible security posture across the board. The key is to see the CRA vs NIS2 differences not as a conflict, but as an opportunity for integrated efficiency.

Frequently Asked Questions About CRA and NIS2

The relationship between the Cyber Resilience Act and the NIS2 Directive often creates confusion, especially where their obligations seem to overlap. Here are some straightforward answers to the most common questions we hear from manufacturers and digital service providers.

If My Product Is CRA Compliant, Do I Still Need to Worry About NIS2?

Yes, absolutely. Think of it this way: CRA compliance is about the security of your product. NIS2 is about the operational security of the entity using it.

For a practical example, if you sell your CRA-compliant product to a hospital (an ‘Essential’ entity under NIS2), they have their own separate obligations. Specifically, they must manage their supply chain risks. Your CRA compliance—proven by your CE mark and technical documentation—becomes a critical piece of evidence they will need from you to meet their regulatory requirements. Your job is to provide the secure product; their job is to use it securely as part of their broader operations.

Can I Be Fined Under Both CRA and NIS2 for the Same Event?

It is possible, particularly if you are a dual-status organization. Imagine you’re a SaaS provider for the banking sector. A severe security flaw in your software would be a clear CRA violation. If that flaw leads to a major service disruption that prevents customers from accessing their accounts, that disruption could be classed as an NIS2 incident.

Because the two regulations address different failures—the insecure product (CRA) and the disrupted service (NIS2)—you could theoretically face penalties under both for a single root cause.

Which Regulation Has Stricter Penalties?

On paper, the CRA has higher maximum financial penalties. Fines can reach up to €15 million or 2.5% of global annual turnover, whichever is greater.

NIS2 penalties are capped slightly lower, at €10 million or 2% of turnover. However, focusing only on the numbers is a mistake. Both regulations grant authorities serious enforcement powers, from ordering product recalls (CRA) to issuing legally binding instructions (NIS2).

Key Takeaway: While the CRA’s fines are nominally higher, the enforcement powers under both regulations are severe and designed to compel compliance. The biggest risk isn’t just the fine; it’s the operational chaos from a product recall or a binding order from a supervisory authority.

What Is the Most Significant Difference for a Product Manufacturer?

For a product manufacturer, the biggest difference lies in the compliance mechanism itself. The CRA mandates compliance through the EU’s established CE marking framework. This means you must conduct a conformity assessment, compile a comprehensive technical file with a Software Bill of Materials (SBOM), and physically affix the CE mark to your product before it can be legally sold in the EU.

NIS2, on the other hand, is primarily about internal processes, risk management, and governance. These obligations fall mainly on your customers (the service providers), not directly on you as the manufacturer, though they will push those requirements down to you via their procurement process.

Navigating CRA and NIS2 requires a clear, actionable plan. Regulus provides a guided platform to assess your applicability, map requirements, and generate the evidence needed for CRA compliance. Gain clarity on your obligations and build your roadmap today.

La entrada CRA vs NIS2 Differences A Guide to EU Cyber Compliance in 2026 se publicó primero en Regulus.

Understanding Your Core CRA Update Obligations

The Cyber Resilience Act isn’t just another box-ticking exercise. It fundamentally changes how you must manage product security long after a sale is made, shifting security support from a customer service perk to a core compliance mandate. This has serious implications for your budgeting, engineering resources, and long-term product strategy.

At its heart, the CRA establishes a legally binding minimum security support window. For any product with digital elements you place on the EU market, you are obligated to provide security updates for a minimum of five years.

For instance, if your company launches a new smart home hub in June 2027, your team must be prepared to actively develop and deploy security patches for it until at least June 2032. This isn’t about shipping new features; it’s a firm commitment to patch discovered vulnerabilities for that entire period.

Your security update and EOL policy is where you make this commitment transparent and formal. Below is a summary of the key elements your policy must contain to align with CRA expectations.

CRA Security Update Policy Key Elements

This table covers the non-negotiables. Building your policy around these components ensures you’re not just compliant on paper but also ready to execute when a vulnerability is found.

Defining the Five-Year Support Window

The five-year clock starts the moment a product is “placed on the market.” This is a legally binding obligation that went into force on 10 December 2024, with its main requirements becoming applicable from 11 December 2027. Article 13 of the CRA is clear: manufacturers must handle vulnerabilities effectively throughout the support period, and patches must be provided “without delay.”

So, if you place a product on the EU market in 2028, you must maintain an active security update infrastructure for it until at least 2033. It’s a simple rule with complex operational consequences.

Beyond the Five-Year Minimum

Don’t get too comfortable with the five-year rule. It’s a floor, not a ceiling. The CRA requires the support period to align with the product’s expected lifetime and reasonable user expectations. This is where you need to apply some critical judgement.

A key takeaway is that the ‘expected product lifetime’ isn’t determined by your marketing department, but by a realistic assessment of how long a consumer or business will actually use the device.

Let’s look at a few real-world scenarios:

• Smart Thermostat: A consumer who has a smart thermostat professionally installed in their home will reasonably expect it to function securely for seven to ten years, not just five.
• Industrial PLC (Programmable Logic Controller): In a factory, these controllers often have operational lifespans of 15 years or more. A five-year security policy here would be seen as grossly insufficient and non-compliant.
• Consumer Drone: Given the rapid pace of technological change and the likelihood of physical wear and tear, a five-year support window might be perfectly reasonable.

Failing to align your support period with these realistic expectations is a direct path to non-compliance penalties and a breakdown in customer trust. To meet these mandates effectively, it’s vital to build a broader framework for regulatory compliance risk management. For a deeper dive, check out our guide on CRA update requirements for more detailed information. This strategic planning ensures your policy is not only compliant but also a tool for building long-term trust.

An EOL security updates policy isn’t a document you write once and file away. For CRA compliance, it has to be a living, operational workflow. This is where the theory ends and the real work of building your vulnerability detection, management, and disclosure processes begins.

Your first move is to establish clear and secure reporting channels. Under the CRA, security researchers are your allies, not adversaries. You need to give them an easy, reliable way to tell you about potential vulnerabilities.

A common and effective way to do this is with a security.txt file on your website. This simple text file acts as a signpost, directing researchers to your vulnerability disclosure policy (VDP) and the right email address. For example, your security.txt file should point to a contact like security@yourcompany.com and include a link to your public VDP page.

Establishing Internal Triage and Prioritisation

Once a vulnerability report lands in your inbox, your internal workflow must take over. Not all vulnerabilities are created equal, which is why a structured triage process is so important. This is where you assign severity scores—usually with the Common Vulnerability Scoring System (CVSS)—and prioritise what to fix based on real-world risk.

A solid, repeatable workflow might look like this:

• Initial Triage: An assigned security team member acknowledges the report within 48 hours. Their first job is to validate the report to confirm it’s a genuine vulnerability affecting your product. For example, if a researcher claims they can bypass the login on your smart lock app, the triage team’s first job is to try and replicate that exact process.
• Severity Assessment: The team assigns a CVSS score and classifies the vulnerability (e.g., Critical, High, Medium, Low). A remote code execution flaw in your core firmware is obviously Critical; a minor glitch in the UI is Low.
• Prioritisation: Based on its severity, the vulnerability is fed into the engineering backlog. Critical issues must jump to the front of the queue, no questions asked.

This entire triage process has to be documented. When regulators come knocking, they’ll want to see evidence of a repeatable, risk-based system for handling vulnerability reports. For a much deeper dive into these mechanics, you can read more about https://goregulus.com/cra-requirements/cra-vulnerability-handling/.

Defining and Documenting Your SLAs

With a vulnerability prioritised, the clock on your Service Level Agreements (SLAs) officially starts. The CRA’s requirement to provide updates “without delay” is intentionally vague; your policy is where you translate that into concrete, defensible timelines. These SLAs are your public commitment to patching.

The CRA reporting obligations, which became effective on 11 September 2026, force manufacturers to have these processes documented and ready for inspection. This deadline arrives well before the main obligations in December 2027. Your technical files must prove you can support your products for the required five-year period and respond to incidents, all underscoring the urgency of delivering updates “without delay.”

The timeline below shows the mandatory support period that every product must follow.

As you can see, the five-year security support clock starts the moment your product is launched. This is a commitment that must be actively managed until you formally declare its End of Life.

Defining your response timelines is a critical exercise. The following table provides a template for defining your internal and external SLAs based on vulnerability severity, which is a cornerstone of a compliant CRA policy.

Sample Vulnerability Response SLAs

This structure creates an auditable, risk-based process that demonstrates your commitment to timely remediation and helps you meet those crucial reporting deadlines.

Differentiating Default vs. Critical Product Timelines

The CRA isn’t a one-size-fits-all regulation. It distinguishes between product classes, and your SLAs absolutely must reflect that. ‘Critical’ class products—think industrial controllers, network hardware, or safety systems—carry far greater systemic risk and are held to a much higher standard.

A key principle is that the more integral your product is to critical infrastructure or operations, the shorter your patching timeline must be. Your CRA end of life security updates policy must reflect this risk-based approach.

Your workflow needs to account for the heightened urgency around critical security vulnerabilities, as recent incidents have shown how quickly these can escalate.

Let’s look at a practical comparison of SLAs for two different types of products. A ‘Default’ class smart speaker just doesn’t carry the same weight as a ‘Critical’ class Programmable Logic Controller (PLC) used in a factory.

• For a Critical vulnerability (CVSS 9.0+):

  • ‘Default’ Smart Speaker: You might commit to a patch within 30 days. An example would be a flaw allowing unauthorized access to the speaker’s microphone.
  • ‘Critical’ PLC: The expectation is much shorter, perhaps 15 days or even less. A similar remote access flaw in a PLC controlling a city’s water pumps would demand a much faster response.

• For a High severity vulnerability (CVSS 7.0-8.9):

  • ‘Default’ Smart Speaker: A 60-day patch timeline might be acceptable.
  • ‘Critical’ PLC: You’d be expected to deliver a patch within 30 days.

Building this tiered, risk-based workflow isn’t just a good idea; it’s a non-negotiable requirement for market access under the CRA. It creates the repeatable, auditable process you need to prove your vulnerability management is both effective and compliant.

Drafting Your Policy Document Clause by Clause

Alright, let’s get practical. It’s time to translate your plans into a formal, actionable document. Your CRA end of life security updates policy isn’t just a box-ticking exercise for the lawyers; it’s a public promise to your supply chain partners and the people who use your products. This document has to be precise, transparent, and leave zero room for interpretation.

Think of this policy as the single source of truth for your product’s security lifecycle. It spells out your commitments, manages expectations, and gives you a framework for handling vulnerabilities and communicating updates. Every clause needs to be written with both compliance and real-world clarity in mind.

Defining Policy Scope and Applicability

First up, you need to be crystal clear about which products the policy actually covers. This is especially critical if you have a large or growing product portfolio. Getting specific here prevents a world of confusion down the line for everyone from your internal teams to distributors.

The best way to do this is by listing product families or even specific models. Vague, all-encompassing language is a recipe for trouble.

Here’s how that might look in a real policy:

“This Security Update and End-of-Life Policy applies to all hardware and software products with digital elements manufactured by [Your Company Name] and placed on the European Union market on or after December 11, 2027. This includes, but is not limited to, the ‘SmartHome Hub’ Series (Models SH-100, SH-200) and the ‘SecureConnect’ Router Series (Models SC-500, SC-550).”

This example immediately clarifies which products are in scope, ties it directly to the CRA’s start date, and gives concrete examples. If you need a deeper dive into the documentation required, our guide on CRA technical documentation is a great resource.

Articulating the Security Support Period

This is the absolute heart of your policy. The CRA sets a floor with its five-year minimum, but as we’ve discussed, your product’s real-world lifespan might demand a longer commitment. Your policy must state this support period without any ambiguity for each product or product line.

Remember, the clock starts ticking the moment a product is “first placed on the market.” Be precise about this so you have a clear, auditable timeline.

Here’s a practical clause:

“Each product covered by this policy will receive security updates for a period of no less than seven (7) years from the date it is first placed on the EU market. For Product Model Z, first placed on the EU market on June 1, 2027, security updates will be provided until at least June 1, 2034. The specific End-of-Life (EOL) date for each product model will be published on our corporate website.”

This clause doesn’t just meet the CRA minimum; it extends it based on the product’s expected use, showing a real commitment to security. It also provides a specific, verifiable example and tells people exactly where to find EOL dates.

Outlining the Vulnerability Disclosure and Patching Process

Transparency in how you handle vulnerabilities is a non-negotiable part of the CRA. This section of your policy needs to lay out the journey from receiving a vulnerability report to shipping a patch. While your internal SLAs can hold the fine-grained details, the public policy should give a clear, high-level overview.

You should also point to your vulnerability disclosure programme (VDP) and the channels researchers should use. It shows you have a mature process for getting that crucial external security intelligence.

A solid vulnerability process clause should cover:

• Reporting Channels: Be specific about how security researchers can contact you. Point them to your security.txt file, a web form, or a dedicated email address. For example: “Security researchers are encouraged to report potential vulnerabilities to security@yourcompany.com. Our PGP key for encrypted communication is available on our Vulnerability Disclosure Policy page.”
• Nature of Support: Make it clear that this support is for security vulnerabilities, not for adding new features or fixing general software bugs.
• Update Delivery: Explain how users will get the updates (e.g., over-the-air, manual download) and confirm they will be provided free of charge. For example: “Updates are delivered automatically via over-the-air (OTA) updates. Users will receive a notification in the companion app to initiate the update.”

This section effectively turns your internal workflows into a public commitment, which goes a long way in building trust with customers and the security community.

Structuring Your Communication Plan

Your policy has to spell out how you’ll communicate with everyone in your supply chain—importers, distributors, and end-users. A vulnerability isn’t truly fixed until the patch is actually applied, and that requires telling people about it.

The CRA places duties on every economic operator, so your communication plan must help them meet their own obligations. An importer needs to know about a patch just as urgently as an end-user does.

A robust communication clause ensures every actor in the supply chain receives timely, actionable information. This is not just good practice; it’s a critical component of your shared responsibility under the CRA.

Here’s an example of what that commitment looks like on paper:

“Upon the release of a security update, [Your Company Name] will notify affected parties through the following channels:

• End-Users: In-app notifications and a public security advisory posted on our website.
• Distributors and Importers: Direct email notifications to registered supply chain partners within 48 hours of a patch release, including details on the vulnerability and affected product versions.

We will provide at least 180 days’ notice before a product’s declared End-of-Life date, communicated via our website and direct partner channels.”

This clause establishes a clear, multi-channel strategy. It ensures the information gets to everyone who needs it, from a homeowner with a smart device to the distributor who brought it into the country. This kind of systematic approach is the backbone of a compliant and effective CRA end of life security updates policy.

The Cyber Resilience Act doesn’t just apply to future products. It creates complex, and often misunderstood, obligations for the devices you already have on the EU market.

The transition period leading up to the full 11 December 2027 deadline requires a clear strategy for these legacy products. Ignoring them is not an option, and getting it wrong can create a major compliance and reputational risk.

While products placed on the market before that date won’t need to meet every CRA requirement retroactively, crucial provisions still apply. Key among them are the rules on vulnerability handling and incident reporting. Your CRA end of life security updates policy must therefore have a concrete plan for this transition.

Start With a Legacy Product Inventory

Your first practical step is to get a complete picture of every product with digital elements your company has placed on the EU market. This inventory is the absolute foundation of your transition strategy.

You need to map out your entire portfolio, organised by launch date. For example, imagine a manufacturer with three key product lines:

• Product Line A: Launched in 2024
• Product Line B: Launched in 2025
• Product Line C: Launched in early 2026

Each of these product families carries different obligations under the CRA’s phased timeline. A simple spreadsheet or asset management tool can get you started, but the goal is a definitive record that maps each SKU to its specific compliance path.

Understand the Critical Transitional Deadlines

The CRA’s rollout isn’t a single event. Certain rules activate much earlier than others, and they directly impact your legacy products. Two dates are especially important for your transition plan.

First, the manufacturer’s vulnerability and incident reporting duties under Article 14 kick in from 11 September 2026. For all in-scope products already on the market—including those launched in 2024, 2025, and 2026—you must have a process to report actively exploited vulnerabilities to the designated authorities.

Second, the main CRA obligations, like the five-year support window and full technical documentation, apply to products placed on the market from 11 December 2027 onwards. Products launched before this are generally exempt from these retroactive requirements, but there’s a huge catch: “substantial modifications.”

A “substantial modification” is any change made after the deadline that alters the product’s original intended purpose, function, or type in a way that could change its compliance with the CRA. This effectively turns a legacy product into a new one from a regulatory standpoint.

For instance, if your team pushes a significant firmware update in 2028 for your 2026 product line—one that adds new connectivity features or increases its cybersecurity risk—that updated version will likely need to be fully CRA-compliant. A practical example: changing a smart camera’s firmware to allow cloud storage where previously only local storage was possible would almost certainly be a substantial modification. Your transition plan must account for this.

Build Your Practical Transition Plan

With your inventory complete and deadlines understood, you can build a transition plan that prevents compliance gaps. This shouldn’t be an informal checklist; it must be a documented part of your formal CRA strategy.

The plan needs to outline precisely how you will handle products based on their market placement date.

A Real-World Example: Transition Strategy for Three Product Lines

Let’s look at how this applies to our example portfolio:

1. Product Lines A, B, and C (Launched 2024-2026):

   • Action: Implement a vulnerability monitoring and incident response workflow immediately. You must be ready to meet the 11 September 2026 reporting deadline. This means having the systems to detect, assess, and report actively exploited vulnerabilities to the designated CSIRT via ENISA’s platform.
   • Action: Define and enforce a strict policy on “substantial modifications.” Your engineering and product teams have to understand that any major post-2027 update could trigger full CRA conformity requirements, turning a simple update into a major compliance project.
   • Action: Communicate a clear support status. Even if the CRA’s five-year rule doesn’t retroactively apply, providing security updates for a defined, reasonable period builds customer trust and reduces your risk exposure.

2. New Products (Launched from 11 December 2027 onwards):

   • Action: These products must be fully compliant from day one. All your processes for secure design, vulnerability management, documentation (including the SBOM), and the five-year support window must be fully operational and evidenced.

This tiered approach ensures you allocate resources effectively. You can prioritise the urgent reporting requirements for legacy devices while systematically preparing your entire product development lifecycle for full compliance. It’s the only way to turn the complex CRA transition period into a manageable, step-by-step process.

Generating and Maintaining Your Compliance Evidence

When it comes to the Cyber Resilience Act, the guiding principle is brutally simple: if you can’t prove it, it didn’t happen. A perfectly written CRA end-of-life security updates policy is just the beginning. The real challenge is generating the complete, auditable evidence trail that regulators expect to see in your technical file, as outlined in Annex II and VII.

This isn’t about scrambling to create paperwork during an audit. It’s about building a system where compliance evidence is the natural output of your day-to-day security and development work. Market surveillance authorities will want to see a clear, traceable line from a vulnerability report all the way to a deployed patch, and your records are what will tell that story.

The Software Bill of Materials as Your Foundation

The absolute cornerstone of your evidence file is the Software Bill of Materials (SBOM). The CRA makes this mandatory, transforming the SBOM from a nice-to-have best practice into a fundamental condition for market access for any product with digital elements.

Your SBOM must be in a common, machine-readable format like SPDX or CycloneDX. While the law requires you to detail at least the top-level dependencies, both best practice and regulatory expectations are pushing for a deeper view that includes transitive dependencies. You’re on the hook for keeping this document for at least ten years after the product is placed on the market.

The SBOM isn’t a static document you create once at release. It is a living record. It must be updated with every single patch or component change, providing a real-time inventory of your product’s software DNA.

Think of it this way: when you patch a third-party library to fix a critical flaw, your SBOM must be updated to show the new, secure version. That updated SBOM becomes a key piece of evidence, proving you’ve closed the risk.

Building Your Undeniable Audit Trail

An effective audit trail isn’t just a pile of documents; it’s a coherent story that connects every piece of evidence. Regulators need to see the entire lifecycle of your vulnerability response, from the initial report to the final fix.

Here’s a practical example of how you can link records to build that undeniable proof:

1. Vulnerability Report: A researcher reports a flaw in the lib-auth-v1.2 library used in your “SmartConnect Hub” via your security@yourcompany.com inbox. You immediately log this report with a unique ID, let’s say VR-2028-005.
2. Internal Triage: Your security team confirms a CVSS score of 8.8 (High). They document this assessment in your issue tracker, making sure to link it back to the original report, VR-2028-005.
3. Patch Development: Your engineers get to work. When they commit the fix, the Git message is explicit: “Fix: Update lib-auth to v1.3 to resolve VR-2028-005.” The link is clear.
4. Firmware Release: You release a new firmware version, v2.5.1, containing the patch. The release notes specifically call out the security fix.
5. SBOM Update: The SBOM for firmware v2.5.1 is generated, and it now correctly lists lib-auth-v1.3.
6. Communication Logs: You send a notification to your distributors about the critical update and publish a security advisory on your website. These communications are time-stamped, creating a permanent record.

This chain—from email to Git commit to SBOM—creates a complete and irrefutable audit trail. It doesn’t just show you fixed the bug; it proves you followed your own documented process. For a full breakdown of what to include, you might want to look at our guide on building a CRA compliance evidence pack.

A Checklist of Essential Compliance Evidence

Whether you’re facing an importer’s verification request or a full regulatory audit, you need your technical file organised and ready. Here is a checklist of the core evidence you should be generating and maintaining as a matter of course.

• Vulnerability Management Records:
  • Logs of all inbound vulnerability reports from researchers, automated tools, and other sources.
  • Internal triage notes, including CVSS scores and your reasoning for prioritisation.
  • Records of all communications with the people who reported the vulnerabilities.
• Development and Patching Artefacts:
  • Version control history with commit messages clearly linked to specific vulnerability fixes.
  • QA reports and test results that validate the security patches.
  • Release notes that transparently identify security updates for your users.
• SBOM Lifecycle Records:
  • A complete and up-to-date SBOM for every single product version you ship.
  • A changelog or version history for your SBOMs, showing exactly how and when they have evolved.
• Supply Chain Communication Logs:
  • Copies of emails or portal notifications sent to importers and distributors about security updates.
  • Time-stamped records of any publicly posted security advisories.

By systematically collecting and organising these records, you move your policy from being a static document to a living, auditable system that truly demonstrates cyber resilience.

Digging into the details of the Cyber Resilience Act, even with a solid plan, can bring up some tricky questions. Let’s tackle some of the most common grey areas and practical scenarios we see manufacturers wrestle with when building their CRA end-of-life security updates policy.

What Does ‘Without Delay’ Really Mean in Practice?

“Without delay” is probably one of the most debated phrases in the entire CRA, and for good reason. The regulators intentionally left it open to interpretation. They’re not looking for a fixed number of days; they’re looking for a risk-based response you can defend. Everyone understands that not all vulnerabilities are equal and that a proper patch is more than a quick code change.

The real test is whether your timeline is justifiable given the circumstances. Several factors will naturally shape how fast you can—and should—roll out an update:

• Vulnerability Severity: A critical remote code execution flaw (CVSS score 9.0+) is an all-hands-on-deck emergency. A low-severity issue, on the other hand, can probably wait for the next scheduled patch release.
• Fix Complexity: Some fixes are simple. A quick configuration change can be pushed out rapidly. But a flaw buried deep in the firmware might demand serious re-engineering and testing, which just takes more time.
• Testing and QA Cycles: Rushing out a broken patch can cause more damage than the vulnerability itself. Your timeline has to bake in enough time for rigorous testing to make sure the fix is stable and doesn’t create new problems.

For example, if a critical vulnerability is found, “without delay” could mean your security team works through the weekend to develop a patch within 72 hours. This would be followed by another 48 hours of automated and manual QA before deployment. For a medium-severity bug, a 30-day sprint cycle is often a perfectly reasonable and defensible timeframe. The key is to have these SLAs defined and documented internally.

Does the Five-Year Clock Apply to Products Sold Before the Deadline?

This is a major point of confusion, so let’s clear it up. The five-year minimum support clock officially starts ticking only when a product is first “placed on the market” after the CRA’s main rules apply on 11 December 2027. A product you sell on 10 December 2027 is not retroactively covered by this five-year rule.

However, that doesn’t give pre-deadline products a free pass. There are a couple of important nuances to be aware of.

First, the reporting obligations kick in much sooner. The duty to report actively exploited vulnerabilities to the authorities applies from 11 September 2026. This affects all products on the market, including your legacy devices.

Second, think about your supply chain partners. An importer bringing your pre-2027 product into the EU will still have their own due diligence to perform. A clear EOL policy, even for older products, makes their life easier and shows you’re a reliable partner. For example, if you provide a clear 2-year support policy for a product sold in 2026, an importer can use that information to confidently handle their obligations, making them more likely to stock your product.

So, while the five-year rule isn’t retroactive, the CRA’s earlier reporting deadlines and the expectations of your supply chain mean your legacy products are very much part of the bigger picture.

How Do We Announce an End-of-Life Date Without Scaring Off Customers?

This is all about framing. A lot of manufacturers worry that advertising an EOL date sounds like planned obsolescence and will kill sales. The trick is to position your support period as a guarantee of quality and a transparent security commitment, not as a countdown to a useless product.

Don’t hide it. Make it a selling point.

Being upfront builds trust and manages customer expectations right from the beginning. It shows you’re a professional organisation that stands behind its products.

Here’s how you can phrase it positively on your website, packaging, and manuals:

• On the Box: “Includes guaranteed security updates until at least December 2032 to protect your investment.”
• On a Product Webpage: “We stand behind our products. The SmartHome Hub 2.0 comes with a 7-year security support commitment, ensuring it stays safe and reliable throughout its expected lifetime.”
• In the User Manual: “To ensure your long-term security, [Your Company Name] provides critical security patches for this product for a minimum of five years from its market launch. You can find the specific EOL support date for your model at [link to your EOL page].”

When you’re this transparent, a regulatory headache becomes a competitive advantage. It tells the world you’re serious about keeping your customers safe.

Regulus provides a step-by-step roadmap to turn complex CRA findings into an actionable compliance plan. Our platform helps you unify applicability assessments, generate tailored requirements, and structure technical evidence so you can confidently place compliant products on the European market. Gain clarity and reduce costs by visiting us at https://goregulus.com.

La entrada Your Guide to a Compliant CRA End of Life Security Updates Policy se publicó primero en Regulus.

Defining the Security Support Period Under the CRA

Let’s say you’ve developed a new smart home camera. In the past, you decided how long to provide security patches based on business strategy. The Cyber Resilience Act (CRA) changes that completely. This is now a legal requirement, and the security support period is the core concept defining your long-term commitment to a product’s safety once it’s in a customer’s hands.

This isn’t just about fixing the odd bug. It’s about actively maintaining your product’s defences throughout its expected lifetime. The CRA’s goal is simple: protect consumers from devices that become insecure over time, so they can trust the connected products they buy.

From Feature to Legal Requirement

This is a massive shift for manufacturers. What was once a competitive advantage or a premium service offering is now the baseline for entry into the EU market. Your responsibility doesn’t end when the product is sold; it extends for a defined period afterwards.

Under the CRA, manufacturers are legally bound to address vulnerabilities for a defined period. This transforms post-market surveillance from a best practice into an enforceable duty, ensuring products remain resilient against emerging threats.

Practical Examples of the Support Period

Understanding this is easiest with a few real-world scenarios. The support period you define has to be realistic and defensible, tied directly to how a consumer would reasonably expect to use the product.

• Smart Security Lock: A customer expects a high-end digital lock to secure their home for years. A manufacturer might therefore define a 10-year support period, committing to patching any new software flaws or exploits for a full decade.
• Connected Kitchen Scale: This device has a much lower security risk and a shorter expected lifespan. Here, the manufacturer could reasonably set a 5-year support period—which is the minimum under the CRA, unless an even shorter lifetime can be justified.
• Smart Toy for Children: A connected toy might have a camera or microphone. While its play value might only last a year or two, its potential for privacy invasion means regulators will expect a support period covering its realistic use, likely hitting the 5-year minimum to protect children’s data long-term.

To get a clearer picture of which of your products fall under these new rules, have a look at our guide on the scope of the Cyber Resilience Act. Getting this right sets the foundation for all your other compliance activities.

How to Calculate Your Product’s Support Period

Figuring out your product’s security support period isn’t a guessing game. It’s a strategic decision you have to be ready to defend in front of regulators. The Cyber Resilience Act (CRA) ties this period directly to your product’s ‘expected lifetime’, meaning you need a clear, documented method for calculating how long customers will realistically use it.

This goes far beyond a simple warranty. It requires a hard look at your product’s purpose, value, and place in the market. You are effectively defining the window during which you are legally on the hook for its security.

Factors for Defining Expected Lifetime

To land on a reasonable and compliant expected lifetime, you need to analyse several key factors. This entire process must be documented because it’s a critical part of your technical file and conformity assessment.

• Product Purpose and Type: Is your product a core piece of infrastructure or a throwaway novelty? A smart thermostat built into a building’s HVAC system clearly has a longer expected lifetime than a connected party speaker. Practical Example: A smart thermostat is physically installed and expected to function for 10-15 years, so its support period should align with that. A portable Bluetooth speaker might only be expected to last 3-5 years.

• Customer Expectations: Put yourself in your customer’s shoes. Someone buying a high-end smart refrigerator rightly expects it to receive security updates for a decade or more, matching its high price tag and long service life. Practical Example: A €3,000 smart fridge should receive updates for its entire useful life (e.g., 10+ years), whereas a €50 smart coffee mug has much lower expectations.

• Market Comparisons: What are your competitors doing? Analysing the support periods and lifecycles of similar products helps establish a benchmark for what’s considered standard practice in your product category. Practical Example: If leading brands of smart TVs offer 7 years of security support, offering only the 5-year minimum for your competing model might be hard to justify to regulators.

The core principle is justification. Your support period must be a logical extension of the product’s intended use and market context, not an arbitrary number picked for convenience. A well-reasoned calculation is your best defence during market surveillance.

The CRA also throws in a crucial safety net for consumers. While you should aim for a support period that matches the product’s expected lifetime, the law mandates it must last for at least five years. This rule creates a non-negotiable minimum commitment for most products, ensuring a baseline of long-term security.

Practical Calculation Examples

Let’s apply these factors to a couple of different products to see how their support periods might shake out. This shows how the CRA security support period definition works in the real world.

1. Connected Holiday Decorations: These have a very specific, seasonal use. A consumer probably expects them to work for a few holiday seasons at most. A manufacturer could justifiably argue for a shorter expected lifetime, perhaps two or three years, but would still be bound by the five-year minimum support requirement.

2. Industrial IoT Sensor: An IIoT sensor used in a factory to monitor critical machinery is expected to operate reliably for a long, long time. Given its role in operational safety and efficiency, its expected lifetime could easily be 10-15 years, demanding a correspondingly long security support period.

Ultimately, your goal is to arrive at a period you can confidently document and defend. Getting a handle on these calculations is vital, as the clock on these obligations is already ticking. You might want to check out our guide on the upcoming CRA deadlines for 2025-2027.

Your Obligations During the Support Period

Defining your product’s security support period is one thing, but living up to that promise is where the real work begins. Under the Cyber Resilience Act (CRA), this period isn’t a passive warranty—it’s an active, continuous service commitment you owe your customers.

Think of it less like a one-off compliance checkbox and more like a live service agreement for your product’s security. Your responsibilities here aren’t just good practice; they are legal duties that make or break your market access. These obligations are fundamental to what the CRA security support period definition truly means in practice.

Let’s break down exactly what the regulation expects from you day in and day out.

Proactive Patching and Free Updates

Your first and most important job is to hunt down and fix security flaws. The CRA firmly rejects the old, reactive model of waiting for bug reports to trickle in. Instead, you are expected to be on the front foot, actively monitoring your product and its third-party components for emerging vulnerabilities.

When a flaw is found, your obligation is to develop and ship a security update to fix it. Critically, these patches must be provided free of charge and delivered in a way that’s simple for users to install. Long gone are the days of hiding updates behind complex portals or paywalls.

A smart TV manufacturer, for example, must have a system to push an over-the-air (OTA) update automatically to all its devices when a flaw is discovered in its operating system. The user should see nothing more than a simple on-screen prompt to install it.

The CRA’s mandate is clear: security updates must be delivered without delay. This means having a well-oiled machine for patch development, testing, and deployment is non-negotiable for the entire support period.

Structured Vulnerability Management

Alongside your own proactive work, you must build a formal, organised system for handling vulnerabilities that others find and report. This requires a public, secure channel where security researchers, ethical hackers, and even customers can submit potential bugs they’ve discovered.

To give you a clearer picture, here’s a summary of the core obligations that fall under vulnerability management.

Key Manufacturer Obligations During the Security Support Period

This table outlines the main responsibilities manufacturers have throughout the defined support lifecycle of a product with digital elements.

Ultimately, these duties work together to create a cycle of continuous improvement and risk reduction, which is exactly what regulators want to see.

Transparent Communication and Documentation

Finally, transparency is a non-negotiable pillar of the CRA. You are legally required to tell your customers exactly how long the security support period will last, right from day one. This information must be clear and easy to find in the product’s documentation, like the user manual, on the packaging, or on its website.

This upfront declaration does two things: it manages customer expectations and serves as your public, legally binding commitment. It empowers buyers to make smarter purchasing decisions, weighing the long-term security of your product against competitors.

For instance, the online listing for a new Wi-Fi router must explicitly state something like, “This product will receive security updates for a minimum of 7 years from the date of purchase.” No ambiguity, no fine print. Just a clear, honest statement.

Managing the 24-Hour Vulnerability Reporting Deadline

When an actively exploited vulnerability hits your product, the clock starts ticking. Loudly. The Cyber Resilience Act (CRA) gives you just 24 hours to report it, turning a bad day into a frantic race against a legal deadline.

This isn’t a suggestion; it’s a mandate. The rule exists to trigger a rapid, coordinated EU-wide response to protect users and critical infrastructure. Without a battle-tested plan, you’re not just risking a security crisis—you’re facing serious penalties and a major blow to your brand.

Understanding the Reporting Triggers

The 24-hour countdown begins the moment you become aware that a vulnerability in your product is ‘actively exploited’. This isn’t about a theoretical weakness found in a lab. It means attackers are actually using the flaw out in the wild to compromise systems.

Practical Example: Your security team discovers forum posts with code showing how to take control of your smart doorbell model by exploiting a specific flaw. This is active exploitation, and your 24-hour reporting clock has just started.

This rapid reporting duty is also triggered by any security incident that has a severe impact on your product’s security, even without confirmed exploitation. Your team needs the skills and authority to assess a situation fast and decide if it hits the threshold for immediate notification.

The moment you learn of an actively exploited vulnerability, you must notify your national Computer Security Incident Response Team (CSIRT) and the European Union Agency for Cybersecurity (ENISA). This is an immediate early warning—not a report you file after you’ve fixed it.

A High-Pressure Incident Timeline

To pull this off, your internal incident response process needs to be flawless. Think about the timeline from the moment of discovery (Hour 0) to the reporting deadline (Hour 24). It’s tight.

• Hour 0-2: Initial Triage. Your security team gets an alert—maybe a zero-day exploit. The first two hours are a blur of confirming the vulnerability and hunting for the first pieces of evidence showing it’s being actively used.

• Hour 3-12: Impact Assessment. The full incident response team is activated. Their job is to quickly understand the blast radius: which product versions are affected, how many users are at risk, and what the potential damage could be.

• Hour 13-20: Drafting the Report. Your compliance lead grabs a pre-approved communication template and starts drafting the initial notification for ENISA and the national CSIRT. The report must be clear, concise, and packed with all known technical details. You can find more on these formal duties in our article on CRA reporting obligations under Article 14.

• Hour 21-24: Review and Submission. The draft goes through a final, high-speed review by legal and technical leadership. Then, it’s submitted through the official portal. You absolutely want to submit well before the final hour to avoid any last-minute technical glitches.

This 24-hour reporting requirement will apply sooner than other parts of the CRA. In fact, manufacturers must be ready to report vulnerabilities starting September 11, 2026. You can read more about what you need to be doing to prepare for the Cyber Resilience Act on DLAPiper.com.

Turning this potential chaos into a structured process means preparing now. You need a dedicated incident response team, clear lines of authority, and ready-to-go templates.

The infographic below highlights the pressure-cooker scenario of an actively exploited vulnerability. Once discovered, the clock starts ticking on a mandatory 24-hour reporting window.

This tight deadline alone shows why having a pre-planned incident response process is not just good practice—it’s a core survival skill under the CRA.

Practical Scenarios: Support Period in Action

Let’s move from theory to practice. Seeing how the CRA’s security support period plays out in the real world is the best way to understand the planning, documentation, and long-term commitment it demands from manufacturers.

Scenario 1: The High-Risk Smart Security Camera

Imagine SecureHome, a manufacturer launching a new, high-end security camera with advanced AI features. This isn’t a cheap gadget; it’s a premium product designed to protect a family’s home. Given its critical function and price point, the company determines the product’s expected lifetime is at least 10 years.

SecureHome doesn’t just guess. They formally document this assessment in their technical files, referencing market analysis of similar high-value security systems. Based on this, they commit to a 10-year security support period. This isn’t buried in the fine print; it’s stated clearly on the packaging, in the user manual, and on their website.

The Test in Year Six

Six years after the camera’s launch, a crisis hits. A security researcher finds a serious vulnerability that could let an attacker bypass authentication and view the live video feed. Worse, there’s evidence the flaw is being actively exploited in the wild. The 24-hour reporting clock starts now.

Because they were prepared, SecureHome’s team validates the report and submits its initial notification to ENISA and the relevant national CSIRT in just 18 hours. Their well-rehearsed incident response plan and pre-written templates made all the difference.

In the following two weeks, their engineers develop, test, and deploy a free over-the-air (OTA) security patch to every affected camera. SecureHome turned a potential disaster into a demonstration of competence, precisely because their long-term support obligations were baked into their processes from day one.

Scenario 2: The Standard-Risk Connected Kitchen Scale

Now, let’s look at a different type of product. A company called PreciseKitchen is launching a smart kitchen scale that sends nutritional data to a mobile app. It’s a useful consumer gadget but serves no critical function. It falls squarely into a lower-risk category.

PreciseKitchen analyses the market and concludes a reasonable expected lifetime for this type of device is five years. They decide to set the security support period to the CRA-mandated minimum of 5 years. This decision is justified and documented, with the product’s low cost and non-critical nature as the key rationale.

Planning for End-of-Life

For PreciseKitchen, the game isn’t just about starting support; it’s about ending it gracefully. As the 5-year period nears its conclusion, their focus shifts entirely to transparent communication. They don’t want to leave their users in the lurch.

One year before support ends, they begin a clear notification campaign through the companion app and by email.

• 12 Months Out: An initial heads-up that security updates will stop in one year.
• 6 Months Out: A second reminder about the approaching end of support.
• Final Month: One last alert confirming the exact date security updates will cease.

This proactive communication ensures no one is caught by surprise. By managing expectations so effectively, PreciseKitchen not only meets its legal duties but also preserves customer trust—a valuable asset, even when a product reaches the end of its life.

How to Prepare: Your Action Plan

Right, let’s turn the theory of the CRA support period into a concrete action plan. This isn’t just about ticking boxes; it’s about building a defensible process that protects your customers and stands up to regulatory scrutiny.

Think of this as a practical checklist for your product, security, and legal teams to get on the same page.

• Define and Document Your Product’s Lifetime. This is the cornerstone of your support period. You need to formally assess and justify the expected lifetime based on product type, cost, and realistic user expectations. This isn’t a guess; it’s a documented decision that forms the basis for your CRA security support period definition.

• Set Up a Public Vulnerability Intake Channel. You must have a clear, public, and secure way for security researchers and users to report potential flaws. This usually means a dedicated email address (e.g., security@yourcompany.com) and a web form, prominently displayed on your website’s support page.

• Stress-Test Your 24-Hour Incident Reporting. Don’t wait for a real crisis. Run a simulation of an actively exploited vulnerability to ensure your team can meet the CRA’s strict notification deadlines. A dry run will quickly reveal any gaps in your response plan. Building this into a structured CRA Compliance Evidence Pack makes the process repeatable and auditable.

To make all of this work seamlessly throughout the support period, you’ll need to embed these activities into your daily operations. Adopting a strong set of DevSecOps best practices is one of the most effective ways to build this continuous security muscle.

Cyber Resilience Act Security Support: FAQs

The concept of a long-term security support period is central to the CRA, but it also raises plenty of practical questions for manufacturers. Let’s tackle some of the most common ones.

What if My Product’s Lifecycle Is Shorter Than Five Years?

The CRA sets a default security support period of at least five years. But what if your product simply isn’t designed to last that long?

An exception exists, but you need to justify it. For example, a disposable smart sensor built for a single event might have a realistic lifetime of only a few months. In this case, you must provide a solid, documented justification for the shorter support period in your technical files. Be prepared for scrutiny—market authorities will examine these justifications to ensure they are reasonable and based on the product’s intended use, not just a desire to cut costs.

Does the Security Support Period Require Me to Add New Features?

No. The obligation is strictly about security, not functionality. During the support period, you are required to provide free and timely security updates to fix identified vulnerabilities.

You have no obligation to release new features or performance upgrades. The goal is to maintain the security of the product as it was when first placed on the EU market, making sure it stays resilient against emerging threats.

The CRA’s focus is on resilience and safety. Your duty is to patch security holes, not to provide free functional enhancements. This keeps the product secure without mandating new product development.

Who Is Responsible if a Vulnerability Is in an Open-Source Component?

You are. As the product manufacturer, you are ultimately responsible for the security of the entire product you place on the EU market. This responsibility covers every single component inside it, including all third-party and open-source software.

The CRA requires you to maintain a Software Bill of Materials (SBOM) and actively monitor your entire software supply chain for new vulnerabilities. If a flaw is found in an open-source library your product uses, it’s your job to integrate the patch and push the security update to your users. Having a clear action plan for these scenarios is a key part of effective regulatory compliance strategies.

Regulus provides a unified platform to help you navigate the Cyber Resilience Act. Generate your tailored requirements matrix, build audit-ready documentation, and turn complex obligations into an actionable compliance plan. Learn how to confidently place your products on the EU market at https://goregulus.com.

La entrada CRA Security Support Period Definition Explained for 2026 se publicó primero en Regulus.

They don’t help you build a compliant product. They verify that what you’ve built meets the CRA’s strict legal standards before it can reach the market.

Decoding the Role of CRA Notified Bodies

The CRA introduces a whole new level of accountability for anyone placing products with digital elements on the EU market. For high-risk products, the framework places Notified Bodies right at the centre. Their entire job is to provide impartial, third-party conformity assessments.

For certain product categories, their stamp of approval is an absolute prerequisite for market access via the CE marking process.

Practical Example: Imagine you manufacture a smart home security camera. The CRA will almost certainly classify this as a “Critical” product because of its security function and network connectivity. You can’t just declare it secure on your own. You have to submit it to a Notified Body for a full-blown audit. This body acts as a strict gatekeeper. They will meticulously review your technical documentation, test your device against known vulnerabilities, and scrutinise your vulnerability management processes. Their role isn’t to give you design tips or advice. It’s to issue a clear pass or fail verdict against the requirements of the law.

The Foundation of Trust and Expertise

To become a Notified Body, an organisation has to meet a demanding set of criteria laid out by the EU. This is designed to guarantee a consistently high standard of assessment across all Member States.

Key requirements for a Notified Body include:

• Legal Standing and Independence: They must be a legal entity under national law and prove complete impartiality, with zero conflicts of interest related to the products they assess. For example, a Notified Body cannot assess a product manufactured by its own parent company.
• Technical Competence: Their teams must have deep, demonstrable expertise in cybersecurity—everything from secure coding and network protocols to risk assessment and penetration testing. For instance, auditors assessing a network router must understand BGP hijacking and DNS security, not just general IT security.
• Operational Integrity: They must follow robust, documented procedures for conducting assessments, protecting client confidentiality, and managing any complaints. This includes having secure systems for handling a manufacturer’s sensitive intellectual property, like source code or design schematics.

The timeline for getting this infrastructure in place is tight. With the CRA entering into force on December 10, 2024, EU Member States are required to designate their national notifying authorities by June 11, 2026. Those authorities will then assess and appoint the Notified Bodies.

This schedule is meant to ensure enough qualified bodies are up and running before the CRA’s main obligations, including conformity assessments, become mandatory on December 11, 2027. You can track the CRA’s legal framework and official timelines on the European Commission’s summary page.

The core function of a Notified Body is to verify, not to consult. Their impartiality is the bedrock of market trust, assuring consumers and businesses that a CE-marked product has been rigorously vetted against EU cybersecurity standards.

Getting this dynamic right is the first step to a successful conformity assessment. If you manufacture a critical product, you need to learn to think like an auditor. That means preparing evidence-backed documentation that proves you meet every single requirement. To see how these requirements are defined, check out our guide on CRA harmonised standards.

Navigating Your CRA Conformity Assessment Route

Figuring out your path to Cyber Resilience Act (CRA) compliance isn’t a one-size-fits-all exercise. The route you take is decided entirely by your product’s risk classification. Think of it like this: the rules for a casual Sunday drive are very different from the rules for transporting hazardous materials through a city centre.

The CRA sorts products based on the potential harm they could cause if compromised. This classification directly sets the level of scrutiny your product will face before it can wear the CE mark and enter the EU market. Getting this right from the start is a critical strategic decision that will shape your project timelines, budget, and resource planning.

The Three Main Pathways

The CRA lays out different “modules” for conformity assessment, which are just standardised procedures for proving you meet the requirements. The path you follow hinges on whether your product is classified as ‘Default’, ‘Critical Class I’, or ‘Critical Class II’.

• Default Products (Internal Control): For the vast majority of products with digital elements that aren’t deemed critical, you can perform a self-assessment. This is done through an internal control procedure, known as Module A. You are responsible for testing your own product, compiling the technical documentation, and declaring that it meets all the CRA’s security rules.
• Critical Class I Products (Third-Party Assessment): If your product falls into this class, you must involve a Notified Body. The most common route is a mix of your own internal controls combined with a mandatory third-party assessment of key elements. This usually means following Module B (EU-type examination) plus Module C (conformity to type based on internal production control).
• Critical Class II Products (Full Quality Assurance): As the most stringent category, Class II requires comprehensive oversight from a third party. The typical route here is Module H (conformity based on full quality assurance). This involves a Notified Body auditing your entire quality management system for design, development, and production to ensure security is baked in from start to finish.

Understanding these routes early is non-negotiable for manufacturers. To map out your strategy effectively, it helps to walk through a detailed Cyber Resilience Act compliance roadmap to guide your planning.

To make this clearer, let’s look at how the conformity routes and Notified Body involvement change based on product classification.

CRA Conformity Assessment Routes at a Glance

As you can see, the higher the risk classification, the deeper the involvement of an independent third party, moving from simple self-assessment to a full-system audit.

Practical Examples of Assessment Routes

Let’s make this tangible. Imagine your company is developing three very different products.

1. The Smart Thermostat (Default Class)
Your product is a smart thermostat that lets people control their home’s temperature from a mobile app. It’s connected to a network, but its failure doesn’t create a systemic risk. Under the CRA, this would almost certainly be a Default class product.

• Your Route: You can use Module A (internal control). You’ll run your own cybersecurity risk assessment, test for vulnerabilities, generate the Software Bill of Materials (SBOM), and pull together all the technical documentation yourself. No Notified Body is needed, but your documentation had better be solid enough to pass an inspection from a market surveillance authority if they come knocking.

2. The Network Firewall (Critical Class I)
Next up, you’re building a network firewall designed for small businesses. The product’s entire purpose is security, and if it fails, it could expose a customer’s whole network. This is a textbook Critical Class I product.

• Your Route: You’ll most likely follow the Module B + C path. First, you submit your technical documentation and a sample of the firewall to a Notified Body for an EU-type examination (Module B). They will put the design through its paces and, if it passes, issue an EU-type examination certificate. From then on, your internal production controls (Module C) must ensure that every single firewall you manufacture is identical to the certified type.

The core difference is the introduction of an independent check. While you still manage production, the design’s security has been validated by an accredited third party, providing a higher level of assurance.

3. The Industrial Control System (Critical Class II)
Finally, your company builds a Programmable Logic Controller (PLC) used in a municipal water treatment plant. A compromise here could have devastating consequences for public safety. This lands you squarely in Critical Class II.

• Your Route: You have to follow a much more rigorous procedure, like Module H (Full Quality Assurance). A Notified Body won’t just look at the final product; they will audit your entire quality management system. They’ll dig into your secure development lifecycle, your risk management framework, your vulnerability handling processes, and how you guarantee security from the drawing board to the product’s end-of-life. This is a deep, process-level audit to certify that your organisation is built to produce secure products consistently.

Preparing Your Technical Documentation for Audit

Your technical documentation is the single most important file you will present to a Notified Body. Don’t think of it as just a folder of miscellaneous documents. It’s the structured, evidence-based story that proves your product meets every essential security requirement under the Cyber Resilience Act. The best analogy is a complete case file a lawyer prepares for court—every claim must be backed by solid proof.

This file is what your entire audit will be based on. A well-organised technical file makes the Notified Body’s job simpler, which means a smoother, faster, and less expensive assessment for you. On the other hand, a disorganised or incomplete file is a fast track to non-conformity findings, delays, and frustrating rework.

Mapping Annex II to Annex VII

The CRA gives you a clear map for what your technical documentation must contain. Annex II lists the essential security requirements your product must meet, while Annex VII outlines the structure of the technical documentation you need to create to prove it. The goal is to build a direct, traceable line from every requirement in Annex II to the corresponding evidence in your Annex VII file.

Practical Example: A Smart Lock Manufacturer

Imagine your company builds a Wi-Fi-enabled smart lock for homes, a product that would likely be classified as “Critical Class I”. Here is how you would map key requirements from Annex II to your documentation in Annex VII:

• Annex II Requirement: “Protect Confidentiality”: The lock sends an unlock command from a user’s phone. To prove this is secure, your technical file (Annex VII) needs to contain hard evidence of your encryption methods. This would include test reports verifying your implementation of TLS 1.3 for data in transit and AES-256 for data at rest.
• Annex II Requirement: “Protect Integrity”: Your lock gets firmware updates over the air. Your documentation must include architectural diagrams showing the secure boot process and the cryptographic signature verification for every update. This proves that an attacker can’t inject malicious firmware.
• Annex II Requirement: “Control Access”: Your documentation must detail your access control policies. This means showing that the product ships with no default passwords and forces the user to create a unique, strong password during setup, directly satisfying the secure-by-default principle.

To help manage the complexity of preparing these files, many teams are now using advanced technical documentation assistants to structure and populate the required evidence.

Building Your Core Documentation Artefacts

Beyond just mapping requirements to evidence, your technical file needs several substantial documents that form the backbone of your security case. These aren’t just check-the-box exercises; they are the living records of your security posture.

For our smart lock manufacturer, this core set of documents would include:

1. Cybersecurity Risk Assessment: This document must identify all credible threats to the smart lock. For instance, it should analyse the risk of a denial-of-service attack that stops a user from opening their door, or a replay attack where an old command is used to illicitly unlock the door. It must also consider physical attacks, like an attempt to disassemble the lock to extract firmware.
2. Software Bill of Materials (SBOM): You need a detailed inventory of every single software component in the lock’s firmware. This means listing the operating system (e.g., FreeRTOS v10.4.3), cryptographic libraries (like OpenSSL 3.0.2), and any third-party drivers. The SBOM is crucial for managing vulnerabilities; if a flaw is found in a specific version of OpenSSL, you can immediately tell if your product is affected.
3. Vulnerability Handling Policies: This is your formal, written process explaining how you will manage vulnerabilities after the lock is sold. It must include your coordinated disclosure policy, defined timelines for patching (e.g., “critical vulnerabilities patched within 30 days“), and the exact mechanism for delivering updates to customers (e.g., “automatic over-the-air updates pushed to all connected devices”).
4. Secure Development Lifecycle Evidence: You have to provide proof that security is built into your development process from the start. This could include records of mandatory security training for your developers, reports from static analysis (SAST) tools run on your codebase, and logs from your code review process where security checks were signed off.

A Notified Body auditor is always looking for traceability. They should be able to pick any security requirement from Annex II, find the corresponding section in your technical file, and follow a clear path straight to a piece of hard evidence like a test report or a policy document.

Ultimately, preparing this documentation is about building a foundation of trust with your Notified Body. For a deeper dive into organising these elements, see our comprehensive guide on creating a CRA technical file structure that will stand up to scrutiny. A clear, well-supported file shows professionalism and a real commitment to security, making the entire CRA notified body requirements process far more efficient.

The Notified Body Assessment Process Step-by-Step

Understanding the CRA notified body requirements is one thing, but knowing what to expect during the audit itself is another. The process is a structured, multi-stage journey, and a lack of preparation can lead to significant delays and costs. Think of it as moving from theory to practice, where your documentation and your product are put to the test.

This walkthrough breaks down the entire audit, from the moment you submit your application to the final certification decision. Knowing these phases helps you manage internal expectations, prepare your team, and align your product milestones with the compliance schedule.

Phase 1: Application and Scoping

The journey begins when you formally apply to your chosen Notified Body. This isn’t just about filling out a form; it’s a critical scoping exercise. You’ll need to provide high-level details about your product, its intended use, and its risk classification under the CRA (e.g., Critical Class I).

The Notified Body uses this information to confirm they have the technical competence to assess your product. Based on this, they provide an initial quote, a project plan, and assign auditors with the right expertise.

Practical Example: A manufacturer of an industrial gateway, likely a Critical Class I product, would submit an application detailing its functions, network interfaces, and supported industrial protocols (e.g., Modbus, OPC-UA). The Notified Body would then assign auditors with deep experience in operational technology (OT) security to lead the assessment.

Phase 2: Documentation Review

Once the engagement is formalised, the auditors start a meticulous review of your technical documentation. This is the moment where all the effort you invested in preparing your Annex VII file really counts. Auditors will scrutinise your cybersecurity risk assessment, your Software Bill of Materials (SBOM), your vulnerability handling policies, and evidence from your secure development lifecycle.

They are looking for three things: clarity, completeness, and traceability. Can they easily trace a requirement from Annex II to a specific piece of evidence in your file? If your documentation is disorganised or has obvious gaps, this phase will drag on with endless requests for more information.

Practical Example: The auditor sees in your SBOM that you use log4j. They will immediately look for documentation proving you are not using a vulnerable version, or if you are, that you have implemented specific mitigating controls and documented the rationale. A missing link here is an immediate non-conformity.

The process flow above highlights the core pillars of a CRA technical file: risk assessment, SBOM creation, and secure development. These are the primary focus of the documentation review. A strong showing here gives the Notified Body confidence before they even power on the product.

Phase 3: Product Audit and Testing

With the documentation reviewed, the hands-on testing begins. This phase involves a deep dive into the product itself to verify the claims made in your documentation. The exact scope depends on the conformity module you’ve chosen (e.g., Module B vs. Module H) and your product’s complexity.

Auditors may perform a range of tests, including:

• Vulnerability Scanning: Using automated tools to find known vulnerabilities in your product’s software and firmware stacks.
• Penetration Testing: Simulating real-world attacks to test the resilience of your security controls, like access control mechanisms or encryption implementations.
• Functional Verification: Checking that security features described in the documentation—such as secure boot or update mechanisms—actually work as intended.

Practical Example: For a smart lock, an auditor might use a software-defined radio to attempt to capture and replay the “unlock” signal from the mobile app. This tests the anti-replay mechanisms claimed in your documentation. If the lock opens, it’s a major non-conformity.

To better grasp the principles of such an evaluation, it can be useful to review a complete guide to cloud security assessment, as it covers similar evidence-based verification concepts.

Phase 4: Non-Conformity Reporting and Remediation

It’s extremely rare for any product to pass its first audit with a perfect score. When the Notified Body finds a gap between your product and the CRA’s requirements, they issue a non-conformity report. These findings are typically categorised by severity, such as major or minor.

You will be given a specific timeframe to address these findings. This remediation phase is a critical loop; you must fix the issues, update your documentation, and resubmit the evidence to the Notified Body for verification.

Practical Example: A “major” non-conformity could be the discovery of a hardcoded password. A “minor” one might be a missing detail in the end-user documentation about how to report a security issue. The former requires an immediate firmware update, while the latter requires a simple document change.

Failing to address these findings properly is one of the fastest ways to derail your certification timeline.

Phase 5: Final Review and Certification Decision

Once all non-conformities have been successfully closed out, the lead auditor compiles the complete assessment file for a final, independent review. This is usually done by a separate technical reviewer within the Notified Body who was not involved in the initial audit. This final check ensures the process was conducted correctly and that all requirements are truly met.

If the review is positive, the Notified Body issues your certificate—an EU-type examination certificate for Module B or a quality system approval for Module H. This certificate is the key that unlocks CE marking for your product, granting you access to the entire EU market.

Avoiding Common Gaps in Your CRA Submission

Getting through your first Cyber Resilience Act (CRA) audit can feel like navigating a minefield. There are a handful of common pitfalls that consistently trip up manufacturers, even those with a solid security posture. The key is knowing where others stumble so you can build a submission that’s truly audit-proof.

Think of it this way: CRA notified body requirements aren’t about proving you have flawless security. They’re about proving you have a perfectly documented, transparent, and repeatable security process. Auditors aren’t just taking your word for it; their job is to find concrete evidence that backs up every single claim. Vague statements and missing paperwork are the fastest way to get hit with non-conformity findings and expensive delays.

This is where being forewarned is being forearmed. Let’s walk through the most common gaps auditors find and, more importantly, how to make sure your technical file stands up to scrutiny.

Incomplete Cybersecurity Risk Assessments

One of the most frequent and critical failures we see is a cybersecurity risk assessment that’s too narrow. Many teams do a great job analysing risks when the product is first unboxed but completely ignore the threats that will inevitably emerge over its operational life and eventual end-of-life.

• The common mistake: Your risk assessment for a new smart thermostat only covers threats during the initial setup, like a user picking a weak password. It fails to consider what happens when your cloud provider has a data breach two years from now, or the security implications when you eventually stop pushing updates.
• What auditors need to see: A robust risk assessment models threats across the entire product lifecycle. It must cover supplier risks (like a compromised chip), operational risks (a new zero-day exploit in an open-source library you use), and end-of-life risks (ensuring data is properly wiped when the device is thrown away). It must be a living document, not a one-and-done report.

Vague Vulnerability Handling Processes

Simply writing “we manage vulnerabilities” in your documentation is a guaranteed red flag. A Notified Body needs to see a formal, documented process that spells out every step, from how a vulnerability is reported to how the patch is deployed. Ambiguity suggests a chaotic, reactive approach to security—exactly what the CRA is designed to prevent.

A Notified Body needs to see a clear, repeatable, and time-bound process. Your vulnerability handling policy is not just a document; it’s a contractual commitment to your customers and the regulators.

A practical example: Defining your patching timeline

• The vague approach: Your policy just says, “Critical vulnerabilities will be patched in a timely manner.” This is subjective, unenforceable, and will not pass an audit.
• The compliant approach: Your policy defines specific Service-Level Agreements (SLAs). For instance: “Upon confirmation of a critical vulnerability (CVSS score 9.0-10.0), a patch will be developed, tested, and released to all affected users within 30 calendar days.” This is specific, measurable, and auditable.

For more insights into structuring this evidence, our guide on the CRA compliance evidence pack offers practical templates.

Insufficient Proof of Secure Development

Claiming you follow a secure development lifecycle (SDL) is easy. Proving it is another matter entirely. Auditors need to see hard evidence that security is woven into every stage of your development process, not just bolted on as an afterthought. Without that proof, your claims are just empty words.

This table shows exactly how to turn those empty claims into the kind of concrete evidence an auditor is looking for.

By anticipating these common gaps and preparing detailed, evidence-backed documentation from the start, you can transform your audit from a major roadblock into a straightforward validation of your commitment to cybersecurity. This proactive mindset is the secret to successfully meeting your CRA notified body requirements.

Your Actionable Checklist for Notified Body Readiness

Turning the complex CRA notified body requirements into a concrete project plan is the final hurdle before engaging an auditor. This checklist is designed to get you ‘audit-ready’ by breaking the enormous task into manageable phases.

Working through these steps systematically helps you build a strong compliance posture and spot gaps early. You’ll approach a Notified Body from a position of strength, saving everyone a lot of time and money. This isn’t just about ticking boxes; it’s about building a solid foundation of evidence that proves your commitment to security.

Phase 1: Internal Scoping and Strategy

Before you start creating documents, you need to get your internal teams aligned and define your strategy. This first phase ensures everyone understands the scope of the project and their role in the compliance journey ahead.

• Task 1: Finalise Product Classification. Formally decide if your product falls under ‘Default’, ‘Critical Class I’, or ‘Critical Class II’. This decision dictates your entire conformity assessment route and is the very first question a Notified Body will ask.
• Task 2: Select Your Conformity Assessment Route. Based on your classification, choose your module (e.g., Module B + C for Class I, Module H for Class II). Document this choice and, crucially, the reasoning behind it.
• Task 3: Assemble a Cross-Functional Team. Put together a dedicated CRA compliance team with people from engineering, product security, legal, and quality assurance. Define clear roles and responsibilities so everyone knows what they own.

Phase 2: Evidence Gathering and Documentation

This is where you build the core of your technical file. Each item must be a concrete artefact, not a vague promise. The goal is to create a library of evidence that directly maps to the CRA’s essential requirements.

Practical Example: Creating a Complete SBOM
A common task is generating a Software Bill of Materials (SBOM). It’s not good enough to just list a few libraries. You must use a standard format like SPDX or CycloneDX and include every single component, its version, supplier, and licence information for all your firmware and software. For instance, an entry might look like: Component: OpenSSL, Version: 3.0.2, Supplier: OpenSSL Software Foundation, License: Apache-2.0.

With that in mind, focus on these critical tasks:

1. Generate a complete SBOM for all software and firmware components, including every dependency.
2. Conduct and document a comprehensive cybersecurity risk assessment that covers the product’s entire lifecycle, from design all the way to end-of-life.
3. Formalise your vulnerability handling process, which must include a public Coordinated Vulnerability Disclosure (CVD) policy with defined patching timelines (e.g., “critical vulnerabilities patched within 30 days“).
4. Collate evidence of your secure development lifecycle (SDL), such as developer training records, code review logs, and static analysis (SAST) tool reports.

The quality of your documentation directly reflects the maturity of your security programme. A well-organised, evidence-rich technical file tells an auditor that you are a serious, professional partner.

Phase 3: Pre-Assessment Review and Refinement

Before you spend any money on a formal audit, conduct your own internal review. This final phase is all about finding and fixing your own gaps before an auditor does it for you.

• Task: Conduct a mock audit against Annex II. Have an internal team (or a friendly third party) audit your technical documentation against the essential requirements in Annex II. This dry run is invaluable for spotting weak points in your evidence.
• Task: Refine documentation based on findings. Use the feedback from your mock audit to strengthen weak sections, add missing evidence, and improve the traceability between your requirements and your proof.

By methodically completing this checklist, you shift from a reactive to a proactive compliance stance. You will enter the formal assessment process with confidence, ready to demonstrate that your product truly meets the high bar set by the Cyber Resilience Act.

Frequently Asked Questions About CRA Notified Bodies

As you start planning for the Cyber Resilience Act, practical questions about Notified Bodies are bound to come up. This FAQ tackles the most common queries we hear from manufacturers, giving you the direct answers needed to prepare for a successful conformity assessment.

When Should We Start Engaging with a CRA Notified Body?

You should start the conversation with potential Notified Bodies as soon as your product design is stable. In our experience, this means making initial contact 9 to 12 months before your planned market launch.

Practical Example: If you plan to launch your new smart alarm system in the EU for the 2027 holiday season, you should be shortlisting and contacting Notified Bodies by December 2026 at the latest. This gives you time to get quotes, schedule the audit, and leave a buffer for any potential remediation work.

With demand for CRA auditors expected to spike dramatically before the December 2027 deadline, securing your place early is a smart move that prevents last-minute chaos.

Can We Use Our Existing Notified Body for the CRA?

It’s a strong possibility. Many Notified Bodies that already assess products under other EU regulations, like the Radio Equipment Directive (RED), are looking to get designated for the CRA. Sticking with a single body that already knows your product and quality management system can be a huge efficiency win.

Your best bet is to ask them directly. When you next speak with your current Notified Body, ask if they are pursuing or have a clear plan to achieve designation for the Cyber Resilience Act. This can help you consolidate your EU compliance work and audit activities under one roof.

What Happens if a Notified Body Finds a Non-Conformity?

Finding a non-conformity is a normal, even expected, part of any rigorous audit. It’s not a final failure. The Notified Body will issue a formal report that pinpoints exactly where your product or technical file falls short of the CRA notified body requirements.

You’ll be given a set timeframe to resolve the findings. This could mean patching a software vulnerability, updating your technical documentation, or refining a process. Once you’ve made the corrections, you resubmit the evidence for review, and only then can a certificate be issued.

How Much Does a CRA Notified Body Assessment Cost?

Costs vary widely. The final price tag depends on your product’s complexity, its risk classification (Critical Class I vs. Class II), and the Notified Body’s own fee structure.

Practical Example: A Critical Class I smart home hub might require a Module B+C assessment costing €20,000-€40,000. A Critical Class II industrial control system undergoing a full Module H quality system audit could easily exceed €100,000, especially if it involves multiple site visits and extensive product testing.

The only way to know for sure is to request formal quotes from several Notified Bodies early in your budgeting cycle to get a realistic financial picture.

Ready to build a clear, actionable plan for the Cyber Resilience Act? Regulus provides the tailored roadmaps, templates, and guidance you need to prepare for your Notified Body assessment with confidence. Gain clarity and reduce compliance costs at https://goregulus.com.

La entrada CRA Notified Body Requirements: Your Path to Certification in 2026 se publicó primero en Regulus.

Is Your Remote Solution Covered by the CRA?

The Cyber Resilience Act introduces a new level of scrutiny for any “product with digital elements” (PDE) placed on the European market. This broad category covers everything from smart home devices and wearables to standalone software applications. The rules don’t stop at the device or software you sell; they extend to services operating in the background.

This is where the concept of a “remote data processing solution” becomes critical. The CRA defines this as any solution, designed by or under the responsibility of the manufacturer, that a product needs to perform one of its functions. Think of it as a mandatory digital partner to your physical product.

The Essential Functionality Test

So, how do you determine if your remote service is captured? The key is the “essential functionality” test. Ask yourself: can my product perform its primary intended purpose without this remote solution? If the answer is no, then the solution is in scope.

• Practical Example 1: Smart Security Camera
  The hardware is the camera itself. The remote data processing solution is the manufacturer-operated cloud service that processes video, detects motion, and sends alerts to your phone. Without this service, the camera is just a lens; it cannot perform its core security function. Therefore, both the camera and the cloud service fall under the CRA.

• Practical Example 2: Connected Car
  A modern vehicle uses a remote server to receive critical over-the-air (OTA) updates for its engine control unit (ECU). These updates are vital for safety and performance. The car is the product, and the manufacturer’s update server is the essential remote solution. Both are within the CRA’s reach.

A common mistake is assuming that only paid services are in scope. The CRA applies if the product is part of a commercial activity, which includes free products supported by advertising or data monetisation. The dependency on the remote solution is the deciding factor, not its price tag.

Understanding this relationship is the first step toward compliance. For a deeper analysis of whether the CRA applies to your specific products, you might be interested in our guide on Cyber Resilience Act applicability. This linkage between a physical product and its digital brain is central to determining the full CRA remote data processing solutions scope for your portfolio.

Right, so how do you know if your remote data processing solution is actually caught by the Cyber Resilience Act? This is where a lot of confusion comes in, but the test regulators will use is actually quite straightforward.

It all boils down to one critical question: is the remote solution necessary for the product to perform its main function? We’re not talking about nice-to-have features or optional extras. If the product simply cannot do what you sold it to do without that remote connection, then the solution is almost certainly in scope.

Think of it this way: if the core value proposition advertised to the customer disappears when the internet connection drops, the CRA will see the product and the remote service as a single, inseparable entity.

The Core Functionality Test In Action

Let’s make this concrete with a couple of real-world examples. The line between in-scope and out-of-scope often depends on what makes the product “smart” in the first place.

Here is a simple table to help you think through this test for your own solutions.

CRA Scope Test for Remote Data Processing Solutions

As you can see, the distinction is about necessity, not convenience. If the remote component is fundamental to the user experience you’ve promised, you need to treat it as part of the product for CRA purposes.

This decision tree helps visualise the logic. If your remote solution is essential for the product’s core purpose, the CRA treats them as one and the same.

A Closer Look at Exclusions and Grey Areas

Even with this test, there’s still a lot of debate, particularly around cloud services that support products. Industry groups are actively lobbying for clearer lines to be drawn. The big question is whether a service that is integral to a product with digital elements automatically inherits all CRA obligations.

A July 2023 position paper from DIGITALEUROPE proposes nine specific exclusion criteria (E1–E9) for Remote Data Processing Solutions (RDPS). It argues that services not providing core product functionality, or offline manufacturer activities like compiling software updates before they are sent, should be exempt.

This ongoing discussion means it’s more important than ever for manufacturers to carefully document why a specific remote service is or is not essential to the product’s main function. Your documented rationale will be your first line of defence in any regulatory conversation. For a deeper dive on this, you can read also our guide on the CRA scope.

Pinpointing When Your Compliance Clock Starts

Another crucial piece of the CRA remote data processing solutions scope is knowing when your obligations officially begin. The trigger isn’t your development kick-off or service launch date. Your compliance clock starts the moment a product is “placed on the market” in the EU for the first time.

This means the very first instance an individual product unit is made available for distribution or use in the EU as part of a commercial activity. Getting this timing right is absolutely vital for planning your development, documentation, and launch schedules.

So what does “placing on the market” mean in practice for remote solutions?

• For Bundled Products: Your obligations begin when the first hardware unit that relies on your remote service is sold or supplied in the EU. For example, if a French retailer receives the first shipment of a new smart thermostat model, the manufacturer’s CRA clock has started.
• For Standalone Software: It’s the moment the software is first downloaded or accessed by a user in the EU under a commercial agreement. For example, when a German company purchases a subscription and its employee first logs into a SaaS project management tool.
• For Services Updated Post-Launch: If you push a substantial modification to a product already on the market that changes its core function or security posture, that product is considered “newly” placed on the market. For instance, if a smart watch receives an update that adds a new health monitoring feature using a new cloud algorithm, that update re-triggers the full set of CRA obligations.

Understanding this specific trigger point is non-negotiable. It ensures your conformity assessments, technical documentation, and CE marking are all buttoned up before that first unit ever reaches a customer in the EU. A mistake here can result in costly recalls, market-access delays, and serious penalties.

How the CRA Reshapes Your Supply Chain

The Cyber Resilience Act’s reach extends far beyond the original product developer. It establishes a clear chain of accountability that follows a product from design to distribution, especially when it comes to the CRA remote data processing solutions scope.

Compliance is no longer a solo effort; it’s a team sport where every player in the supply chain—the manufacturer, importer, and distributor—has specific, legally binding duties. Knowing your role is crucial for keeping products moving into the EU market without facing major disruptions or legal penalties.

Let’s put this into practice. Imagine a German engineering firm that builds a smart sensor for industrial automation. This sensor is the “product with digital elements,” but it depends entirely on the company’s cloud server for real-time analytics and alerts. That server is its essential “remote data processing solution.”

The Manufacturer’s Core Duties

As the manufacturer, the German firm shoulders the heaviest compliance burden. Before that sensor can be sold, they are responsible for conducting a full cybersecurity risk assessment and a conformity assessment. This must prove that the entire product system—both the physical sensor and its remote server—meets the CRA’s essential requirements.

This process involves building out extensive technical documentation. This file serves as the definitive proof of compliance, detailing everything from the product’s architecture and security-by-design choices to its Software Bill of Materials (SBOM) and vulnerability handling plan.

Only after this is complete can the manufacturer draw up the EU Declaration of Conformity and affix the CE marking to the sensor. This mark is their public promise that the product and its remote solution are fully compliant.

The Importer as the First Gateway

Now, let’s say a French company wants to import these sensors to sell them within the EU. As the importer, this firm becomes the first official gateway into the Union market and has its own set of critical verification duties. They can’t just take the manufacturer’s word for it.

The importer is legally required to verify that the manufacturer has:

• Performed the correct conformity assessment procedure.
• Assembled the required technical documentation.
• Correctly affixed the CE marking to the product.

They must also add their own name and contact address to the product to ensure traceability. If an importer suspects a product is non-compliant, they must not place it on the market. For example, if the packaging lacks the importer’s address or the CE mark looks fraudulent, they are obligated to halt the process and inform both the manufacturer and the relevant market surveillance authorities.

By placing a product on the EU market, an importer is staking its own legal and financial reputation on that product’s compliance. They act as the regulatory backstop, preventing non-compliant goods from entering circulation.

The Distributor’s Final Checkpoint

Once the sensors are in the EU, a Spanish distribution company buys them from the French importer to sell to local factories. This distributor is the final link in the chain before the end-user, and their role is to act with “due care.”

Before making the product available to customers, the distributor must verify that it has the CE marking and comes with all necessary instructions and information, presented in a language their customers can easily understand. They also double-check that the manufacturer and importer have included their names and addresses for traceability.

If a distributor spots an issue, their obligation is the same as the importer’s: stop the sale and notify the parties up the supply chain. A practical example: if the distributor notices the user manual is only in German and they are selling in Spain, they must contact the importer to rectify this before selling the sensors. This model of shared accountability creates multiple checkpoints to catch non-compliant products, a topic we explore further in our overview of supply chain requirements for software.

Real-World Examples of In-Scope Remote Solutions

Definitions and theory only get you so far. To really understand the CRA remote data processing solutions scope, you need to see it applied to real products. The line between an in-scope and out-of-scope remote solution often boils down to a single, powerful question: is the remote processing essential for the product to do its main job?

Let’s walk through a few concrete scenarios. These examples are designed to give your product and engineering teams a clear mental model for spotting CRA-scoped solutions in your own product line-up.

Example 1: Connected Delivery Drones

Think about a company running a fleet of autonomous delivery drones. These drones aren’t just flying on their own; they’re designed to navigate busy cities, avoid no-fly zones, and land safely with their packages.

• The Product: The physical delivery drone.
• The Remote Data Processing Solution: A central command server, operated by the manufacturer, that provides real-time flight path calculations, geofencing updates, and emergency override commands.

Here, the dependency is absolute. Without a constant link to that command server, the drone simply cannot perform its core function of “autonomous delivery.” It can’t navigate safely, react to new obstacles, or follow flight regulations. The remote server isn’t an optional extra; it’s a non-negotiable part of the system. This makes it fall squarely within the CRA’s scope.

When a product’s safety and core function are tied directly to a remote service, the CRA treats them as a single entity. The drone and its server are not seen as separate—both must meet the CRA’s essential cybersecurity requirements.

Example 2: The Modern Smart Thermostat

Now consider a popular smart thermostat. Its main selling point is its ability to learn a household’s habits to automatically optimise heating and cooling, ultimately saving money on energy bills.

• The Product: The smart thermostat unit on the wall.
• The Remote Data Processing Solution: A cloud service that analyses historical usage data, runs machine learning models to predict heating needs, and pushes optimised schedules back to the device.

Sure, you can still walk up to the thermostat and change the temperature manually if the internet is down. But the “smart” features—the very reason customers chose this product—are completely dependent on the cloud. All the heavy lifting, the learning algorithms and data processing, happens on the manufacturer’s remote servers. Because its primary advertised function is “intelligent energy saving,” a function that is impossible without the remote service, that solution is in scope.

Example 3: Industrial Robotics and Remote Configuration

Imagine a factory that has just installed a new generation of high-precision industrial robots on its assembly line. A key feature of these robots is their adaptability—they can be reconfigured for different production runs and receive critical updates remotely.

• The Product: The industrial robot arm itself.
• The Remote Data Processing Solution: The manufacturer’s remote platform, used to push critical safety patches, update firmware, and upload new task configurations for different manufacturing jobs.

In this scenario, the remote platform is vital for the robot’s ongoing security, safety, and functionality. If the robot couldn’t receive a critical security patch, it could expose the entire factory network to a cyber-attack. If it couldn’t be reconfigured remotely for a new task, it would lose a huge part of its value. This direct link to both security and core functionality puts the remote platform firmly within the CRA remote data processing solutions scope.

The logic in each case is the same. The remote solution isn’t just a nice-to-have feature; it’s fundamental to the product’s primary purpose, safety, or identity. This dependency is the definitive test your teams should use when assessing your own products.

Your Documentation and Vulnerability Response Plan

Once you’ve confirmed your remote data processing solution falls under the CRA, it’s time to move from theory to action. Compliance isn’t just about having good intentions; it’s about proving them. This proof rests on two pillars: comprehensive documentation and a robust vulnerability management plan.

These aren’t just administrative box-ticking exercises. They are core operational requirements that demonstrate your product is secure by design and that you have a concrete plan to keep it that way. The CRA demands a clear, auditable trail—informal or purely reactive security practices simply won’t cut it anymore.

The First Pillar: Building Your Technical Documentation

Think of your technical documentation as the central evidence file for your product’s compliance. It’s the first thing market surveillance authorities will ask for, and it needs to tell a convincing story. Under Annex II, this file must be meticulously organised and hold several critical components.

• Cybersecurity Risk Assessment: This is your foundation. You must document a thorough analysis of every potential cybersecurity risk tied to your product and its remote solution. It’s not a simple checklist. It’s a deep dive into threats, their potential impact, and the specific mitigations you’ve put in place. For a smart lock, for instance, you’d assess risks from replay attacks to credential stuffing on the remote server.

• Software Bill of Materials (SBOM): You are required to create a detailed, machine-readable SBOM that lists every single software component. This covers your proprietary code and, crucially, all the open-source libraries used in your product and the remote solution. An SBOM for a fitness tracker’s app would detail every third-party library for Bluetooth, data sync, and UI elements.

• Security-by-Design Evidence: You must prove security was baked in from the start, not bolted on at the end. This means documenting your secure development lifecycle (SDL), including evidence of threat modelling sessions, code reviews, and penetration testing reports. For example, you might include the report from a third-party pen test performed on your remote API before launch.

Your documentation must tell the complete story of your product’s security journey. It should show a regulator that every security decision was deliberate, from initial design to the final build, covering the entire CRA remote data processing solutions scope.

The Second Pillar: Structuring Your Vulnerability Response

The CRA’s rules on vulnerability handling are strict, time-sensitive, and will likely change how you manage security flaws forever. You are now on the hook for managing vulnerabilities for the product’s entire support period—which is typically at least five years.

The most dramatic change is the reporting timeline. Manufacturers must notify ENISA (the EU Agency for Cybersecurity) and the relevant national CSIRT of any actively exploited vulnerability within 24 hours of becoming aware of it. That tiny window demands a highly efficient, well-rehearsed internal process. For more on this, our detailed explanation of CRA reporting obligations under Article 14 can help you prepare.

To meet these demands, you absolutely need a formal plan.

1. Establish a Coordinated Disclosure Policy: Publicly post how security researchers can report vulnerabilities to you. Define your scope, the right communication channels (like a dedicated security email), and what they can expect from you in terms of response times.

2. Define Internal Triage and Assessment: Create a clear workflow for what happens the moment a vulnerability report lands. Who validates the issue? How will you score its severity using a standard like CVSS? And critically, who has the authority to declare it “actively exploited”?

3. Prepare for Rapid Reporting: Don’t try to figure this out during a live incident. Have a pre-defined process and designated people ready to make that 24-hour notification to ENISA. A SaaS company, for example, must have a 24/7 on-call security rotation empowered to make that call. Your plan should also address modern challenges, such as preventing AI hallucinations in any AI-driven systems.

By building out these two pillars, you turn abstract regulatory threats into a clear, manageable operational plan.

Your Compliance Roadmap to the 2027 Deadline

That December 2027 deadline for full Cyber Resilience Act compliance isn’t some far-off concept anymore. It’s a hard date that demands a clear plan, especially for organisations whose products fall under the CRA remote data processing solutions scope. A structured roadmap isn’t just a nice-to-have; it’s the only way to avoid a last-minute crisis.

Trying to tackle this in the final year is a recipe for failure. The work involves deep technical assessments, overhauling documentation, and making fundamental operational changes—none of which can be rushed. The only way to keep your products on the EU market without interruption is to start now with a methodical, phased approach.

Phase 1: Starting Now

The first and most important step is getting a complete picture of your product portfolio. You simply can’t secure what you don’t know you have. This initial phase is all about discovery.

Your immediate priority needs to be a full product portfolio audit. The goal here is to identify every single product—both software and hardware—that has a remote data processing element as part of its core function.

• Action: Build a master inventory of every product you sell or plan to sell in the EU.
• Example: A smart home device manufacturer would list its smart plugs, cameras, and thermostats. For each, they’d need to document the cloud services used for control and data analysis, as these are the in-scope remote solutions.
• Outcome: You’ll end up with a comprehensive list of all potential “products with digital elements” and the remote services they depend on.

Phase 2: Late 2024 to Early 2025

Once your inventory is locked down, the next phase is all about risk classification and deep analysis. This is where you shift from identifying what you have to understanding how the CRA applies to each product.

At this stage, you’ll apply the CRA’s risk criteria directly to your products. You’ll classify them based on their potential cybersecurity impact, which in turn determines the conformity assessment path you must follow.

Under the CRA, products are categorised by risk. The vast majority will be “Default Class,” but products listed as “Important” or “Critical” face much stricter conformity assessment procedures, often requiring third-party involvement.

Your key tasks are:

1. Classify Products: Go through your list and determine if your products are Default Class or if they fall into the higher-risk “Important” or “Critical” categories defined by the European Commission. A practical example: a consumer-grade smart lightbulb is likely Default Class, while an industrial control system for a power grid would be Critical Class.
2. Conduct Detailed Risk Assessments: For every in-scope product, you need to perform a thorough cybersecurity risk assessment as outlined in the CRA. This means identifying threats, analysing their potential impact, and documenting the security controls you have in place.

Phase 3: Mid-2025 to Mid-2027

This final stretch is the most intensive. It’s focused on execution—pulling together all your evidence and formalising your compliance processes before the clock runs out.

During this period, you’ll be finalising all the required documentation and getting your organisation ready for its ongoing post-market obligations. As you build out your documentation and vulnerability response plans, it’s wise to look at established industry certifications; learning about SOC 2 Compliance for RON Platforms can offer valuable insights into data security and integrity best practices.

Your final steps include:

• Complete Technical Documentation: Assemble the complete technical file required by Annex II. This includes your risk assessment, SBOM, and all evidence of your security-by-design approach.
• Perform Conformity Assessments: Carry out the self-assessment (for Default Class) or the third-party assessment (for higher-risk classes) and officially issue the EU Declaration of Conformity.
• Operationalise Post-Market Processes: Finalise and test your vulnerability handling and 24-hour reporting workflows. You need to be sure you can meet these ongoing obligations from day one.

Frequently Asked Questions

Working out how the CRA remote data processing solutions scope applies to your own products can be confusing. Below are some clear, practical answers to the most common questions we hear from manufacturers and product security teams.

Does a Simple API for Data Retrieval Fall Under the CRA?

It all boils down to a test of “necessity”. Ask yourself: if the remote solution stopped working, would the product still be able to perform its main advertised function?

For instance, an API that feeds real-time stock prices to a financial tracking app is absolutely essential. The app can’t do its core job without it, so that remote solution is definitely in scope. On the other hand, an API that just lets a user download a PDF manual is a secondary feature, not a core function, placing it outside the CRA’s direct reach.

The critical factor is dependency. If the product’s advertised purpose relies on the data from the remote solution, that solution becomes part of the regulated system.

Who Is Responsible if My Product Uses AWS for Backend Processing?

You, the product manufacturer, are. The Cyber Resilience Act is unambiguous here: the manufacturer of the final product placed on the EU market must ensure the entire system is compliant.

While a cloud provider like AWS gives you secure infrastructure, that’s just one piece of the puzzle. You are still responsible for making sure your specific application, its configurations, and all your data handling practices running on top of that infrastructure meet every single CRA cybersecurity requirement. You cannot simply delegate or outsource this final legal accountability.

What if My Remote Data Processing Solution Is Hosted Outside the EU?

The physical location of your servers makes no difference. The CRA’s authority is tied to where the product is placed on the market, not where the manufacturer or its infrastructure is physically located.

This means if you sell your product to customers anywhere in the EU, it must comply with the CRA. A classic example is a product sold in Germany that relies on a remote server in the United States for its functionality. The whole system—both the physical product in Germany and the US-based server—must be fully compliant with CRA regulations.

Importers have a legal duty to verify this compliance before placing the product on the EU market. This makes global compliance a basic requirement for market access, rendering geography irrelevant to your obligations.

Navigating the complexities of the CRA and understanding its scope for your products can be a major challenge. Regulus provides a clear, step-by-step software platform to assess applicability, map requirements, and build your compliance documentation efficiently. Gain clarity and confidence in your path to the 2027 deadline by visiting https://goregulus.com.

La entrada CRA Remote Data Processing Solutions Scope Explained se publicó primero en Regulus.

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

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:

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 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.

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 automotive systems.

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’ 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.

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. 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.

La entrada Your Guide to CRA CE Marking Requirements se publicó primero en Regulus.

These new “digital watchdogs” can demand your technical documentation, order product recalls, and hit you with multi-million euro fines to enforce cybersecurity standards across the EU.

Understanding the New Digital Watchdogs

The Cyber Resilience Act isn’t just more paperwork. It kicks off a new era for digital product safety, enforced by powerful national regulators known as Market Surveillance Authorities (MSAs). These bodies are the engine room of the CRA’s enforcement strategy, responsible for making sure every product with digital elements sold in the EU is secure.

Think of an MSA as a new breed of digital safety inspector for the European Union. They now have the authority to proactively examine any product—from a smart thermostat to industrial control software—for potential security weaknesses, even if no incident has been reported. A practical example could be France’s ANSSI deciding to test the security of all connected baby monitors available on the French market to check for unauthorized access vulnerabilities.

The MSA’s Core Mandate

At its heart, an MSA’s mission is to shield the single market from insecure products. Their job is to check that manufacturers, importers, and distributors are meeting their obligations all the way through a product’s lifecycle.

This breaks down into three key activities:

• Verifying Compliance: Checking that products carry the correct CE marking and are backed by a complete and accurate EU Declaration of Conformity. For example, an MSA could purchase a popular smart lock from an online store and first check if the CE mark is present on the product and its packaging, and then request the Declaration of Conformity from the importer.
• Investigating Risks: Proactively testing products and demanding technical files to find vulnerabilities before they can be exploited. For instance, an authority could perform penetration testing on a new connected car’s infotainment system to see if it can be hacked to control critical functions.
• Enforcing Rules: Taking corrective actions against non-compliant products to get them off the market and protect consumers. A real-world scenario would be an MSA ordering a manufacturer to stop selling a line of smart TVs after discovering they transmit user data without encryption.

To truly grasp the scope of an MSA’s authority, you need to understand the principles of statutory interpretation, as these govern how their mandates are defined and ultimately put into practice.

An MSA’s power isn’t just reactive. They are empowered to conduct “sweeps” of specific product categories, such as IoT home devices or connected toys, to gauge the overall security level of the market and root out bad actors.

For instance, the Spanish National Cybersecurity Institute (INCIBE) could decide to investigate all smart plugs sold in Spain. They would have the power to request technical documentation, including risk assessments and vulnerability handling processes, from every single manufacturer.

If a manufacturer can’t produce this evidence, or if their product is found to be insecure, INCIBE can order an immediate sales ban. You can get more insight into what regulators expect by reading the European Commission’s CRA implementation guidance.

MSA Investigations: Information and Access Rights

Market Surveillance Authorities (MSAs) are armed with serious investigative powers to check for Cyber Resilience Act (CRA) compliance, and they aren’t just waiting for a problem to be reported. These authorities can proactively demand access to your company’s most sensitive technical data to make sure your products are secure from the ground up.

This proactive approach marks a fundamental shift. Instead of only reacting to incidents, MSAs are now empowered to run planned and unplanned audits to verify that your products conform to the regulation. This is a core part of the CRA market surveillance authorities powers, designed to catch security flaws before they can be widely exploited.

The Scope of Information Requests

When an MSA opens an investigation, its right to access information is incredibly broad. This is far from a simple box-ticking exercise; authorities have the power to dig deep into your product’s architecture and your company’s internal security processes.

They can demand a whole range of documents and data, including:

• Technical Documentation: Required under Annex VII of the CRA, this is the master file for your product’s compliance journey. It needs to contain everything from the product’s intended use and design to the results of your cybersecurity risk assessment.
• Software Bill of Materials (SBOM): An MSA will want to see a full inventory of all software components, covering everything from open-source libraries to commercial third-party code. This helps them assess your supply chain security and see how you handle vulnerabilities in your dependencies.
• Security Assessments and Test Reports: This includes solid proof from penetration tests, vulnerability scans, and secure code reviews. You must be able to show that you’ve actively looked for weaknesses in your product.
• Vulnerability Handling Processes: Authorities will carefully examine your internal procedures for finding, evaluating, and fixing vulnerabilities after your product is on the market.

In exceptional and fully justified cases, the CRA market surveillance authorities powers even extend to requesting access to your product’s source code. This is seen as a last resort, usually reserved for high-risk products when all other documentation isn’t enough to confirm compliance.

A Practical Example of an MSA Request

Imagine your company builds a popular line of connected thermostats sold across the EU. One morning, you get a formal information request from Spain’s National Cybersecurity Institute (INCIBE), the region’s designated MSA. The notice says they’re running a compliance check on smart home devices.

The request demands that within 10 business days, you provide the complete technical documentation for your main thermostat model. This includes the full SBOM, records of all security updates from the last 24 months, and a detailed report on how you fixed three specific Common Vulnerabilities and Exposures (CVEs) found in an open-source library used in your firmware.

This scenario shows you the level of detail and tight deadlines you could be up against. Failing to provide this information accurately and on time would be a direct breach of the CRA, leading to immediate corrective measures and possible fines.

Remote and Physical Product Access

Beyond asking for documents, the CRA market surveillance authorities powers give them the right to directly inspect and test your products. This can happen in a couple of ways.

First, an authority can carry out remote inspections. They might use network tools to check your product for open ports, weak encryption, or other security flaws that can be spotted from the outside. For instance, an MSA could use a tool like Shodan to scan for internet-connected devices from a specific manufacturer and test if they are using default, easily guessable passwords.

Second, they have the right to request or buy a product sample for physical evaluation. This lets them perform detailed laboratory testing, including reverse engineering and forensic analysis, to find hidden vulnerabilities that remote scanning would miss. If they uncover a serious risk, they can order you to take immediate action. A practical example is Germany’s BSI purchasing a connected doorbell, taking it to their lab, and using hardware-level attacks to extract its encryption keys.

These broad access rights are backed by real enforcement. You can discover more insights about the Cyber Resilience Act’s rollout on taylorwessing.com. This just goes to show how critical it is for manufacturers to have their documentation organised and ready for scrutiny at a moment’s notice.

The Consequences of Non-Compliance: Corrective Actions and Fines

Failing to meet your obligations under the Cyber Resilience Act isn’t a minor administrative slip-up. It’s an invitation for serious penalties that can directly threaten your market access and your bottom line. When a Market Surveillance Authority (MSA) identifies a non-compliant product, it has a powerful set of tools designed to remove that risk from the EU single market—swiftly and decisively.

Understanding these enforcement actions is central to grasping the full scope of CRA market surveillance authorities’ powers. The consequences aren’t just financial; they can stop your sales cold, inflict lasting damage on your brand, and force you into complex and costly logistical operations.

Product Withdrawal vs. Recall: A Critical Distinction

When an MSA finds a non-compliant product, its first priority is to contain the risk. The two main tools for this are product withdrawals and recalls, and it’s vital you understand the difference.

• Product Withdrawal: This is the first line of defence. An MSA can order you to stop the product from being made further available on the market. This action hits the supply chain, forcing distributors and retailers to pull your product from their physical and online shelves. For example, if a new model of a smart fridge is found to have a security flaw, the MSA can order all electronics stores and online retailers in the EU to immediately stop selling it.
• Product Recall: This is a much more drastic step, reserved for products that pose a significant cybersecurity risk and are already in the hands of end-users. A recall requires you to retrieve the product from customers—a far more complicated and expensive undertaking. For example, if a popular fitness tracker is found to have a vulnerability that leaks personal health data, the MSA could order the manufacturer to contact all registered users and arrange for the product to be returned for a fix or replacement.

Picture this: your company makes a popular IoT security camera. An MSA discovers a critical vulnerability that allows unauthorised remote access. They would first order a withdrawal to halt all new sales. If the vulnerability can’t be patched remotely and poses a severe risk, they would escalate to a recall, forcing you to contact every customer and arrange for their cameras to be returned.

Beyond these measures, MSAs can also mandate specific corrective actions. They could force you to issue a critical security patch by a strict deadline or require you to publish public disclosures about the vulnerability to ensure all users are aware of the risks.

The Staggering Financial Penalties

The CRA doesn’t just rely on corrective actions; it backs them up with some of the most significant financial penalties seen in product regulation, echoing the structure of the GDPR. The fines are deliberately designed to make non-compliance a far more expensive gamble than investing in security from the outset.

The regulation uses a tiered system for fines, based on the severity of the infringement. These penalties are calculated as either a maximum fixed sum or a percentage of your company’s total worldwide annual turnover from the preceding financial year—whichever is higher.

This approach gives MSAs the flexibility to penalise organisations proportionally. For a detailed breakdown of the violations that can trigger these sanctions, our guide on CRA penalties and enforcement actions offers more clarity.

CRA Enforcement Actions and Penalties at a Glance

The table below outlines the potential enforcement actions and the staggering financial penalties that an MSA can impose for non-compliance with the Cyber Resilience Act.

As the table shows, the penalties are structured to ensure that failing to invest in cybersecurity is simply not a viable business strategy. A practical example for the highest tier could be a software vendor that fails to patch a known, actively exploited vulnerability in their enterprise software, leading to a major data breach for their customers. The MSA could impose a fine of up to 2.5% of their global turnover for this severe negligence.

These are not just theoretical numbers. The powers of market surveillance authorities are already being put to use. As you can see from recent legal analyses of EU authority actions, this case highlights the very real financial stakes of getting CRA compliance wrong.

Navigating Cross-Border Enforcement in the EU

If you sell a non-compliant digital product in one EU country, you’ve just created a cybersecurity risk for all 27 member states. The EU’s single market is only as strong as its weakest link, which is precisely why the Cyber Resilience Act (CRA) builds powerful tools for cross-border cooperation and uniform enforcement.

This framework is designed to dismantle national silos and stop non-compliant manufacturers from hopping between countries to find a safe haven. For any business with a pan-European strategy, understanding these cooperative CRA market surveillance authorities powers is essential. It proves that compliance must be solid across the entire EU, not just in one or two key markets.

The Principle of Mutual Assistance

At the heart of the CRA's cross-border muscle is the principle of mutual assistance. This is a legal mechanism that allows a Market Surveillance Authority (MSA) in one country to formally request that an MSA in another country take action. It ensures enforcement can follow a non-compliant product, no matter where the manufacturer is based or where the product was first sold.

Think of it as a law enforcement pact for product security. If a product poses a risk anywhere in the EU, authorities can work together to pull it from the market everywhere.

An MSA can ask its counterpart to run inspections, demand your technical documentation, or even impose corrective measures like a product withdrawal on its behalf. This closes the loophole where a manufacturer might ignore an order from an authority in a country where it has no office or staff.

For example, imagine a software company in Ireland sells a new project management tool across the EU. If Germany’s MSA (the BSI) finds a critical vulnerability, its power doesn't stop at the German border. It can formally ask Ireland's MSA to investigate the company directly and, if needed, enforce a sales ban that applies across the entire market.

Intelligence Sharing and Coordinated Actions

For mutual assistance to work in practice, MSAs need to share intelligence. The CRA leans on established information-sharing networks to make sure an alert raised in one country is immediately visible to all others, triggering swift, coordinated responses.

The key platforms and groups making this happen include:

• EU Safety Gate (formerly RAPEX): A rapid alert system for dangerous non-food products. An alert about a non-compliant smart thermostat or a vulnerable software component gets circulated to all national authorities almost instantly. A practical example: if the Dutch MSA finds that a popular brand of connected light bulbs can be easily hijacked to join a botnet, they would issue a Safety Gate alert, and within hours, authorities in Poland, Italy, and Sweden could begin their own investigations or order retailers to stop sales.
• ADCO Groups (Administrative Cooperation Groups): These are expert groups where MSAs coordinate their market surveillance work for specific laws, including the CRA. They plan joint inspection projects and work to apply the rules consistently. For instance, the CRA ADCO might organize a "joint action" where multiple MSAs simultaneously test the security of mobile banking apps offered in their respective countries.

The data proves how cross-border cooperation multiplies the reach of CRA market surveillance authorities powers. For a closer look at the legal text, you can explore the European Cyber Resilience Act's legal text.

This integrated enforcement model sends a clear message: geography offers no protection from scrutiny. A flaw found by one authority quickly becomes a problem for you across the entire European Union.

Preparing Your Defence Against Enforcement

Knowing about MSA powers is one thing, but actively preparing for scrutiny is how you protect your business and maintain market access. A strong defensive posture isn't about scrambling to react when an inspector calls; it's about making readiness a part of your daily operations.

The best approach turns these complex regulatory duties into a manageable, repeatable plan. A solid defence is a continuous cycle built on three core activities: comprehensive documentation, vigilant monitoring, and a rapid response capability. Think of it as having your evidence organised and your team ready to act long before you're ever questioned.

This process flow shows how these core activities fit together in a strong CRA defensive strategy.

As the visual shows, this isn't a one-off project. It's a cycle that ensures you're always prepared for an inspection from market surveillance authorities.

Step 1: Establish Watertight Technical Documentation

Your technical documentation, as required by Annex VII of the CRA, is the absolute cornerstone of your defence. It's the first thing an MSA will demand to verify your product’s compliance. If that file is incomplete, disorganised, or out of date, your defence can crumble before it even begins.

A robust technical file isn't just a document dump. It must clearly contain:

• A Detailed Product Description: This should cover the product’s intended purpose, its complete architecture, and all software and firmware versions.
• The Cybersecurity Risk Assessment: This is your proof that you have methodically identified, evaluated, and mitigated potential security risks.
• A Complete Software Bill of Materials (SBOM): A full inventory of every single software component, from your own code to open-source libraries and third-party dependencies.
• Vulnerability Handling Processes: Clear, documented procedures that explain exactly how you discover, assess, and fix vulnerabilities after the product is on the market.

Using a dedicated compliance platform can make this far more manageable. For instance, a platform can help you generate a tailored requirements matrix and provide ready-to-use templates for Annex VII. This helps you systematically structure all the necessary evidence into an audit-ready CRA compliance evidence pack that you can present to an MSA on demand.

Step 2: Implement a Robust Post-Market Surveillance Process

Your duties don't stop once a product ships. The CRA mandates a continuous post-market surveillance process to monitor for new and emerging vulnerabilities. A weak or non-existent surveillance process is a huge red flag for MSAs, signalling that you aren't taking your ongoing security obligations seriously.

A practical workflow here should include:

1. Systematic Monitoring: Actively and continuously scan vulnerability databases (like the NVD), security feeds, and other intelligence sources for threats that could affect your product’s components. For example, if your product uses the OpenSSL library, your process should include daily checks for any new vulnerabilities reported for that library.
2. Triage and Assessment: When a potential vulnerability is identified, you need a process to promptly assess its severity (e.g., using CVSS scores) and actual impact on your product.
3. Clear Reporting Channels: Define an internal process for escalating significant vulnerabilities to the right teams for immediate remediation.
4. Coordinated Disclosure: Establish a clear workflow for handling the mandatory 24-hour reporting of actively exploited vulnerabilities to ENISA and the relevant national CSIRT.

Step 3: Define Your Response and Disclosure Workflow

When an MSA launches an investigation or a critical vulnerability is discovered, a chaotic, ad-hoc response can be just as damaging as the issue itself. A predefined workflow ensures you can respond with confidence and control, not panic.

This means assembling a dedicated response team well in advance, with representatives from legal, engineering, and compliance. Everyone should know their role. A practical example of a role would be the 'Legal Liaison', who is the sole point of contact for communicating with the MSA to avoid conflicting statements from different parts of the company.

It can also be useful to understand the legal mechanics for challenging an MSA's claims early in the process. For example, knowing the principles behind mastering the motion to dismiss can provide a solid framework for contesting unfounded allegations from a legal standpoint.

By turning these three defensive pillars into routine business operations, you transform CRA compliance from a daunting regulatory burden into a structured, manageable process that safeguards your access to the entire EU market.

Use this checklist to assess your organisation's readiness for an MSA inspection and overall CRA compliance. It's a simple way to see where you stand and what gaps need closing.

Your CRA Compliance Readiness Checklist

Once you have this foundation in place, you're not just compliant—you're resilient. You've built a system that not only meets regulatory demands but also makes your products fundamentally more secure.

How to Respond to an MSA Information Request

Receiving an official notice from a Market Surveillance Authority (MSA) can be unsettling, but your response sets the tone for the entire interaction. An information request isn’t an accusation; it’s a standard procedure under the CRA market surveillance authorities powers to verify compliance. A calm, organised and professional reply can make all the difference.

Think of it as an open-book exam where you’ve already done the homework. With your documentation in order and a clear plan, you can navigate the process confidently, demonstrating cooperation while protecting your organisation’s interests.

Your Step-by-Step Response Playbook

When an information request lands, the last thing you want is a panicked scramble. Instead, follow a structured process to ensure your response is timely, accurate and complete. A methodical approach shows the MSA that you are organised and take your compliance duties seriously.

1. Assemble Your Response Team: Immediately bring together your designated point people. This team should include representatives from legal, engineering (product security), and compliance. Each person has a critical role—legal to review the request’s scope, engineering to gather the technical data, and compliance to oversee the entire submission.

2. Verify the Request's Legitimacy: Before you do anything else, confirm the request is from a genuine MSA and falls within its legal mandate. For example, check that the email comes from an official government domain (like @bsi.bund.de for Germany's BSI) and cross-reference the contact person on the MSA's official website. This crucial first step stops you from accidentally sharing sensitive information with unauthorised parties.

3. Analyse and Clarify the Scope: Read the request carefully with your team. Pinpoint exactly which documents, data, and time periods are required. If any part of the request is ambiguous, it is perfectly acceptable—and often wise—to contact the MSA for clarification. A practical example: if the request asks for "all security test reports" but your product is five years old, you could ask, "Can you clarify if you require reports for all historical versions or just for versions released in the last 24 months?" A precise understanding prevents you from providing either too little or too much information.

4. Gather the Required Documents: This is where your proactive documentation efforts pay off. Pull the specific evidence from your technical file, such as the Software Bill of Materials (SBOM), risk assessments, vulnerability handling records and test reports. Ensure every piece of evidence directly addresses the MSA's query.

A well-organised company can pull a complete evidence pack in hours. A disorganised one might spend weeks searching through disconnected files and emails. That difference in response time and quality sends a powerful message to the authority about your company’s maturity.

A Tale of Two Responses

Consider two companies that both make smart lighting systems. Company A receives an MSA request and, using its compliance platform, generates a complete, audit-ready report with all requested documentation in under two days. Their response is prompt, professional and precise.

Company B, however, relies on spreadsheets and shared drives. The request triggers a frantic search for documents. Their final submission is late, incomplete and contains outdated information, immediately raising red flags for the MSA and inviting deeper scrutiny. For more details on what authorities expect, you can learn about the specific CRA reporting obligations under Article 14.

Answering Your Top Questions About CRA Enforcement

When it comes to the Cyber Resilience Act, the enforcement powers of national regulators are a major point of concern for many manufacturers. Let's tackle some of the most common questions we hear about what CRA market surveillance authorities can actually do.

Can an MSA Really Demand Access to Our Source Code?

Yes, they can. However, this is a power of last resort, not a routine check.

Article 41 of the CRA gives a Market Surveillance Authority (MSA) the right to request your source code, but only when it is considered strictly necessary to confirm whether a product is compliant. This is typically reserved for high-risk products where a critical vulnerability is suspected and reviewing the technical documentation isn't enough to get a clear picture.

Imagine a widely-used industrial controller is found to have a flaw that could take down critical infrastructure. If standard inspection methods fail to clarify the risk, an MSA might then demand to see the source code. This underscores how vital it is to maintain well-organised and documented codebases, just in case.

What If We Disagree with a Recall Decision?

You have the right to challenge it. Before an MSA can force a restrictive measure like a product recall, you are entitled to be heard and to present your own evidence to make your case.

If the authority still moves forward with the decision, both the CRA and national laws give you a path to challenge it in court. Be warned, though: this route is almost always expensive and time-consuming.

A practical example might be a smart home hub manufacturer that receives a recall order. They could challenge it by providing independent test reports showing that the vulnerability in question has already been patched via an over-the-air update for 99.8% of active devices, arguing that a full recall is disproportionate to the residual risk. The takeaway is clear: proactive compliance and rock-solid documentation are your best, and most cost-effective, lines of defence.

Do These Powers Only Apply to Hardware?

No. The CRA’s scope is extremely broad and covers all "products with digital elements." This is a crucial point to understand. It includes:

• Hardware with embedded software, like IoT devices and smart appliances. (e.g., a connected coffee machine)
• Standalone software, including mobile apps, desktop programs, and operating systems. (e.g., a photo editing software or a password manager)
• Firmware that controls how a piece of hardware operates. (e.g., the software running on a network router)

Whether you develop software, manufacture devices, or import them, if your product has a digital component and you sell it in the EU, you are subject to these enforcement powers.

Are Importers Held to the Same Standard?

While the manufacturer holds primary responsibility for a product’s conformity, importers and distributors have their own distinct and critical obligations. They are required to verify that the manufacturer has done their job, make sure the product carries the CE marking, and cooperate fully with MSAs during any investigation.

An MSA can take action against any economic operator in the supply chain. If an importer brings a non-compliant product into the EU market, they can be held directly accountable and face fines or orders to withdraw the product. For instance, if a European importer distributes a non-compliant drone from a non-EU manufacturer, the MSA can fine the importer and order them to manage the product withdrawal from all retailers, even though they didn't create the product.

Navigating CRA compliance can be complex, but Regulus provides the clarity and tools you need. Our platform helps you assess applicability, generate tailored requirement matrices, and build audit-ready technical documentation to confidently meet your obligations. Prepare for the CRA with Regulus.

La entrada CRA Market Surveillance Authorities Powers: A Practical Guide se publicó primero en Regulus.

This initial “early warning” is a cornerstone of the CRA. It’s designed to kickstart a rapid, coordinated response to cyber threats as they emerge across the European Union. For example, if your company discovers that a flaw in your smart security cameras is being used by attackers to view live feeds, the CRA mandates you alert authorities within a day, not after you’ve developed a fix.

Why CRA CSIRT Reporting Is Now Mission Critical

The EU’s Cyber Resilience Act (CRA) isn’t just another set of guidelines; it fundamentally rewires the cybersecurity obligations for any organisation selling products with digital elements in the EU market. It marks a major shift away from voluntary best efforts and toward a legally binding framework.

Prompt, transparent communication is no longer just good practice—it’s the law. The CRA’s CSIRT reporting requirements are the operational heart of this new regulation, turning a technical task into a critical business function.

Think of it as a coordinated emergency response network for digital products. When a serious vulnerability is discovered and exploited, it triggers a mandatory chain of notifications that pulls everyone—the manufacturer, national authorities, and ENISA—into alignment. For instance, if a German manufacturer of industrial controllers finds an exploited vulnerability, their report to Germany’s BSI (the national CSIRT) is quickly shared with other EU countries via ENISA, protecting critical infrastructure across the continent.

Under the CRA, silence is no longer an option. Failing to report a known exploited vulnerability is a direct violation that can result in significant penalties and market exclusion. This makes CSIRT reporting a mission-critical function for maintaining EU market access.

The Key Players in CRA Reporting

To stay compliant, you first need to understand who you’re reporting to. Your process will primarily involve two key bodies:

• National CSIRTs: Each EU member state designates a CSIRT to act as the primary contact point for manufacturers within its jurisdiction. When you discover a reportable incident, this is your first port of call. For a company headquartered in Spain, this role is handled by INCIBE. For a business in Ireland, it’s the NCSC-IE.
• ENISA (The EU Agency for Cybersecurity): ENISA acts as the central coordinator for the entire system. Once you’ve notified your national CSIRT, that information is channelled to ENISA, which then ensures all other relevant member states are alerted. This hub-and-spoke model saves you from the nightmare of reporting to 27 different countries individually.

Grasping why these obligations are so critical comes down to understanding the principles of regulatory compliance risk management. The CRA effectively elevates product vulnerabilities from purely technical issues to major business risks with serious legal and financial consequences.

Core Reporting Triggers and Initial Deadlines

The CRA sets out clear triggers that activate your duty to report. The table below gives a high-level summary of the primary events that mandate a report and the extremely tight initial notification window.

CRA Reporting Triggers and Initial Deadlines

This table summarises the primary events that mandate a report to a CSIRT under the Cyber Resilience Act and the first notification window.

As you can see, the timelines demand well-rehearsed internal processes. There’s simply no time to figure it out once an incident happens. You can read more about the current state of play regarding these regulations.

Who Reports and What Triggers a Report

The Cyber Resilience Act casts a wide net, fundamentally changing how security responsibilities are managed. For any technology company, the first two questions are always the most urgent: ‘Does this apply to my products?’ and ‘Which specific events force us to act immediately?’ Nailing down the answers is the foundation for building a compliant reporting process.

The answer to that first question is refreshingly direct. The reporting obligation falls squarely on the manufacturer of any ‘product with digital elements’ placed on the European Union market. This is a deliberately broad definition, designed to cover today's massive ecosystem of connected technology.

That means everything from consumer gadgets like smart speakers and connected thermostats to complex industrial control systems and enterprise software suites. If you create a product with software or firmware that can connect to a network and you sell it in the EU, the CRA’s reporting duties apply to you. For example, a French company that manufactures smart lighting systems sold across Europe is considered a manufacturer and must comply.

Identifying Your Reporting Triggers

Not every bug or glitch demands a 24-hour alert to European authorities. The CRA makes a crucial distinction between minor issues and significant threats that require a coordinated response. Your primary triggers for a CSIRT report are:

• An actively exploited vulnerability: This is a security flaw in your product that attackers are already aware of and are actively using to compromise systems.
• A severe incident: This refers to a security event that has a significant impact on your product or its users, even if the root cause isn't a specific vulnerability in your code. A practical example could be a misconfigured cloud storage bucket exposing sensitive user data from your connected product.

Think of it as the difference between a leaky tap and a burst water main. A minor UI bug is a leaky tap—you fix it in the next update. But a vulnerability letting attackers remotely seize control of thousands of smart locks? That's a burst water main demanding an immediate, all-hands-on-deck emergency response. This is precisely what triggers the CRA CSIRT reporting requirements.

According to the CRA, an ‘actively exploited vulnerability’ means a vulnerability for which there is reliable evidence that an attacker has leveraged it to compromise a system or network. This official definition grounds your response in observable reality, not theoretical risk.

Practical Examples of Reporting Triggers

Learning to distinguish between a routine bug and a reportable incident is a critical skill your team must develop. Let’s walk through some practical examples to make the distinction crystal clear.

Scenario A: The Non-Trigger

A user reports that a specific menu in your photo-editing software occasionally freezes, requiring a restart.

• Analysis: This is a performance or usability bug. It doesn't compromise security in any meaningful way (confidentiality, integrity, or availability). This would be handled through your normal patching cycle, not a CSIRT report.

Scenario B: The Clear Trigger

Your security team discovers a flaw in your smart camera’s firmware that allows an unauthenticated attacker to access the live video feed. Online forums show proof-of-concept code and chatter from threat actors discussing how to use it.

• Analysis: This is a textbook example of an actively exploited vulnerability. It has a severe impact on user privacy and confidentiality. This mandates an immediate 24-hour notification to your CSIRT and ENISA.

Understanding this distinction is vital. As an ES-based IoT vendor, for example, you must grasp the CRA's CSIRT stats: from 2026, you will report exploited vulnerabilities and severe incidents affecting products with digital elements, such as firmware flaws causing impacts for over 1,000 users. This represents a historical shift; pre-CRA, vulnerability disclosure in Spain had an average seven-day lag, but this will now be under 72 hours, a change which ENISA simulations project could cut exploit rates by 45%. This is crucial, given that a 2025 INCIBE report noted 85% of ES attacks hit unpatched IoT devices. You can read more about the current state of play regarding these regulations to better prepare your teams.

Under the Cyber Resilience Act, time isn't just a factor—it's the single most critical element of compliance. The regulation introduces a fast-paced, multi-stage reporting lifecycle that forces organisations to act with incredible speed and precision the moment a serious issue comes to light.

This isn't your typical technical clean-up. Incident response under the CRA is a highly structured communication protocol with European authorities. You have to master three key reporting milestones: the 24-hour 'early warning', the 72-hour 'main notification', and the subsequent final reports. Getting this rhythm right is fundamental to meeting your CRA CSIRT reporting requirements.

The flow chart below maps out the basic process, from a manufacturer's discovery to the mandatory reporting action.

This simple diagram highlights a core principle of the CRA: awareness of a trigger event immediately starts the clock, and that clock leads directly to a mandatory report.

The 24-Hour Early Warning

The second you become aware of either an actively exploited vulnerability or a severe security incident, the clock starts ticking. You have just 24 hours to submit an "early warning" to both your designated national CSIRT and to ENISA.

This initial report isn't meant to be a full forensic analysis. Think of it as an emergency flare. Its primary job is to give authorities a high-level, immediate heads-up so they can start coordinating a potential EU-wide response, even before you have all the answers.

Let's say you manufacture smart thermostats. Your security team finds forum posts with proof-of-concept code that lets attackers remotely control home heating systems, and your own telemetry confirms it's being actively used in the wild. You must send an early warning within 24 hours of that discovery.

Your initial alert just needs the basics:

• Your company’s name and contact details.
• The affected product name and version (e.g., "SmartComfort Thermostat Model X, firmware v2.1").
• A brief, high-level description of the vulnerability or incident.
• Any immediate mitigation advice you can give to users.

The 72-Hour Main Notification

After sending the early warning, your team needs to dig deeper. Within 72 hours of that initial awareness, you have to follow up with a "main notification" that adds crucial technical context to your first report.

This is where you provide the substance. It requires a much more thorough assessment of the vulnerability's nature, severity, and potential impact.

Going back to our smart thermostat example, the 72-hour report would need to add some serious specifics:

• A technical description of the vulnerability, including its type (e.g., "unauthenticated remote code execution").
• The estimated severity, which often means including a CVSS (Common Vulnerability Scoring System) score. A flaw like this would almost certainly be rated 'Critical'.
• Details on the potential impact, like the ability for attackers to crank up heating to dangerous levels or shut it down completely in the dead of winter.

Final Reports and Resolution

The CRA reporting clock doesn't stop at 72 hours. The final stage is all about providing closure and detailing the long-term fix, though the deadlines here are conditional.

Imagine your team detects an actively exploited vulnerability in one of your connected IoT devices. Within 24 hours of becoming aware, you notify the designated CSIRT and ENISA. By the 72-hour mark, you submit the more detailed 'main' notification. Because the vulnerability was actively exploited, you must then follow up with a final report within 14 days of making a patch or mitigation available. For severe incidents, the final wrap-up is due one month after the 72-hour report.

A complete final report proves the threat has been properly handled. It should cover the root cause, the mitigation steps you took, and clear instructions for users to apply the patch. To get a better handle on the full timeline, check out our guide on important CRA deadlines between 2025 and 2027.

How to Report: Process and Data Requirements

Knowing you have to report an incident is one thing; understanding the exact process, formats, and deadlines is a completely different challenge. The Cyber Resilience Act doesn't just deal in high-level principles—it specifies the practical mechanics of how and what you need to communicate during a security event.

The whole system is designed for efficiency. Instead of a chaotic scramble to notify multiple national authorities, the CRA establishes a single point of contact for all incident and vulnerability reporting.

At the core of this system is ENISA's single reporting platform. This will be the one and only place you submit your notifications. You won’t have to waste time figuring out which national CSIRT needs what information. Your job is to get one clear, comprehensive report into the system, which then handles the coordination.

The Coordinated Reporting Mechanism

The CRA's process is built on a simple but powerful idea: report once, inform many. This completely removes the administrative nightmare of individually notifying every single EU member state that might be affected by an incident.

In practice, the reporting cascade works like this:

1. You submit your full report through the ENISA single reporting platform. For example, your incident response lead logs into the secure portal and fills out the web-based form.
2. The platform automatically directs your submission to the designated national CSIRT coordinator for your organisation.
3. Your national CSIRT then reviews the report and disseminates it to other relevant national CSIRTs and EU bodies through the same platform.

This coordinated model ensures every necessary authority gets the alert without burying your team in bureaucracy during a crisis. It frees you up to focus on what really matters: investigating the incident and shipping a fix.

Required Data for Your Notifications

An effective report is all about providing the right information from the start. Vague or incomplete submissions just create more work, leading to follow-up questions and delays when time is critical. To be prepared, you need to know exactly which data fields are mandatory for both your 24-hour and 72-hour notifications.

Let's walk through a scenario. It's 2027, and your company's embedded software, shipped across the EU, has a severe incident affecting over 10,000 users in Spain and Portugal. The CRA mandates a very specific escalation path. You must notify your national CSIRT coordinator and ENISA via the single platform. Your 24-hour early warning alerts them to the breach, but it's the 72-hour main report that must detail the impact on confidentiality, integrity, or availability.

For a company based in Spain, the national CSIRT coordinator is INCIBE. They would handle the initial intake and use the ENISA platform to share the cross-border details with their counterparts in Portugal. This coordination is critical, especially since statistics show that 65% of IoT attacks often span multiple borders. Learn more about the EU's approach to product cybersecurity compliance.

Your main (72-hour) notification must be structured and packed with detail. The table below gives you a sample template you can use as a tangible starting point for building your internal reporting processes.

Sample CRA CSIRT Notification Template

This table shows an example structure for the main (72-hour) notification, outlining the key data fields manufacturers must provide.

Having this data ready to go is non-negotiable. Building a complete CRA compliance evidence pack in advance ensures your team can pull this information together quickly when the 72-hour clock is ticking.

Your Practical Compliance Checklist for 2027

Understanding the CRA's legal text is one thing; operational readiness is what actually guarantees compliance. When you're facing a 24-hour deadline, you don't have time to figure things out during a live incident. This checklist breaks down the theory into a practical implementation plan.

1. Establish Key Contacts and Teams

First, build the human infrastructure for reporting. You need to know who to call externally and who’s responsible internally long before a crisis hits.

• Identify Your Lead National CSIRT: Your main reporting contact is the designated CSIRT coordinator in the EU member state where your main establishment is located. If your company is headquartered in Spain, for example, this is INCIBE. Find your designated CSIRT now.
• Form a Dedicated Response Team: Create an internal incident response team with crystal-clear roles. For example, specify that the Head of Product Security is responsible for assessing severity, a technical writer drafts the report, and the CISO gives final approval before submission.

2. Develop and Pre-Approve Reporting Templates

That 24-hour clock starts ticking fast. You won't have time to write a report from scratch. Preparing templates in advance is one of the single most effective ways to guarantee both speed and accuracy.

Use the sample template from the previous section as a starting point. Create pre-filled documents for both the 24-hour "early warning" and the 72-hour "main notification". Populate them with your company details, product lines, and contact information. Get these templates approved by legal and management now, so they are ready when you need them.

A pre-approved template is more than a document; it's a pre-negotiated consensus. It eliminates internal debates over wording and content during a high-pressure event, allowing your team to focus solely on the technical facts of the incident.

This step alone can slash your response time, making those tight deadlines far more manageable. For organisations still mapping out their compliance journey, it's also helpful to explore the role of CRA harmonised standards in providing a clear framework for these processes.

3. Implement Monitoring and Automation Tools

You can't report a vulnerability you don't know about. Robust monitoring is the bedrock of compliance. This means putting tools and processes in place that give you continuous visibility into your products' security posture.

• Continuous Vulnerability Scanning: Use Software Composition Analysis (SCA) tools to constantly monitor your code and its dependencies for newly disclosed vulnerabilities.
• Automate Draft Reports: Configure your security tooling to automatically generate a draft incident report whenever a high-severity or actively exploited vulnerability pops up in a production environment. For instance, if your SCA tool flags a critical flaw in a library like OpenSSL that is known to be exploited, it can trigger a ticket in your system with a pre-populated report draft.

4. Run Realistic Simulation Drills

A plan on paper is not enough. You have to pressure-test it. Regular simulation drills are the only way to build the muscle memory your team needs to meet the CRA’s demanding timelines.

Run tabletop exercises that simulate a real-world discovery of an actively exploited vulnerability. Start the 24-hour clock and make your team execute the full reporting process. A practical drill could involve a scenario where a security researcher privately discloses a critical remote code execution flaw in your flagship product. The team must then race against the simulated clock to validate the finding, draft the early warning, get approval, and submit it.

5. Integrate CRA into Broader Security Policies

Finally, make sure your CRA reporting process doesn't exist in a silo. It must be woven into your organisation's bigger security and disclosure frameworks.

Your Coordinated Vulnerability Disclosure (CVD) policy should specify that any incoming report meeting the CRA criteria immediately triggers your internal CSIRT notification workflow. Likewise, your post-market surveillance activities need a clear protocol for escalating security findings to the incident response team. For specialised assistance in meeting all regulatory demands, explore dedicated Compliance Solutions.

Your CRA Reporting Questions, Answered

Once you move from the legal text of the Cyber Resilience Act to building real-world processes, practical questions always come up. The theory is one thing; day-to-day operational reality is another. Getting the details right in these grey areas is what separates a smooth compliance process from a scramble.

Here, we'll tackle some of the most common and pressing questions teams have about CRA reporting obligations.

What Happens If We Notify the CSIRT but a Patch Is Not Ready?

The CRA prioritises transparency and proactive communication. If you hit the reporting deadline but your patch isn’t ready, you must still submit the report on time. Your duty is to be upfront about the situation.

In your report, you need to give a clear status update. For example: "We have confirmed the vulnerability and its severity. A patch is currently in development and undergoing QA testing. We anticipate releasing firmware version 2.5.1 to address this issue within the next 7 days. In the meantime, we advise users to disable remote access features." This kind of honest communication is far better than silence.

Does Reporting to a CSIRT Make the Vulnerability Public Immediately?

No, it doesn't. The initial reports you send to your national CSIRT and ENISA are confidential. This isn't about naming and shaming; the immediate goal is to allow a coordinated, behind-the-scenes response among national authorities and to figure out the potential EU-wide impact.

The entire process is built to align with Coordinated Vulnerability Disclosure (CVD) principles. This means public disclosure is usually held back until a patch is developed and available, preventing attackers from getting a roadmap to an exploit before users can protect themselves.

How Does This Relate to Our Existing Bug Bounty Programme?

Think of your bug bounty programme as a critical input to your CRA compliance workflow. It's one of the best tools you have for finding serious vulnerabilities before attackers do.

When a researcher reports a vulnerability through your programme that fits the CRA criteria—for instance, it's being 'actively exploited' or is a 'severe incident'—that's when your 24-hour reporting clock starts ticking. You absolutely must have a bulletproof process to escalate these findings from your bug bounty platform to your incident response team, kicking off the formal CSIRT reporting workflow without any delay. A practical example would be a researcher submitting a video proof-of-concept showing how to bypass authentication on your smart doorbell. The moment your team validates that it works, the clock starts.

What Are Our Responsibilities As an Importer or Distributor?

While the manufacturer carries the primary reporting burden, importers and distributors are not off the hook. You are a crucial link in the safety chain and have your own distinct obligations. If you learn about a reportable incident involving a product you’re selling on the EU market, you are legally required to inform the manufacturer 'without undue delay.'

For example, if a large retail chain acting as an importer receives multiple customer complaints about their smart home hubs being hacked, they cannot ignore it. They must promptly notify the product's manufacturer so the CRA reporting process can be initiated. Turning a blind eye to this could leave you exposed to penalties and significant legal liability.

Regulus provides a unified platform to help you navigate the complexities of the Cyber Resilience Act. Our solution helps you assess applicability, classify products, and generate a tailored requirements matrix, including ready-to-use templates for documentation and a step-by-step roadmap to turn findings into an actionable compliance plan. Gain clarity, reduce costs, and confidently place compliant products on the European market with our software, which you can explore at https://goregulus.com.

La entrada A Practical Guide to CRA CSIRT Reporting Requirements se publicó primero en Regulus.

Decoding the CRA Substantial Modification Definition

Think of it like renovating a house. Painting a room or fixing a faucet is just routine maintenance; you don’t need to call the building inspector. But if you decide to add an extension or knock down a structural wall, you’ve fundamentally changed the building. That kind of work demands new plans, new permits, and new inspections.

The same logic applies to digital products under the CRA. A security patch or a minor bug fix is just routine upkeep. But if an update alters the product’s core purpose, introduces new risks, or weakens its security posture, it crosses the line into a substantial modification. For manufacturers, understanding precisely where that line is drawn is a major compliance challenge.

The Legal Foundation

The CRA establishes this compliance trigger in Article 3(30). A substantial modification happens when a change made after the product is on the market either impacts its compliance with the essential cybersecurity requirements in Annex I or alters its original intended purpose.

The consequences are significant. Anyone making such a change effectively becomes the manufacturer, inheriting all the associated obligations. This means new documentation, a fresh security assessment, and updated conformity procedures.

Practical Example: An importer takes a batch of smart home hubs and, before selling them, installs custom firmware that allows the hubs to control industrial equipment. This is a substantial modification. The importer is now considered the “manufacturer” under the CRA and is responsible for a full new conformity assessment, even though they didn’t build the original device.

Drawing the Line Between Updates and Modifications

The good news is that not every change forces you to restart your compliance journey. The key is distinguishing between routine, non-substantial updates and fundamental, substantial modifications.

To make this distinction clearer, the table below compares different types of changes and how they are typically classified under the CRA.

Substantial Modification vs. Routine Update Under the CRA

This table provides a clear comparison of changes that are considered substantial modifications versus those classified as routine, non-substantial updates, helping manufacturers quickly assess their product changes.

This principle of re-evaluating risk based on significant change is becoming a common theme in technology regulation. For context, you can see similar concepts emerging in the California AI law, where modifications to AI systems can also trigger new obligations.

Ultimately, correctly identifying a substantial modification is more than a box-ticking exercise. It’s about maintaining a clear, defensible, and continuous compliance strategy throughout your product’s lifecycle. For more details on the broader regulatory expectations, see our guide on the European Commission’s CRA implementation guidance.

The Two Main Triggers for a Substantial Modification

When you’re trying to figure out if a change to your product qualifies as a substantial modification under the Cyber Resilience Act, it really boils down to two key questions. Getting the CRA substantial modification definition right means understanding these triggers inside and out, as they’re the litmus test for deciding if an update is just routine maintenance or something that resets your compliance clock.

An update crosses the line into a substantial modification if it does one of two things:

• It alters the product’s original intended purpose.
• It changes the product in a way that negatively affects its compliance with the CRA’s essential security requirements.

If your update trips either of these wires, you’ve almost certainly made a substantial modification. Let’s break down exactly what each of these means with some real-world examples.

Trigger 1: Changing the Intended Purpose

The intended purpose is the bedrock of your product’s original risk assessment and compliance strategy. It defines what your product is meant to do, who it’s for, and the environment it’s designed to operate in. As soon as you push an update that expands this scope, you’ve fundamentally changed the product’s risk profile.

Practical Example: A smart camera is originally marketed for indoor home monitoring. Its intended purpose is clear: helping a family keep an eye on their living room. A firmware update is released that adds features for outdoor, all-weather surveillance and integrates with a commercial security firm’s monitoring platform.

This is a substantial modification. The change expands the original “use, context, and conditions of use,” turning a simple home gadget into a commercial-grade security tool. This isn’t just a new feature; it’s a completely new job for the product. The risks tied to a commercial security system—like data privacy in public spaces or resilience against sophisticated, targeted attacks—are miles apart from those of a basic indoor camera. That shift in purpose makes the original security assessment obsolete.

Trigger 2: Affecting Security Compliance

The second trigger is any change that weakens the product’s ability to meet the essential cybersecurity requirements laid out in Annex I of the CRA. These requirements are the technical core of the regulation, covering everything from secure-by-design principles to vulnerability management.

A change becomes substantial if it degrades the product’s security posture or introduces new, unassessed risks.

Practical Example: A developer of a connected industrial sensor releases an update. To boost data processing speed, the update disables Transport Layer Security (TLS) encryption for data sent to the cloud, reverting to an unencrypted protocol.

This move has an immediate and direct impact on compliance. By stripping away a critical security control (encryption in transit), the developer has left data exposed to interception. This compromises one of the CRA’s core security principles, making the change a substantial modification. A new, comprehensive conformity assessment would be mandatory. You can find out what that involves in our guide on how to perform a CRA risk assessment.

Distinguishing these triggers from routine work has been a major point of discussion for the industry. It’s now clear that standard security patches, bug fixes, and minor functional tweaks like UI adjustments do not count. However, any change that introduces features handling sensitive data, alters security configurations, or adds new functions in a way that increases cybersecurity risk will almost always cross the substantial modification threshold.

Real-World Examples of Substantial Modifications

The theory behind a substantial modification is one thing, but spotting it in the wild during a hectic development cycle is another. That grey area between a routine patch and a change that forces a full re-assessment is where many product teams will get caught out.

To really understand where the CRA substantial modification definition draws the line, we need to move from abstract rules to concrete scenarios. Let’s look at what this means for software, firmware, and hardware, linking each example back to the core triggers: changing the intended purpose or degrading the product’s ability to meet security requirements.

Software Modification Adding a Sensitive Feature

Let’s start with a common software scenario. A company has a simple messaging app for internal teams, designed and assessed for exchanging basic text on a trusted corporate network. The initial risk assessment was straightforward, focusing on a limited, low-risk use case.

Then, marketing decides the app needs a new file-sharing feature. The update lets users upload documents and share them directly with external business partners.

This isn’t just a feature bump; it’s a clear substantial modification. The reasoning is twofold:

• Change in Intended Purpose: The app has morphed from an internal chat tool into an external collaboration platform. This new function was completely outside the scope of the original conformity assessment.
• Change in Data Handling & Risk Profile: The product now handles potentially sensitive documents and transmits them outside the trusted network. This introduces a whole new class of risks—data exfiltration, unauthorised access by third parties—that the original security model never accounted for.

Because the product’s risk profile has fundamentally changed, the original assessment is obsolete. A new, full conformity assessment is required to address the security implications of this new functionality.

Practical Example: By adding a feature that processes new, more sensitive data types (e.g., financial reports, legal contracts) and expands the product’s use case to external collaboration, the developer has crossed the substantial modification threshold. The product’s core function and associated risks have been fundamentally altered.

Firmware Modification Enabling New Connectivity

Now for a classic firmware example. A manufacturer makes industrial sensors used in factories to monitor machine temperatures. Their security model is simple because the product is designed for one thing: connecting to a private, air-gapped industrial network via an Ethernet cable. It’s never supposed to touch the public internet.

Later, the company pushes a firmware update that activates a dormant Wi-Fi chip inside the device. This seemingly minor change allows the sensor to connect directly to the internet for remote monitoring.

This is a textbook substantial modification. The original intended purpose was local monitoring in a physically secure, isolated environment.

• Change in Context of Use: The update drags the product from a controlled private network into the hostile, open environment of the public internet.
• Impact on Security Compliance: This instantly creates a massive new attack surface. The security controls that were perfectly adequate for an isolated device are now dangerously insufficient for one exposed to global threats. This directly impacts compliance with the CRA’s essential security requirements.

From a cybersecurity standpoint, this update has created an entirely new product. The manufacturer must now perform a full conformity re-assessment to prove it can withstand the threats of its new, internet-facing role.

Hardware Modification Swapping a Critical Component

Finally, let’s look at a hardware change that trips the wire. A company builds a popular smart lock for homes. A key part of its security architecture, and a central feature in its CRA technical file, is a certified secure element (SE) chip that stores cryptographic keys.

To cut costs, the product team decides to swap out the high-quality SE for a cheaper, general-purpose microcontroller that handles cryptography in software. To the end-user, the lock looks and works exactly the same.

Under the surface, however, this is a major substantial modification.

The intended purpose—locking a door—hasn’t changed at all. But the product’s ability to meet the CRA’s essential security requirements has been critically weakened. The original SE provided hardware-level protection against physical tampering and sophisticated side-channel attacks. The new, cheaper component offers no such guarantees, making the all-important cryptographic keys far more vulnerable.

This change invalidates the security claims made in the original conformity assessment. The manufacturer must go back to the beginning and re-certify the product with its new, less secure internal architecture.

Consequences of Making a Substantial Modification

So, you’ve made a change to your product. The big question is: does it count as a substantial modification under the Cyber Resilience Act? If the answer is yes, this isn’t just a minor administrative task—it’s a full compliance reset.

Making a substantial modification sets off a chain reaction of duties. It effectively treats your updated product as if it were brand new, forcing you to re-validate its security from the ground up.

The moment a change gets this classification, the person or company that made it takes on all the legal responsibilities of the original manufacturer. This is a critical point. Even if you’re an importer, a distributor, or a third-party integrator, making that change puts you squarely in the manufacturer’s shoes, along with every single obligation that comes with the title.

The Compliance Domino Effect

The most immediate consequence is that the product must undergo a completely new conformity assessment. The original assessment, along with all its supporting evidence and documentation, is no longer valid for the modified product. You have to start the entire process over again to prove the product meets the CRA’s essential cybersecurity requirements.

This isn’t just a paperwork exercise. It means a deep re-evaluation of the product’s security architecture, its risk profile, and how it handles data. Following this new assessment, you must create and sign a new EU Declaration of Conformity for the modified version. Our detailed guide on the CRA Declaration of Conformity explains the specific requirements for this document.

Overhauling Your Technical Documentation

Alongside the new assessment, your technical documentation needs a complete overhaul. You can’t just add an addendum; you must update the entire file to reflect the product’s new state. This includes:

• Revising the product description to include its new intended purpose or features.
• Updating the risk assessment to account for any new threats and vulnerabilities introduced by the modification.
• Documenting the new security architecture, including any new components or changed configurations.
• Providing evidence from the new conformity assessment to support your compliance claims.

This reset ensures that market surveillance authorities have a complete and accurate picture of the product as it currently exists on the market, not as it was originally designed.

Practical Example: The entity performing a substantial modification inherits the full legal weight of a manufacturer under the CRA. For instance, if a car mechanic flashes the engine control unit (ECU) of a car with software that fundamentally changes its performance and emissions controls, that mechanic may be deemed the manufacturer of the modified ECU, bearing all CRA obligations for that change. This underscores why correctly classifying a change is one of the most critical decisions a company can make.

The Impact on Hardware and Supply Chains

This principle extends deep into the supply chain, creating complex challenges. For hardware manufacturers, substantial modification rules apply not only to firmware and software but also to hardware revisions.

Practical Example: A manufacturer of network routers faces a chip shortage and decides to replace the original network interface controller (NIC) with a different, uncertified one from a new supplier. Even if it seems functionally equivalent, this hardware swap is a substantial modification because the security properties of the new chip have not been assessed, potentially introducing new vulnerabilities. This triggers a full reassessment and can seriously complicate compliance across distributed EU supply chains.

Ultimately, a substantial modification is a high-stakes event. It demands a significant investment of time and resources to re-establish compliance and carries serious legal responsibility. This makes the initial assessment of any product change a crucial step in managing your regulatory risk under the CRA.

A Simple Checklist for Assessing Product Changes

The decision tree above gives you the high-level workflow. Every change you make to a product has to be scrutinised to see if it’s substantial, which in turn dictates whether you need a new conformity assessment. This visual flow highlights why a structured evaluation process is so critical for every single update.

Of course, moving from a flowchart to your daily workflow is what really matters for consistent compliance. To figure out if a planned update crosses into substantial territory, your team needs a simple, repeatable process. This checklist offers a series of direct questions to guide your internal assessment for any proposed change.

Answering “yes” to any of these questions is a strong signal that you are dealing with a substantial modification. That means you’ll most likely need to perform a new conformity assessment and take on all the manufacturer’s obligations for the modified product.

Question 1: Does the Change Alter the Original Intended Purpose?

The intended purpose is the bedrock of your original CRA compliance. Any change that expands this scope demands careful review. You need to ask if the update allows the product to be used in a new environment, for a completely different task, or by a new type of user.

Practical Example: A ‘yes’ here is a major red flag. Imagine updating a consumer-grade smart plug with firmware that lets it manage high-load industrial machinery. This changes its intended purpose from simple home convenience to factory automation, fundamentally altering the product’s risk profile and making your original assessment invalid.

Question 2: Does It Introduce New Ways of Handling Data?

Data is the lifeblood of cybersecurity. You absolutely must ask if the change alters how the product collects, processes, or transmits data—especially personal or sensitive information. Does it start gathering a new category of data that wasn’t covered in your original assessment?

Practical Example: A fitness tracking app gets an update to collect detailed GPS location history to suggest new running routes. Previously, it only tracked steps and heart rate. That’s a clear ‘yes’. The app now handles sensitive geolocation data, creating new privacy and security risks that demand a fresh assessment to stay compliant with the CRA.

Question 3: Does It Weaken or Remove a Security Feature?

Sometimes, changes are made to boost performance or improve usability, but they come at the expense of security. You have to scrutinise any update that disables, bypasses, or weakens an existing security control, such as encryption, access controls, or secure boot mechanisms.

Practical Example: To simplify user login, a software update for a business application replaces mandatory two-factor authentication (2FA) with a simple username/password system. This is a substantial modification because it removes a critical security control, directly weakening the product’s security posture. A good guide on mastering information security risk assessment can help you evaluate these risks systematically.

Question 4: Does It Add a New Third-Party Component?

Modern products are built on incredibly complex supply chains. Ask whether your update integrates a new third-party software library, a hardware component, or an API. If it does, you are effectively inheriting the security posture of that component.

Practical Example: A video-conferencing application adds a new AI-powered transcription feature by integrating an open-source library from an unknown developer. If this library has not been properly vetted for security vulnerabilities, its inclusion could introduce significant new risks into the application, potentially qualifying the update as a substantial modification.

A ‘yes’ means you must perform due diligence on the new component’s security. By creating a structured process around these questions, you build a defensible and repeatable workflow. For a more exhaustive set of checks, you might be interested in our complete CRA compliance checklist to guide your team.

How to Streamline Your CRA Compliance Process

Trying to manage your Cyber Resilience Act compliance using spreadsheets and manual trackers is a recipe for trouble. It’s not just inefficient; it’s risky. Deciding whether a change is a routine update or a substantial modification demands a consistent, documented process—something that’s incredibly difficult to maintain by hand. This is where a dedicated compliance platform stops being a luxury and becomes a core part of your strategy.

A platform like Regulus is built to manage this exact kind of complexity. Its primary job is to help you create a clear, official baseline for each product. By documenting the product’s original intended purpose and security features in one central place, you build a solid foundation to measure all future changes against.

Establishing a Clear Baseline

The first step toward simplifying compliance is to nail down what your product is supposed to do. Without a clearly defined intended purpose, every change turns into a subjective argument. A compliance platform provides built-in documentation templates and evidence management tools to formalise this baseline.

This process gives your team clarity, cuts down on human error, and creates a robust audit trail for market authorities.

The platform screenshot below shows how requirements can be mapped and tracked, giving you a clear view of your compliance status at a glance.

This dashboard centralises all CRA obligations, making it easy to see which requirements are met and which still need attention.

Automating the Assessment of Changes

Once your baseline is set, the platform can help flag proposed changes that are likely to be considered substantial. As organisations prepare for the December 11, 2027, deadline, they are building systematic ways to categorise every product change. A platform like Regulus assists by generating tailored requirement matrices that help differentiate permissible updates from substantial modifications needing a full reassessment. You can discover more insights about this and other aspects of the Cyber Resilience Act on cycode.com.

This structured approach turns the CRA substantial modification definition from an abstract legal concept into a practical, data-driven workflow. Instead of relying on guesswork, your team can assess changes against a pre-defined set of criteria.

• Requirements Matrix: Instantly see how a proposed change affects your product’s compliance with Annex I requirements.
• Documentation Templates: Use ready-made templates to document your assessment, justifying why a change is or is not substantial.
• Evidence Management: Link every decision back to concrete evidence, creating an audit trail that will stand up to scrutiny.

By adopting a tool like this, you shift from risky, ad-hoc decisions to a systematic and defensible process. This doesn’t just prepare you for market authority inspections; it gives you the confidence and efficiency needed to navigate the complexities of CRA compliance.

Common Questions About Substantial Modifications

Understanding the Cyber Resilience Act often comes down to a few critical definitions, and none is more important than ‘substantial modification’. Getting this wrong can turn a simple update into a full-blown compliance nightmare.

Here, we answer the common questions that product managers, compliance officers, and engineering leads grapple with when deciding if a change triggers a new conformity assessment.

Are Security Patches That Fix Vulnerabilities a Substantial Modification?

Generally, no. A patch that fixes a known vulnerability without changing the product’s core function or security architecture is just routine maintenance. In fact, the CRA requires you to do this as part of your post-market duties.

Practical Example: You discover a buffer overflow vulnerability (like CVE-2023-1234) in your smart thermostat’s firmware. Releasing a patch that corrects the flawed code to prevent the overflow is a non-substantial update. It simply restores the product’s security.

However, if fixing the vulnerability required you to remove the entire Wi-Fi module and force users to connect via Ethernet only, that would likely be a substantial modification because it fundamentally changes how the product operates.

Who Is Responsible if a Third Party Makes the Modification?

The responsibility falls squarely on whoever makes the change. The CRA is crystal clear on this: any person or company that performs a substantial modification is treated as the manufacturer of that newly-changed product.

Practical Example: An importer buys generic security cameras and installs their own custom AI software that adds facial recognition capabilities before selling them. The importer is now legally the “manufacturer” of this modified product. They must conduct a new conformity assessment, create all technical documentation, and issue a new Declaration of Conformity. The original camera maker is only responsible for the camera as they sold it, without the AI software.

Does Changing the User Interface Count as a Substantial Modification?

A purely cosmetic UI change—like updating colours, icon styles, or button layouts—is almost never a substantial modification. These changes don’t touch the product’s security posture or its intended purpose, so they don’t trigger a reassessment.

The story changes completely if the UI redesign adds new functionality. For example, if a new interface in a banking app adds a form to upload identity documents for verification, that is a substantial modification. It’s not a simple facelift; it introduces a new, high-risk data handling process that was not part of the original assessment.

How Should We Document Our Decision That a Change Is Not Substantial?

Meticulous record-keeping is your best defence. For every single product change, you need to document your assessment—especially when you conclude it is not substantial. This creates a defensible audit trail that shows regulators you’re performing due diligence.

Your technical file should contain a clear record of:

• The Change Itself: A straightforward description of the update or modification (e.g., “Software version 2.1: Updated button colors and patched CVE-2024-5678”).
• Your Analysis: An explanation of how you evaluated the change against the CRA’s two main triggers (e.g., “The change does not alter the intended purpose of home climate control. The patch only corrects a known vulnerability and does not weaken other security controls.”).
• The Justification: A written conclusion explaining precisely why the change was classified as a non-substantial update (e.g., “Conclusion: Update 2.1 is non-substantial as it is a minor UI tweak and a standard security fix.”).

This internal documentation proves you have a structured process and are actively managing your compliance obligations, not just hoping for the best.

Confidently assessing modifications and navigating the complexities of the CRA is far easier with the right tools. Regulus provides a structured platform to document your product’s intended purpose, manage technical files, and create a clear, auditable trail for every decision. Explore how Regulus can bring clarity to your compliance workflow and reduce risk.

La entrada CRA Substantial modification definition: EU Compliance Guide for 2026 se publicó primero en Regulus.