"We have already implemented NIS2, and the CRA is basically the same thing." Two weeks before 11 September 2026, this is the myth with the greatest damage potential that I hear in conversations. It is so insidious because it feels like work already done. The company really has invested, built processes, defined reporting paths. Just for a different regime.
What do NIS2 and the Cyber Resilience Act each regulate?
NIS2 is the EU directive on network and information security, implemented in Germany via the NIS2 Implementation Act. It addresses operators: companies classified as important or essential entities, for instance in manufacturing above certain size thresholds. What is regulated is the organisation itself, that is, risk management for its own IT, supply-chain security, governance duties of the management, and the reporting of significant security incidents affecting the company to the BSI.
The Cyber Resilience Act addresses manufacturers (as well as importers and distributors) and regulates the product with digital elements: security by design, that is, security anchored in the development process from the start, an SBOM (Software Bill of Materials, the inventory of all software components), security updates over the support period, conformity assessment with CE marking, and the reporting of actively exploited vulnerabilities in the product. For an overall overview, see the CRA summary.
In short: NIS2 asks whether your organisation is operated securely. The Cyber Resilience Act asks whether what you sell is secure and stays secure.
Why the equation is dangerous
A manufacturing company from medium size upwards is often both at once: a NIS2 entity and a CRA manufacturer. Then two sets of duties apply in parallel, and the differences sit exactly where it hurts operationally:
- Different reporting triggers: NIS2 reports significant incidents in the company's own organisation. The CRA reports actively exploited vulnerabilities and severe incidents relating to the product.
- Different reporting paths: the NIS2 report goes to the BSI as the supervisor of entities. The CRA report runs via the ENISA Single Reporting Platform to the competent CSIRT (in Germany also located at the BSI, but a separate channel with its own formats and deadlines).
- Different deadline logic: both regimes know 24-hour early warnings, but for different events. How the CRA staged model works is in the post on the 24-hour deadline.
- Different objects: a ransomware infection of your administration is a NIS2 case. An exploited flaw in the controller you sell is a CRA case. If an attacker compromises your update infrastructure, it can be both at once, with two parallel reporting strands.
The practical example I currently see more often: a mid-sized company with 400 employees has implemented NIS2 cleanly. Registration, risk management, reporting process to the BSI, management training, all in place. Internally the verdict is "reporting duties: done." That on 11 September a separate reporting path goes live for the product side, with a different trigger and a different platform, is on nobody's radar. The NIS2 implementation acts like a ticked-off box and hides the open flank.
Myth vs. Fact
Myth: Anyone who has implemented NIS2 has thereby also covered the requirements of the Cyber Resilience Act.
Fact: NIS2 regulates the organisation as an operator, the CRA the product and its manufacturer. Anyone with both roles has to meet both sets of duties, including two separate reporting paths with different triggers, objects, and platforms.
Concrete consequences for dual-role companies
1. Clarify your roles formally. Check two questions separately: is your company an important or essential entity under NIS2? And do you place products with digital elements on the EU market, that is, are you a manufacturer in the sense of the Cyber Resilience Act? The answers determine which sets apply. Do not rely on gut feeling here, the manufacturer role also bites in white-label constellations and substantially modified products.
2. Build a crisis organisation with two reporting strands. The synergies are real: escalation paths, availability, decision authority, and documentation routines from the NIS2 implementation can be reused directly. Extend them with the CRA strand: who establishes that a product is affected? Who operates the Single Reporting Platform? A shared playbook with two clearly separated exits beats two separate parallel organisations.
3. Test the CRA reporting path before the deadline. The NIS2 process is rehearsed at your company, the CRA process probably not. Use the remaining two weeks for a dry run: from establishing an actively exploited vulnerability in a product through the early-warning template to the fictitious submission. The precondition is that you even know which components sit in which products, that is, a maintained SBOM and a running vulnerability management.
What does this mean for your EU CRA roadmap?
On 11 September 2026, in two weeks, the reporting duties of the Cyber Resilience Act enter into force. For dual-role companies that means: the second reporting strand has to be in place now. It is the last Friday with realistic lead time to still test it.
On 11 December 2027 full CRA applicability follows for products newly placed on the market, from conformity assessment to CE marking.
How to translate both deadlines into overall planning is shown in the CRA compliance roadmap 2026/2027. What is at stake is quantified in the article on CRA fines and penalties.
Frequently asked questions
We are not a NIS2 entity. Does the CRA still concern us? Yes, the regimes are independent. The CRA attaches solely to whether you make products with digital elements available on the EU market, regardless of company size or sector.
We are a NIS2 entity but do not manufacture anything. What applies? Then it stays with NIS2. But check carefully: anyone who supplies software or devices to third parties under their own name, including as a white label, can be a manufacturer in the CRA sense.
Can we use the same report for both regimes? No. Triggers, content, recipients, and platforms differ. For overlapping events, such as an attack on the update infrastructure, you have to serve both strands in parallel. A shared playbook helps you not to miss the double report.
Does the management training from NIS2 also count for the CRA? In substance it helps, formally it replaces nothing. The CRA knows no explicit management training duty, but the company is liable for product duties that only work with backing from the leadership, such as support periods and reporting sign-offs.
After the NIS2 implementation, our CRA effort looks manageable. Is that deceptive? Partly. In process terms you have done groundwork. The product-related duties, SBOM per product line, conformity assessment, update processes, are by contrast new and typically sit in development and product management, not in IT security.
Conclusion
NIS2 and the Cyber Resilience Act are neighbours, not twins. One regime protects your organisation, the other your products and their users. Anyone with both roles needs both sets, and above all two functioning reporting paths. The NIS2 groundwork is a genuine head start here, as long as it is not used as an excuse to tick off the product side.
A structured CRA roadmap, supported by a platform like Kunnus, helps you build the product duties alongside the existing NIS2 organisation systematically, before the deadline tips from theory into practice. A starting point is our free CRA compliance check.
Every Friday I debunk a CRA myth here.