Does a Firmware Update Require Re-certification?

← All guides

A product ships with firmware 1.0.3, and the test report records that version on the equipment description page. Eight months later the development team pushes 1.1.0: a new channel plan for one region, a raised output power table on the top rate, and a fix for a display flicker. Nobody updates the compliance file, because nothing about the hardware changed.

That is the most ordinary way a compliant product quietly stops matching its own paperwork. It is also one of the most frequent questions that arrives after a product is already on the market: we changed the firmware, do we have to re-certify?

The short answer is that a firmware update is not a certification event by itself. What decides it is whether the update changed something that was measured, declared or assessed. That is a narrower question than most teams assume, and a wider one than "did the radio change".

Two regulatory starting points

Different markets answer this in completely different ways, and both answers are useful because they bracket the problem.

Market	Governing text	What it says about a software change
United States (certificated transmitter)	47 CFR 2.1043	Software changes that do not affect RF emissions require no filing at all. Changes that degrade reported spurious or out-of-band emissions are treated as a change in frequency or modulation.
European Union (radio equipment)	RED Guide, section 1.5 "Repairs - Software updates"	An update is maintenance unless it modifies intended functions, the radio interface, type or performance in a way the initial risk assessment did not foresee, and it changes the nature of the hazard or raises the risk, and the product is made available.

Both texts land on the same practical test: not "is the version different" but "did a measured or declared characteristic move". The FCC just writes it in terms of filings, and the EU writes it in terms of whether the product is new.

Where the version number lives in your file

Before any of this matters, check that your file even names the version. For the EU, the technical file must contain the software or firmware versions affecting compliance - that is RED Annex V(a)(ii), and it is a required element, not a courtesy. A report that says "standard firmware" or "latest release" is a report you cannot defend eighteen months later, because nobody can show what was actually tested.

Ask for the exact string: 1.0.3, or V2.14 build 20250311, or whatever the release process produces. If the laboratory has to guess, you have a documentation defect that will surface at the worst possible moment - usually during a marketplace compliance check or a customs query.

Firmware matters in a second place too. If a safety assessment covered charge termination, a thermal cut-off or an interlock, that behaviour was implemented in code. Change the threshold and you have changed a protective function, even though the bill of materials is identical.

The FCC route: 47 CFR 2.1043 in plain terms

For an FCC-certified transmitter, the regulation already anticipated software updates, and it is more permissive than most people expect at the bottom end and stricter at the top end.

No filing at all. Paragraph (a) says changes to the software installed in a transmitter that do not affect the radio frequency emissions require no additional filings, and may even be made by parties other than the holder of the grant. That covers UI changes, logging, cloud connectivity, and most bug fixes.

Class I. Modifications that do not degrade the characteristics reported to the Commission at certification. No filing is required.

Class II. Modifications that degrade the reported performance characteristics but still meet the minimum requirements of the applicable rules. The grantee files complete information plus test results for the characteristics affected by the change, and the modified equipment must not be marketed under the existing grant until the change is acknowledged.

Class III. Software changes to a software defined radio that alter frequency range, modulation type or maximum output power outside the parameters already approved, or that change the circumstances in which the transmitter operates under the rules. This needs a description of the changes and test results showing compliance with the new software loaded, including RF exposure.

There is one note under paragraph (b)(3) that catches teams who reason "we lowered nothing, we only raised power slightly, so nothing degraded": any software change that degrades spurious and out-of-band emissions reported at initial certification is treated as a change in frequency or modulation, requiring a Class III permissive change or a new equipment authorization. Spurious margin is exactly what a power table change eats first.

And a constraint that matters commercially: Class I and Class II changes may only be made by the holder of the grant. If the grant sits with your factory or your ODM, you cannot file the change yourself - which is the same structural problem described in using a supplier's test report for your own brand.

The EU route: maintenance or a new product?

The RED Guide sets out a three-part test. A software update is treated as maintenance - no new conformity assessment, no new declaration of conformity - provided it does not modify the product in a way that may affect compliance. It becomes a substantial modification, and therefore a new product, where all three hold:

1. the update modifies the original intended functions, radio interface, type or performance, and this was not foreseen in the initial risk assessment;
2. the nature of the hazard has changed, or the level of risk has increased, because of the update; and
3. the product is made available.

Your own risk assessment is the reference point, which is why the document you wrote before testing matters years later. A product whose risk assessment explicitly considered "BLE only, no proprietary mode, fixed channel plan" has a harder time arguing that enabling a proprietary mode was foreseen.

One consequence is often overlooked: the assessment has to cover every configuration a user can reach. A mode that exists in the silicon but is disabled in the shipped build is not automatically covered - and enabling it by update is a change to a configuration, not a bug fix.

Two further points apply to products that are resold or rebadged. Under RED Article 14, an importer or distributor who modifies radio equipment already placed on the market in a way that may affect compliance takes on the manufacturer's obligations under Article 10. So a distributor who pushes a regional firmware variant is no longer just a distributor. And since 1 August 2025, the cybersecurity requirements in Article 3(3)(d), (e) and (f) apply to the product categories set by Delegated Regulation (EU) 2022/30 - which makes the update mechanism itself part of the assessment. The EN 18031 series looks at how an update is authenticated, delivered, and whether a device can be rolled back to a vulnerable version. In the UK, the PSTI regime (in force since 29 April 2024) separately requires a defined minimum security update support period to be published.

What actually decides it: the change, not the version

This table is the one worth keeping next to the release checklist. The middle column is the question that matters. Hardware is judged the same way, which is why changing a hardware component is not automatically a retest either - the test is always whether a reported characteristic moved.

Type of change	What it touches	Normal outcome
UI text, icons, language packs, app-side copy	Nothing measured	No filing, no retest. Record the version.
Bug fixes in non-radio code (logging, cloud link, display logic)	Nothing measured - unless clock or switching timing moved	Record. Check emissions if timing changed.
Output power table, duty cycle, data rate, packet length	RF output and spurious margin	Retest affected items. FCC: Class II if reported characteristics degrade.
Channel list, band edges, new frequency range	Frequency determining behaviour	New certification, or Class III for an SDR.
Enabling a radio mode that shipped disabled	A configuration that was never assessed	Test the mode, or do not ship it.
DFS, LBT or adaptivity parameters	Spectrum access behaviour	Retest the affected RF items.
Radio chip firmware, calibration tables, RF front-end switching	The RF chain itself	Retest, full radio suite in most cases.
Charge control, thermal limits, protection thresholds, interlocks	A safety function	Safety retest of the affected clause.
Authentication, password policy, encryption, update mechanism	RED 3(3)(d)(e)(f) where in scope	Re-assess against EN 18031.

Four situations that come up constantly

1. "The hardware never changed, so nothing changed"

A BLE-only product was tested and declared with one mode. A later release enables a 2.4 GHz proprietary mode that was always present in the radio chip but switched off in the shipped firmware. Nothing on the board moved, so the team concluded no action was needed. But the report covered the modes that were exercised, and the declaration was built on that configuration. The compliant options are narrow: keep the mode disabled, or test it now.

2. Power raised to fix range complaints

Field complaints about range, so the top rate gets a firmer power table, still inside the maximum already granted. The reasoning is that the grant ceiling did not move, so the grant still applies. The measurement that usually breaks is not the fundamental - it is the spurious and out-of-band emissions, whose margin is often only a few dB. Under 2.1043 that is precisely the case the note to paragraph (b)(3) addresses: a degradation of reported spurious emissions counts as a change in frequency or modulation. What looked like a tuning tweak becomes a Class III filing or a new authorization.

3. A display fix that is not a radio change

Flicker on the panel, solved by changing the PWM frequency. Radio untouched, so the RF report is unaffected. But radiated emissions were measured with the old PWM, and a new switching frequency puts energy at a different set of harmonics - sometimes right through a limit line with less margin than the radio ever had. CE conformity is not radio-only, so the EMC part of the file is the one that gets invalidated by a change that nobody classified as an EMC change.

4. Version drift during the test window

The most common defect I see, and the least dramatic. The laboratory receives 1.4.2. During the three weeks on the bench, a bug fix ships internally and production starts loading 1.5.0. The report is technically correct about a build that no customer will ever receive. When a buyer later compares the report's equipment description with the label on the box, the mismatch is visible - and it is not explainable after the fact. Freeze the build before the samples leave, and treat any change during the window as a change to the tested configuration.

What to send the laboratory

A genuine delta question can be answered in a few days and a short bench slot, if the input is specific. What helps:

• the tested version and the new version, exactly as they appear in the release system;
• the release notes, or a diff summary written for an engineer rather than for marketing;
• which measured parameters could plausibly move - output power, occupied bandwidth, spurious, switching frequency, charge current;
• whether units already in the field will receive the update, because the installed base then becomes the new configuration;
• the equipment description page from the existing report, so the comparison starts from what was actually declared.

With that, a laboratory can usually say within a day whether you are in the "record it" box, the "test these four items" box, or the "this is a new product" box. Without it, the only safe answer is a full retest, which is the most expensive way to resolve uncertainty.

Where SZC-LAB fits

Most of the firmware questions we handle are not full projects. They are a report in hand, a release note, and a decision to make before the update goes out. That is a different kind of job from running a new certification, and it is easier to get wrong in both directions - either retesting everything out of caution, or shipping a change that nobody assessed.

We run EMC, RF and SAR testing in-house, which matters here because the affected items after a firmware change are usually spread across radio and emissions rather than sitting in one discipline. A delta assessment against an existing report is normal work for us: we take the declared configuration, compare it with the new build, list the test items that the change can reach, and then run those items - or a short pre-scan first where the outcome is genuinely uncertain. Where the answer is "the file just needs the new version recorded", we will say that rather than sell a retest, and where the change lands in Class III or new-product territory we will say that too, before you have booked anything.

What we do not do is decide your regulatory classification for you. Whether a change makes a product new under the RED is a judgement your risk assessment supports, and whether a permissive change can be filed at all depends on who holds the grant. We will give you the measurement evidence and a written view of the affected scope; the filing decision stays with the responsible entity.

The answer in one paragraph

A firmware update is not a certification event in itself, and no regulation requires you to re-certify every release. Under 47 CFR 2.1043, a software change that does not affect RF emissions requires no filing at all, while one that degrades the spurious or out-of-band emissions reported at certification is treated as a change in frequency or modulation and needs a Class III permissive change or a new grant. Under the Radio Equipment Directive, a software update counts as maintenance unless it modifies intended functions, the radio interface, type or performance in a way the initial risk assessment did not foresee, changes the nature of the hazard or raises the risk, and the product is made available - at which point it is a new product. In between sits the ordinary case: a measurable characteristic moved, so the affected test items are repeated and the technical file is updated, because RED Annex V(a)(ii) requires the software or firmware versions affecting compliance to be recorded there.