Last week we wrote that the declaration of conformity for your product is yours to sign, even when somebody else designed the radio inside it. The question that arrives immediately afterwards is this one: a design change lands on the desk, and somebody has to say whether the testing still counts.
Nobody is going to tell you the answer. That is the part most teams discover late.
Nobody will tell you to test again
There is no certificate with an expiry date. There is no authority watching your revisions, and no annual renewal that makes somebody look. In the self-declaration route the manufacturer decides, which means you decide, and the first time anyone checks your reasoning may be years later.
So the useful question is not whether anybody will make you test again. It is whether the evidence you already have still describes the product you are about to ship.
What a test measured, and what a design change can quietly move
Open any test report and there are two kinds of content in it. There is what somebody measured: emissions, immunity, radiated power, electrical safety. And there is what the measurement assumed: this enclosure, this antenna, this supply, this firmware build, this intended use.
The measurements are written down. The assumptions usually are not, or they sit in a configuration annex that nobody reads after the campaign is over.
A design change that touches a measured value is easy to spot, and people handle those well. A design change that touches an assumption looks harmless, because nothing in the report appears to be about it. That is the one that gets through.
Three families of design change, and they do not behave alike
- Changes that touch the radio. Antenna type or position, ground plane, metal arriving nearby, a second transmitter, transmit power, band, duty cycle. These move measured values, and the module’s integration conditions usually say so in writing. If you are reusing a module’s evidence, its conditions are part of your file.
- Changes that touch safety. Enclosure material, supply, operating temperature, what a user can reach, what a service technician can open. These rarely feel like radio decisions and they land in a different standard entirely.
- Changes that touch the intended use, with nothing physical changing at all. The product gets sold into a different environment. It starts connecting through a phone instead of staying local. Somebody adds a feature that handles personal data. Nothing on the bill of materials moved, and the applicable requirements just changed underneath you.
The third family is the one nobody logs as a design change, and it is the one that can pull in a whole new set of requirements.
The check that costs nothing
Take the test report and the integration guide, and write one sentence: this evidence describes a product that is like this. Enclosure, antenna, supply, firmware, environment, use.
If you can write that sentence, every design change from then on is a five minute conversation. Does the change contradict the sentence or not.
If you cannot write it, the problem is not the change. It is that nobody can say what the evidence covers, and that was already true last month.
Who decides a design change is fine, and when
Whoever signs. And the decision belongs before the change, not after it.
The failure is structural rather than careless. Changes get decided by whoever has the problem in front of them, and that is how it should work. The mechanical engineer clearing a screw boss. The buyer replacing a component that went obsolete. The firmware engineer fixing range the week before a demo. None of them has the test report open, and none of them is signing anything.
Obsolescence deserves a line of its own, because it is the most common of all and the easiest to wave through. A component that is functionally identical is still a different component. Sometimes that is genuinely nothing. Sometimes it changes the thing the measurement assumed.
What it actually costs, which is less than people fear
Testing again is not all or nothing. Depending on what moved, the honest answer is one of four. A delta measurement on a single parameter. A technical justification written into the file, explaining why the existing evidence still applies. A partial retest of one standard. Or genuinely nothing at all.
The expensive outcome is not the retest. It is finding out after the tooling is paid for, which is also when the answer is most likely to be the full campaign.
A change log worth keeping
Not a log of every change, which nobody maintains. A log of the changes that touch something measured or something assumed, with three columns: what changed, who decided it was fine, and which piece of evidence says so.
It takes minutes per entry and it is the document that answers the question two years later, when the person who chose the module has moved on. It is the same seam we have written about when a project is split across suppliers: the files travel and the reasons do not.
One more case is worth knowing, because it runs the other way round. Everything above is about changing a product before you sell it. If somebody modifies a product after it has been placed on the market, European guidance treats a substantial modification as creating a new product. The obligations of the manufacturer can then move to whoever made the change. The Blue Guide sets out how that gets assessed. It is guidance rather than law, and market surveillance authorities lean on it heavily. If your customers integrate or modify what you sell them, that paragraph is about them.
The email that saves the argument
When a design change touches the radio, there is one message worth sending before anybody commits to it. Describe the change in two lines and ask the module supplier a single question: does this fall outside your integration conditions?
Three things come back from that. Sometimes a clear no, which you file as evidence. Sometimes a yes with a condition attached, which is the cheapest answer you will ever get. And sometimes silence, which is information too, because a supplier who cannot answer that question is a supplier whose evidence you are leaning on with nothing underneath.
Send it before the mechanical design freezes. Afterwards, the same question is a negotiation.
Where to start
Suppose you are in the middle of a design change right now, and the honest answer to “does this need retesting” is a shrug. The cheapest next step is the sentence above. One paragraph describing what your evidence covers, agreed by the person who signs.
If it turns out nobody can write it, that is a good subject for a paid scoping study, and it is a short one. We do the radio side of this work in the open, and the physics of putting a sensor inside somebody’s product is written up here. You can also read how we work across hardware, firmware, software and radio.
Next week: what an OEM has to decide before anybody can quote a custom sensor, and none of the five things is electronics.