Logbook· entry 001

001 · Starting point: the decisions before the product

First entry in the logbook of preparing our agri-IoT product for the CRA. Where we stand, what we have already decided, what we still don't know.

Published: 15 Jul 2026

This logbook documents, in the open, the preparation of our agricultural IoT product for the Cyber Resilience Act — including the decisions that later turn out to be wrong. The product is at prototype stage, with a field trial in Coruche, and the market forecast is 2027–2028. In other words, if all goes to plan, the product is born already inside the full application of the regulation, with no transition period for us. That was a deliberate choice.

What is already decided

1. The working classification is “default product”. Agricultural monitoring is not in Annex III. The hypothesis stays documented with its rationale and gets revisited at every change of functional scope — the lesson from the classification article is that an added feature can change the category, and for us the temptation will exist (a sensor that “also detects intrusion” would be a different conversation).

2. SBOM from the first tagged build. Generated by the build system, never by hand, archived with the binary. The concrete tooling choice depends on the build system we settle on at the end of the prototype phase; the criterion is already fixed: only what generates an SBOM natively makes the shortlist. The gaps (vendor blobs) will be declared as gaps.

3. The support period is a design constraint, not a form field. Working target: five years. Immediate consequence, already in force at the prototype stage: no component enters the BOM without a known and compatible end-of-life date, and the annual cost of the update infrastructure enters the product’s cost model from now on.

4. The reporting process gets built before there is anything to report. The obligations of Article 14 will only touch us once there is a product on the market — but the process (triage, the awareness decision, templates for the three notifications) gets written and rehearsed long before, because it is also what we recommend to clients, and we do not recommend what we do not do.

5. Coordinated disclosure starting from the website. The security.txt of this site is the embryo of the coordinated vulnerability disclosure policy the CRA will require for the product. Next step, documented here: publish a PGP key and a formal policy.

What we still don’t know

With the honesty a logbook demands: we do not yet have a settled answer for (a) the OTA update architecture in a context of intermittent rural connectivity — which is our context — and its implications for the secure-updates requirement; (b) whether the remote processing we plan will be “integral to the product’s functions” in the regulation’s sense, which would define the perimeter of the technical documentation; (c) the state of the CRA’s harmonised standards by the date we need them.

Each of these will get its own entry when the answer exists — or when the first attempt fails.

Two panels side by side: on the left, the five decisions already taken before the product (default working classification, SBOM from the first build, support period as a design constraint, reporting process built before the product, coordinated disclosure starting from the website); on the right, the three questions still open (secure OTA over rural connectivity, the perimeter of remote processing, the state of harmonised standards). — The starting point in one picture: what is closed by decision, and what stays honestly open.

Why this is public

A client case study can never carry this level of detail; our own product can. If the reader is on the same journey and disagrees with any decision, the email address is in the footer — reasoned disagreement is more useful to us than silent reading.