002 · The prototype meets the regulation: we audited our own firmware

In entry 001 we wrote that we do not recommend to clients what we do not do ourselves. This entry puts that to the test. We ran on our own prototype the analysis we run on other people’s products, and we are publishing the whole result, including the part that does not show us at our best.

The product, now with a name

What we have so far been calling just “our agri-IoT product” is called Aeromate. It is an environmental control ecosystem for drying and maturation: wine, aromatic herbs, cheese, charcuterie, cigars. The most mature module is called Aerodry and it does one thing only, but does it well: it reads temperature and humidity, computes the dew point and the vapour pressure deficit, and drives a dehumidifier inside a temperature-controlled chamber, be that a wine cellar, an adapted refrigerator or a curing chamber.

Aerodry has two years of continuous operation in a real environment. It detects the refrigerator’s compressor cycles, so it does not mistake the humidity spikes they cause for real events. It warns when the curing cloth dries out. It cuts the dehumidifier if the temperature climbs too high. It is a prototype we are proud of, and that is exactly why it suits this exercise. The distance between “it has worked for two years” and “it can be sold in Europe in 2027” is almost exactly the list of requirements in Annex I of the CRA, and that distance is worth measuring on a case where we can tell the whole story.

How we ran the analysis

We took the firmware as it sits in the repository, without tidying it up for the photograph first, and walked through the essential cybersecurity requirements of both parts of Annex I: the product’s security properties and vulnerability handling. For each requirement we recorded one of three answers: met, not met, or not applicable. No rounding in our favour.

What the prototype already does well

We start with the positive side, which also exists.

The update capability is there. Aerodry has updated its firmware by OTA since day one. The CRA requires that a product be able to receive security updates throughout the support period, and many prototypes do not even have the mechanism. We have it. The problem, as will become clear just below, is the security of that mechanism, but the mechanism exists.

The Wi-Fi credentials are not in the code. The first boot creates a temporary access point where the user configures the home network, and those credentials never pass through the repository. It was a good decision in 2024 and it is still a good one today.

There is operational safety logic at work: the maximum-temperature cutoff, the compressor cycle detection, the maintenance alerts. It is not cybersecurity, but it shows the right attitude, because the system was already written expecting things to go wrong.

And the attack surface is small. Two network services, one sensor, one relay. The CRA asks that the attack surface be minimised, and here the prototype’s simplicity works in our favour with no effort at all.

What fails, and why it was always going to fail

We describe here the nine flaws with direct consequence for whoever uses the product. These are the four most serious.

The OTA update accepts firmware from any origin. The update endpoint is plain HTTP, on port 80, with no authentication and no signature verification. Any device on the same network can replace the entire firmware. On a lab network of our own, this is a convenience. In a customer’s home it becomes the product’s most serious vulnerability, because the mechanism that should serve to fix problems turns into the way in. It is the first item on the work plan, for the simple reason that an insecure update channel is more dangerous than having no channel at all.

All communication travels in the clear. The readings, the relay state and the logs go out over unencrypted HTTP, with the data itself embedded in the URL, to a server that asks for no authentication. The CRA requires that data in transit be protected in confidentiality and in integrity. The technical fix is well known, with TLS and mutual authentication on MQTT. The real cost is not in knowing what to do, it is in making it fit on a microcontroller and in managing the certificates across five years of support. It will get a technical entry of its own.

The factory password is the same on every device. The configuration access point uses a fixed, weak password, identical across all units, and on top of that it is published in the README. This is one of the few points where the CRA calls out a concrete bad practice by name: no universal factory passwords. The fix means generating a different password per unit, in production, printed on the device’s label. Notice where this takes us: it stops being a firmware problem and becomes an assembly-line problem. It was the most useful discovery of the whole audit, and we come back to it at the end.

There was an integration secret in the public repository. The identifier of a device in an integration with a cloud platform was written into the code, in an open repository. It has since been revoked. It is recorded here because it is the most common mistake we find in other people’s firmware, and with us it was no different.

The other five, in brief. There is no SBOM, the component inventory: the dependencies are copied into the repository with versions frozen at different dates, which is more archaeology than inventory. There is no integrity verification at boot. There is no security event logging and no detection of unauthorised access. There is no way to erase the data at end of life, and this point is less abstract than it sounds, because the device stores the home’s Wi-Fi password in memory without encryption: an Aerodry resold second-hand carries the previous owner’s network with it. And the vulnerability disclosure policy still has to be extended to the product; on the website it already has an embryo, but no PGP key and no dedicated channel yet.

The conclusion that matters

Nine flaws with direct consequence, against a table of twenty-one applicable requirements, is not a bad result. It is the normal result of any prototype, including the good ones, including the ones that have already run for two years. None of these flaws came from carelessness. They came from priorities that were right for the prototype phase and stop being right when the goal becomes handing the device to strangers. A prototype exists to prove that the humidity control works. A product has to withstand being in the home of someone who did not build it.

The CRA is, at bottom, the work list between the one and the other. And the exercise revealed something you only see by doing it: about half of the fixes are not software. They are manufacturing process, like the per-unit password. They are infrastructure, like the key authority that signs the firmware and has to stay standing for five years. They are documentation, like the SBOM and the technical documentation. And they are organisation, like the disclosure channel and the team that responds. That is why leaving conformity to the eve of CE marking comes out expensive: by then the cost is already designed into the product, and touching it means reopening everything.

Entry 003 takes this audit and turns it into a plan, with the sequence from prototype to product and an idea of what each phase costs. If any decision in the plan proves wrong along the way, it gets recorded here, as agreed.

---

The full analysis, requirement by requirement, is in the annex to this entry. It is the same report format we deliver to manufacturers.