Guardian360
Start free trialBecome a partner
← All posts

Opinion

Everyone is watching NIS2. The Cyber Resilience Act is the one that can pull your product off the market.

By Jan Martijn Broekhof ·

On 9 July I attended CRA Connect, an event on the Cyber Resilience Act organised by CyberVeilig Nederland, FME and the Ministry of Economic Affairs, hosted by Tesorion in Nieuwegein. I went in thinking I already knew the essentials. Guardian360 builds software, so of course the CRA applies to us; that part was never in doubt. What caught me off guard was the speed. Not the headline date of December 2027, which most people in the room could recite, but the one sitting quietly in front of it: 11 September 2026. That is not a distant obligation. That is preparation time that has already started running.

I suspect I am not the only one who had the timeline slightly wrong in my head. And the reason that matters is simple: right now, almost everyone in cybersecurity is looking at NIS2. The CRA is arriving in its shadow, and of the two, the CRA is the one that can eventually stop you from selling your product at all.

What exactly is the Cyber Resilience Act?

The Cyber Resilience Act is a European regulation aimed at the security of products with digital elements. It entered into force on 10 December 2024 and, because it is a regulation rather than a directive, it applies directly across the EU without being translated into national law.

Its scope is broad. It covers not only physical connected devices such as IoT hardware, firewalls and network equipment, but also software: operating systems, mobile apps, firmware and separately marketed software components. If a product with digital elements is placed on the EU market as part of a commercial activity, it is very likely in scope. That reach extends beyond Europe too; a manufacturer based outside the EU is bound by the CRA the moment its products are made available on the EU market.

There is one exception worth naming, because it is widely misunderstood. Non-commercial open-source software falls outside the CRA. But the moment you integrate open-source components into a commercial product, those components are part of your product, and the CRA obligations apply to the whole. You cannot outsource responsibility to an upstream project you never paid.

When do you actually have to comply?

Here is where the surprise lives. There are two dates, and the second one gets all the attention while the first one does the damage.

On 11 September 2026 the reporting duty begins. From that date, manufacturers who become aware of an actively exploited vulnerability or a severe incident in their product must report it, with a first notification within 24 hours, through the national channel at mijn.NCSC.nl. On 11 December 2027 the rest of the regulation applies in full: the essential cybersecurity requirements, the conformity assessment, the CE marking, the technical documentation. From that date, only CRA-compliant products may be placed on the EU market.

Now turn those dates around. Look at them not as deadlines but as the moment your preparation has to be finished. A working incident and vulnerability reporting process, tested and staffed, has to exist before September 2026. A full conformity assessment, with all the documentation behind it, has to be done before December 2027. Subtract the time each of those genuinely takes, and both dates point back to the same uncomfortable place: now.

Everyone is looking at NIS2. That is the dangerous part.

The cybersecurity sector has spent the past two years absorbed by NIS2 and its Dutch implementation. That attention is not wrong, but it has created a blind spot, and the blind spot is dangerous precisely because the two laws are not competitors for your attention. They interlock.

The CRA is, in effect, the supply-chain instrument underneath NIS2. An organisation that falls under NIS2 can only be secure if the products it buys are themselves secure. A hospital, a utility, a logistics operator; each is only as resilient as the connected products and software it procures. That is exactly what the CRA regulates at the product level. Look only at NIS2 and you are managing half the problem while assuming the other half takes care of itself.

The stakes differ too, and this is the part that should make people sit up. NIS2 non-compliance brings supervision and fines. Those are serious. But the CRA operates like the CE marking does for physical safety: from December 2027, a product without a valid conformity assessment simply may not be placed on the EU market. The worst case under NIS2 is a penalty. The worst case under the CRA is that your product cannot be sold. For a software vendor, that is not a compliance cost. That is an existential one.

We tested this on ourselves

I want to be honest about where Guardian360 sits in this, because it is the clearest way to show why “we’ll get to it” is the wrong reflex.

We are ISO 27001 certified. We already maintain a Software Bill of Materials for our products. On paper, we were better prepared than most. And the conclusion we reached was still sobering: that preparation gives us a head start, not an exemption. ISO 27001 governs our information security management system, our organisation and its processes. The CRA governs the security of the product itself. The two are complementary, but they are not interchangeable, and an ISO 27001 certificate on the wall does not make a product CRA-compliant.

Then we started mapping our own products against the CRA’s categories, and it became more interesting still. The regulation sorts products with digital elements into regular products, important products in class I and class II, and critical products, with the assessment getting heavier as the risk rises. Class II, which includes intrusion detection and prevention systems, requires assessment by an external notified body; self-assessment is not enough. Part of what we do sits squarely in that intrusion-detection space. In other words, some of our products point towards the heavier regime, not the lighter one. Working out exactly which product lands in which category, and documenting the reasoning, is precisely the kind of task that takes months. It is not something you do in a hurry in the late summer of 2026.

Why you cannot wait, even for “just” the reporting duty

Here is the fair objection, and it deserves a straight answer. Someone will say: September 2026 is only the reporting obligation, not full product conformity. Full compliance is 2027. So aren’t we overstating the urgency?

No, and here is why. The reporting duty is not a switch you flip. You cannot report what you do not monitor, which means the detection and reporting process has to be operational, and rehearsed, before the date arrives. You cannot report accurately on a product whose third-party dependencies you have never mapped, which is where the Software Bill of Materials comes in; assembling one across a real product portfolio is months of work, not an afternoon. And for anyone building physical products, the timeline is even less forgiving. At the event, Ferry Mulders of VDL Agrobotics spoke about the lifecycle of a machine, about proving that a machine cannot be hacked across the years it stays in service. A machine builder with a multi-year development cycle is designing today the products that will come to market after 2027. For them, 2027 is not the future. It is the current design brief.

Erik de Jong of Tesorion, whose company hosted the event, put the honest version of this plainly: they help others become compliant and are sitting with a substantial CRA job of their own. That is the reality across our sector. The people who advise on this are subject to it too.

What this means for partners

If you are a partner, an MSP, an integrator, a reseller or a cybersecurity specialist, this lands on your desk twice.

First, for yourself. If you develop, import or distribute any product with digital elements, go and check whether the CRA applies to you, and to which category each product belongs. Do not assume a service business is out of scope; a great many service providers also ship software, appliances or integrated products without thinking of them that way.

Second, for your customers. They are going to ask what the CRA means for them, and the partners who can answer well, calmly, specifically, with the timeline and the categories straight, are the ones who will earn the trust that follows. The conversation is coming either way. The only question is whether you have done the work before your customer asks, or after.

So here is the question I would leave you with. Have you already laid your own products against the CRA’s annexes, or are you quietly assuming that 2027 is still comfortably far away? Because when you turn the dates around, it isn’t.

Sources