It is one of the most repeated questions once a connected product has been on the market for a few months: we have shipped a new firmware version, is the CE marking still valid? The short answer is that it depends on what changed. The long answer is more interesting, because it contains an apparent contradiction almost nobody explains.
On one side, modifying an already assessed product can force you to reassess its conformity. On the other, European legislation requires you to be able to update it in order to fix vulnerabilities. Both are true at once, and the way out is not regulatory: it is architectural.
The idea in one sentence: the problem is not updating. The problem is not having decided in advance what an update is allowed to touch.
Table of contents
CE marking covers a product, not a firmware version
When you declare conformity, what you are declaring is that that product, as placed on the market, meets the essential requirements applicable to it. The technical file describes a specific configuration: a piece of hardware, a set of parameters and a behaviour that were measured and documented.
Firmware is part of that configuration. It is not an accessory: in a connected product it is precisely what decides how the radio behaves, how credentials are managed and what the device does when something fails. That is why an update is not automatically harmless — nor automatically a problem.
If the whole process is still unclear, start with the basics: we cover it in our guide to CE marking costs and pre-compliance.
When an update is a substantial modification
The reference criterion is the European Commission's Blue Guide, which distinguishes between trivial and substantial modifications.
The difference between trivial and substantial
A modification is trivial when it cannot affect compliance with the essential requirements. It is substantial when it can, and the modified product then has to be treated, in practice, as a new product.
Note the nuance: the test is not whether the change did affect anything, but whether it could. That shifts the burden onto you: you have to be able to justify why a given change does not compromise what was assessed.
Who takes on the obligations when it is substantial
When the modification is substantial, whoever introduces it takes on the same obligations as the original manufacturer: reassessing conformity, preparing the corresponding technical documentation, drawing up a new EU declaration of conformity and standing behind the marking.
In firmware this has an uncomfortable consequence. If you push a substantial change over the air to units already in your customers' hands, you are not only modifying future product: you are modifying product already placed on the market.
Which firmware changes actually affect conformity
In practice the list of problematic changes is fairly short and fairly predictable.
Radio parameters
These are the first suspects, because they are exactly what the laboratory measured:
- Transmit power. Raising it is the textbook case: the test was run at one value and the product ships at another.
- Bands and channels. Enabling channels that were not active during testing, or changing the configured regulatory region.
- Duty cycle. Relevant in bands with occupancy limits; firmware that transmits more often can push you over.
- Modulation or data rate, where they change occupied bandwidth or the emitted spectrum.
Safety functions
If the firmware implements a function with a safety role — thermal protection, overcurrent cut-off, an emergency stop, battery charge management — touching it means touching an essential requirement directly. Here the bar for treating a change as substantial is much lower.
A typical case: an update that tweaks the battery charge profile to squeeze out more runtime. It sounds like a product improvement and it is, in fact, a change to a safety function.
What almost never matters
Most day-to-day firmware work does not enter this territory: bug fixes that touch neither safety nor radio, UI changes, translations, telemetry, cloud integrations, power optimisations that leave transmission parameters alone. These are trivial modifications and require nothing beyond keeping the record tidy.
The paradox: the law requires you to be able to update
Here is the part that rarely gets told. While one side of the legislation asks for caution when modifying, another demands that you be able to do it.
EN 18031 and secure update
Since 1 August 2025 the cybersecurity requirements of Delegated Regulation 2022/30 under the Radio Equipment Directive are enforceable for internet-connected radio equipment. The harmonised EN 18031 standards, published by CEN-CENELEC, treat software update as a security mechanism: you must be able to distribute fixes, and to do so in an authentic and verifiable way.
Put another way: a connected product that cannot be updated is, today, a product with a compliance problem.
The Cyber Resilience Act reinforces it
Regulation (EU) 2024/2847 goes further and extends the duty across the product's lifecycle, with vulnerability reporting obligations from September 2026 and full application in December 2027.
The practical conclusion is that you cannot resolve the dilemma by not updating. You resolve it by designing what an update is allowed to change.
How this is handled in practice
Keep regulatory parameters out of the OTA's reach
The cleanest answer is architectural: separate the configuration with regulatory relevance — power, bands, charge limits, protection thresholds — from the code that gets updated over the air. If those values live in a layer the update does not touch, functional firmware can evolve without dragging the technical file behind it.
It is a decision that costs little early in the project and a lot later, exactly like EMC decisions in product development.
Versioning and traceability in the technical file
The technical file has to describe the product on the market. With firmware that keeps evolving, that means maintaining:
- which firmware version corresponds to the configuration that was tested,
- a change log per version,
- and an assessment, however brief, of whether each version touches anything with regulatory relevance.
That third point is the one almost nobody does, and the one that solves the problem. A single line per release saying "does not affect radio parameters or safety functions" turns a doubt into evidence.
When you do have to go back to the lab
When a change does touch measured parameters, you rarely need to repeat the whole campaign: you repeat the affected tests. Change transmit power and you go back to radio testing, not to electrical safety. Which is exactly why it pays to know precisely what was measured, and in which configuration.
How we approach it at RobotUNO
As always in this area, let's be clear: we are not an accredited laboratory or a notified body, and we do not decide for you whether a modification is substantial. That assessment belongs to the manufacturer and, where there is real doubt, to the laboratory.
What we do is the design work that prevents the problem:
- Separate, in the firmware architecture, what carries regulatory relevance from what does not.
- Implement secure update — signed and verified — compatible with EN 18031 requirements.
- Set up a versioning and change-log scheme that actually works inside the technical file.
- Review, before a release ships, whether it touches anything that was tested.
It is a natural part of the work on any connected device expected to stay on the market for years.
A practical rule: if, before shipping a release, you cannot answer "does this touch radio or safety?", the problem is not the update. It is that the firmware is not organised well enough to answer.
Frequently asked questions
Does every firmware update require recertification?
No. The vast majority of updates are trivial modifications: they fix bugs, improve the interface or add features that touch nothing that was assessed. Conformity only has to be reassessed when the change could affect the essential requirements that were demonstrated.
Which firmware changes force radio testing to be repeated?
Those touching parameters that were measured in the laboratory: transmit power, bands or channels used, duty cycle, modulation type or antenna behaviour. If the radio test was run with one set of values and the firmware changes them, the test report no longer describes the product you are selling.
Do I have to update the technical file with every version?
The file has to describe the product that is on the market. You do not need to rewrite it for every patch, but you do need a version record showing which firmware corresponds to the assessed configuration and what changed in each release.
Does the legislation require the product to be updatable?
For internet-connected radio equipment, the cybersecurity requirements enforceable since August 2025 mean in practice being able to distribute security fixes in an authentic, verifiable way. The Cyber Resilience Act reinforces that duty across the product's whole lifecycle.
Can I lock the radio parameters to avoid the problem entirely?
Yes, and it is the cleanest design answer. If the radio configuration lives in a layer the OTA process cannot modify, functional updates stop being a regulatory risk. It is an architectural decision, and it has to be made before you write the update mechanism.
Have a connected product that will keep evolving?
We can review how the firmware is organised and leave it ready so that updates never turn into a regulatory problem.
