The European Commission has published its long-awaited EU Cyber Resilience Act implementation guidance (Regulation (EU) 2024/2847), offering companies practical examples just weeks before the first reporting obligations kick in on 11 September 2026. The guidance is one of the most important EU Cyber Resilience Act updates for organizations preparing for the CRA's implementation and reporting requirements.
Published on 27 July 2026, it is a non-binding document developed via stakeholder and public consultation. Ever since the EU Cyber Resilience Act (CRA) was first presented, this regulation has raised a lot of questions about its defined controls and requirements, which can be confusing, especially for existing and legacy devices.
For small and mid-sized organizations, these demands might even feel like a roadblock to their business. This new guidance aims to provide clarity to the process and address the questions stakeholders have been asking most.
Below, I’ve outlined a few sections that are the most interesting from our perspective.
1. When is a product "placed on the market" under the CRA?
Everything in the EU Cyber Resilience Act hinges on this concept, as it determines when software and other products are considered “placed on the market” under the CRA, when the obligations apply, and whether a product is even in scope.
For physical products, the logic is familiar from existing product law. Each physical device is treated individually. So if you produce a series of the same device model, unit #1 shipped in January and unit #500 shipped in June, both are placed on the market on their own respective date.
For software, it's a bit different: a standalone product is placed on the market when its development is finished and it is first offered for distribution or use in the EU in the course of a commercial activity. From that moment, every copy of that version is considered 'placed on the market' at the same time, regardless of when each individual copy is actually downloaded or bought.
One practical consequence worth noting is that different builds are treated as different products. If you ship variants that differ in components, configuration or enabled features — say a Windows build and a Linux build, or a basic and a pro bundle — those are treated as distinct products, not copies of one.
The guidance also draws a clear line regarding remote access. Software that is delivered to the user and runs on the user's device is in scope. Software that runs remotely and is merely accessed, for example through a browser, is outside the CRA's scope.
2. What counts as a substantial modification under the CRA?
This part is exceptionally important, especially because of the number of legacy products placed on the market before the regulation fully takes effect. The EU CRA states that any product with digital elements that is already placed on the market falls under the scope of cybersecurity requirements following a CRA substantial modification. In short, a modified product is treated as newly placed on the market.
But in practice, this isn't always so deterministic. What actually counts as 'substantial'?
- Whether a change is "substantial" depends on its effect on cybersecurity risk, not on how big the change looks. A small feature can be a substantial modification. A large security patch usually is not.
The guidance is explicit that even security updates are generally not substantial modifications, because their whole point is to reduce risk. This also applies when an update involves significant technical changes - as long as it doesn't alter the product's intended purpose or introduce new risks. The exception is a security update that, despite its purpose, changes the product's boundaries.
Example, straight from the logic in the guidance: a manufacturer adds a "remember me" login feature that stores authentication tokens on the device. It’s a minor change. But it introduces new risks around token theft and session hijacking that were never in the original risk assessment. That makes it a substantial modification.
Contrast that with a manufacturer deploying a patch to fix an input-validation flaw, this is a significant change, but no new purpose, no new exposure, and not a substantial modification.
To decide if the change is substantial, the guidance gives four questions to work through:
One more nuance to mention: even if the change is substantial, the obligations attach only to the parts affected by the modification, unless the change undermines the security of the product as a whole – in this case, the whole product is treated as new.
3. How long must CRA support periods last?
Article 13(8) sets a minimum support period of five years, but if your product is reasonably expected to be in use for longer than five years, the support period must be extended accordingly.
For software that is updated iteratively, each substantially modified version needs its own declared support period that meets the rules at the time it goes to market. Nevertheless, you are not required to keep patching every old version forever. Once users can upgrade to the latest version free of charge and without "additional costs", you can stop addressing vulnerabilities in the older versions.
The term "additional costs" is also clarified, and it does not include the normal operational effort of applying updates like staff time, post-update testing, configuration changes, updating dependencies, etc. It does include things like being forced to buy new hardware or fundamentally change the operating environment. So requiring a customer to spend an afternoon testing and rolling out an update is fine; requiring them to buy a new box is not.
4. What are the CRA reporting obligations?
The reporting starts in September 2026, and this is the first real CRA duty most organizations will face.
The affected teams must report actively exploited vulnerabilities and severe incidents to both ENISA and the coordinating CSIRT, even though the reporting platform is still under development as of August 18, 2026.
Nevertheless, don't wait for the portal to build your process. Create an EU Login account now, confirm which national CSIRT you report to under Article 14(7), and stand up an internal detection-to-disclosure workflow built around ENISA's published 24h/72h/final field template so your team is ready to submit the moment the platform opens.
The clock starts ticking the moment you "become aware," and the guidance ties that concept to the same reasoning used for GDPR breach notification: you are aware once, after an initial assessment, you have a reasonable degree of certainty that a vulnerability is being actively exploited or that a severe incident has compromised your product's security.
The reporting itself is staged:
- Early warning within 24 hours of becoming aware.
- A fuller notification within 72 hours.
- A complete report within 14 days of a fix or mitigation being available for an exploited vulnerability, or within one month of the 72-hour notification for a severe incident.
You can find more details in my previous article.
5. How is a product's CRA conformity route determined?
The EU Cyber Resilience Act outlines different approaches for the product conformity assessment. Whether you can self-assess or need a third party depends on how your product is classified: default, important (class I or II), or critical.
That classification turns on the product's "core functionality", but what does it mean in practice?
Core functionality is the product's main features and technical capabilities, the features without which it could not meet its intended purpose. Two points matter in practice.
- A product has only one core functionality for classification purposes.
- Just because your product contains a component that could be considered important or critical on its own does not mean that the whole product falls into that category. What matters is the main function of the product as a whole.
The guidance also warns that you cannot describe your product creatively to dodge the stricter assessment route. If your marketing materials, user instructions, and technical documentation tell inconsistent stories about what the product does, market surveillance authorities will take notice.
If you want to get a preliminary evaluation of your specific product class and CRA compliance route, feel free to use our Star assessment tool.
6. How does the CRA define remote data processing?
Another interesting area is how to properly identify the scope of compliance for complex products with multiple components. Most commercial connected products now rely on the cloud backend and wider third-party integrations.
The question is: which parts of that backend and services fall inside your product and require CRA compliance?
The guidance proposes a simple two-part test. Remote data processing is considered part of your product only if both of the following conditions are met:
Conclusion:
- If the processing is not needed for the function to work, it is not the remote data processing solution under the Cyber Resilience Act. However, you may still need to consider it as a risk.
- If processing is necessary but performed by a third party, it is treated as a third-party component. This means it is outside the scope of your product’s conformity assessment, but you still need to perform appropriate due diligence.
Below you can see how it maps with the different cloud service models:
Summary
The guidance covers many critical questions and will definitely be useful for organizations navigating the EU Cyber Resilience Act. Stay tuned for future articles where I'll cover other aspects of it.
Two things to keep in mind: first, the guidance is not law. Only the Court of Justice can provide an authoritative reading of the CRA. What the Commission has published is its own interpretation, meant to steer manufacturers and market surveillance authorities toward a consistent approach. Second, every worked example illustrates the reasoning, but it does not replace a case-by-case assessment of your own product.
If you need expert support navigating the compliance questions and evaluating your specific products, please contact us.
FAQ
For physical products, each unit is placed on the market individually at the moment it ships — unit #1 in January and unit #500 in June are both "placed on the market" on their own respective dates. For software, the whole product is placed on the market once development is finished and it's first offered for distribution or use in the EU commercially; every copy of that version counts as placed on the market at that same moment, regardless of when an individual copy is actually downloaded. Builds that differ in components or enabled features (a Windows build vs. a Linux build, a basic vs. a pro tier) count as distinct products, not copies of one — and software that only runs remotely and is merely accessed by the user (e.g. through a browser) falls outside CRA scope entirely.
