Logbook· entry 003

003 · From prototype to product: the plan, the sequence and what it costs

The audit from entry 002 turned into a work plan. Four phases, what goes into each one, and where the money gets spent. A good part of it is not code.

Published: 5 Aug 2026

Entry 002 ended with a list of flaws and a promise: to turn it into a plan. This is the part manufacturers rarely see before hiring us, because it usually only exists once the contract is signed. We publish it because it is the work we sell, and showing how we think is the best way to describe it.

The order is worth more than the list

The CRA’s list of requirements is in the regulation, and anyone can copy it. What sets the work apart is the sequence: deciding what has to be settled first so that the rest does not have to be redone. Doing things out of order tends to cost double, because you end up repeating work already done.

A concrete example from Aerodry. There is no point setting up TLS on the communications before deciding how the devices get their identity, because the identity determines how certificates are issued and renewed. And there is no point designing the identity before deciding whether the first boot generates a secret of its own for each unit, because that is where each device’s identity is born. These are three of the flaws from entry 002. Done in the right order, they are a single chained piece of work. Done backwards, they are three pieces of work, and each one forces you back into the others.

The four phases

Phase 0, framing. Before touching code, we need to decide and write down the product’s classification under the CRA, fix what the product does and above all what it does not do (because a new function can change the risk category), and define the support period as a constraint that shapes the design. Without this, every technical decision that follows has no criterion to be judged against. It is the cheapest phase of all and the one that saves the most later on.

Phase 1, the security foundations. The devices’ identity and the key authority that sustains it, first boot with a per-unit secret, verified boot. It is everything the next phase will assume as already solved. It is the phase the client sees least and the one that carries the greatest technical risk, and that is why it comes early, while it is still cheap to get it wrong and correct it.

Phase 2, the surface and the data. The signed and verified OTA update, encrypted and authenticated communication, security event logging, data erasure at end of life. These are the direct fixes from the entry 002 list. They only appear now because each one depends on a decision taken in Phase 1.

Phase 3, process and proof. The SBOM generated at build time and archived with every version, the Annex VII technical documentation, the vulnerability disclosure policy with a public channel and PGP key, the response process already rehearsed, and the conformity assessment with the declaration that goes with it. This phase does not change the product. It exists to make it demonstrable that the product complies. And without it a product can be secure and still not be sellable, because the proof is missing.

The four phases in sequence — framing, foundations, surface and data, process and proof — and, below them, an effort bar split down the middle: half code, half manufacturing, infrastructure, documentation and organisation. — The sequence and the effort: each phase assumes the decisions of the one before, and about half the work is not firmware.

Where the money gets spent

The audit’s discovery is worth insisting on, because it runs against almost everyone’s intuition: a good part of the effort is not firmware.

The per-unit password is not solved with a line of code, it is solved on the assembly line, with generation and printing of secrets. That is production logistics. The key authority that signs the firmware has to exist and be maintained throughout the support period, and the hard part is not standing it up, it is keeping it standing for five straight years. The documentation, which includes the SBOM, the technical documentation and the security instructions for the user, is serious work, and it is precisely what the assessment body will read. And the disclosure channel and the response process are people and procedures, which have to be in place before the first vulnerability shows up.

Only the other half is what most people picture when they hear “cybersecurity conformity”, which is touching the code.

What this means for our readers

If you are building a connected product for the European market, the practical lesson from our own experience is this: conformity comes cheap when it starts at Phase 0. A phase you skip does not disappear. It reappears later, more expensive, already designed into a product that nobody wants to reopen. The best moment for Aerodry’s Phase 0 would have been before the first prototype. We failed that moment, like almost everyone does. The next moment is now, and that is where we are.

Entry 004 goes down to the first serious technical decision: how to do the OTA update securely when the internet connection is rural and intermittent, which is our case. It was one of the three questions entry 001 admitted it could not answer. We will try to answer it. If the first attempt fails, that too gets written down.

This plan is the public, generic version of what we do per product. The concrete sequence, the effort estimates and the requirement-by-requirement analysis always depend on the specific product.