Three misconceptions are taking hold in CRA preparations across European companies. They're understandable – but they're wrong. And if you're building your product strategy on them, you risk standing before a market surveillance authority with a support declaration that won't hold up.
In this post, we walk through the three most common misconceptions and explain what CRA's support requirements actually mean in practice.
Here's what we're addressing:
Let's take them one at a time.
This is probably the most widespread misconception. Companies declare a 5-year period, plan security updates for 5 years, and consider themselves compliant. But Article 13(8) sets a minimum floor of five years – a safety net designed for products with shorter expected service lives.
It does not apply as a default to all products, and the guidance makes this explicit:
"A support period of five years is therefore not to be considered as the default for all products with digital elements."
The underlying logic is straightforward: the support period must reflect the product's expected service life – not an arbitrary figure, but the actual expected service life.
If you manufacture industrial equipment, embedded infrastructure solutions, or medical technology, a realistic service life is closer to 10–15 years. And under CRA, your support period is 10–15 years accordingly.
That's a more significant commitment than many organisations have factored in – but it is what the regulation requires.
The fear of having to repeat an entire conformity assessment with every major software update is understandable. But the guidance is far more proportionate than most people assume.
For software updates, the applicable test is risk-based: does the update introduce new attack vectors, enable new attack scenarios, or change the likelihood or impact of known threats?
If the answer is no – and the existing risk assessments still hold – there's likely no significant change to speak of.
If a significant change is involved, you can reuse all existing documentation and test results for the parts of the product that remain unaffected. The assessment focuses on what actually changed. A new declaration of conformity is required – but it's not a full restart.
That distinction matters in practice. A complete reassessment every time would make rapid vulnerability response prohibitively slow and expensive. The proportionality principle is designed precisely to ensure that manufacturers can act quickly when needed.
This one is perhaps the most counterintuitive. The starting point is that a significant change is treated as a new product under CRA – and many companies draw from this the conclusion that the support clock restarts.
It doesn't – not automatically.
According to the guidance, the support period is only reset if the significant change actually affects the factors that originally determined the product's expected service life.
A new software feature on an industrial controller lives as long as the hardware does – and that change doesn't alter users' expectations about the product's lifespan. The support period continues from wherever it already is.
Concretely: if two years remain in the support period when you make a significant software change that doesn't touch service life factors, two years remain after it. The five-year minimum applies to the original determination – it doesn't affect the remaining support obligation.
These three misconceptions arise because CRA's support requirements are written with a level of proportionality and context dependence that doesn't appear in a surface-level reading of the regulation.
The correct answer to "how long is our support period" requires an analysis of the product's actual lifecycle.
The correct answer to "does this update require a new assessment" depends on ongoing documentation of what changed – and what didn't.
Neither is insurmountable. But both require the groundwork to be done in advance. By the time an authority requests your documentation, or you need to determine whether the next update triggers new compliance obligations, it's too late to start.
At NorthGRC, we help manufacturers with exactly that: the advisory work that clarifies what CRA actually requires of your product, and the platform that ensures your documentation is ready when it needs to be.
The continuous delivery model is addressed directly in the guidance. You can concentrate your active vulnerability remediation on the latest version – but only where users can upgrade for free and without requiring new hardware or fundamental infrastructure changes.
That works for SaaS. It doesn't eliminate all obligations: coordinated vulnerability disclosure and reporting requirements continue to apply across all versions within the support period.