Annex · Aerodry against CRA Annex I, requirement by requirement

The full conformity report referred to in entry 002. The same format we produce for manufacturers, applied to our own prototype.

Published: 29 Jul 2026

This is the report behind entry 002. It is the format we deliver to clients: each essential cybersecurity requirement of Annex I, its status on the prototype, the concrete evidence supporting that status, and the nature of the fix. The last column is usually the one that surprises, because it shows how many requirements are not solved by touching the code.

Status: ✗ not met · ◑ partially met · ✓ met · N/A not applicable.

Part I, security properties of the product

#	Requirement (Annex I, Part I)	Status	Evidence on the prototype	Nature of the fix
1	No known exploitable vulnerabilities when placed on the market	◑	Frozen dependencies, no CVE triage process	Process and SBOM
2	Secure configuration by default	✗	Fixed, shared access password; services in the clear by default	Firmware and manufacturing
3	Vulnerability fixes through updates	◑	OTA mechanism exists, but no secure channel	Firmware and infrastructure
4	Protection against unauthorised access	✗	Update endpoint and server without authentication	Firmware and infrastructure
5	Confidentiality of data, including encryption at rest and in transit	✗	Plain HTTP; the home’s Wi-Fi stored without encryption	Firmware
6	Integrity of data, commands, configuration and firmware	✗	Unsigned firmware; commands without verification	Firmware and infrastructure
7	Collect only the data needed	✓	Only temperature, humidity and relay state	Keep in the design
8	Availability of essential functions	◑	Safety cutoffs exist; no network protection against denial of service	Firmware
9	No harm to other devices or the network	✓	Small surface, no amplification effect	Keep in the design
10	Minimise the attack surface	◑	Few services, but the HTTP OTA is always on	Firmware
11	Reduce the impact of an incident	✗	No separation between the control function and the network interface	Firmware
12	Log security-relevant activity	✗	Operational logs exist, but no security events	Firmware
13	Allow data and settings to be erased at end of life	✗	No secure reset; credentials persist on resale	Firmware and documentation

Part II, vulnerability handling

#	Requirement (Annex I, Part II)	Status	Evidence on the prototype	Nature of the fix
1	Component inventory (machine-readable SBOM)	✗	Dependencies copied into the repository, no SBOM	Documentation and build
2	Fix vulnerabilities without delay	◑	The mechanism exists; the response process does not	Firmware and process
3	Regular security testing	✗	No defined test cycle	Process
4	Disclose fixed vulnerabilities	✗	No channel and no security history for the product	Process and organisation
5	Coordinated vulnerability disclosure policy	◑	The site’s security.txt is an embryo; PGP and a product policy are missing	Organisation
6	Make vulnerability reporting easy	◑	A generic contact exists; a dedicated security contact is missing	Organisation
7	Distribute updates securely	✗	OTA unsigned and without an encrypted channel	Firmware and infrastructure
8	Security updates available without delay and free of charge	◑	Technically possible; no committed support period	Process and infrastructure

The count

There are 21 applicable requirements, 13 in Part I and 8 in Part II. 2 are met, 8 are partially met, and 11 fail.

Entry 002 describes nine flaws: they are the ones with direct consequence for whoever uses the product, and they are spread across both parts. This annex shows the full table, including what the entry does not develop, such as the Part II process gaps, less visible but equally required.

The reading by nature of fix

If we look at the fixes by their nature, instead of requirement by requirement, firmware appears in about eleven requirements, but almost never alone. Infrastructure appears in about six, process in about seven, documentation in about four, and organisation in about four. Manufacturing appears in only one, the per-unit password, but that fix is mandatory and is not solved in code.

Bar chart: firmware appears in about eleven requirements, process in seven, infrastructure in six, documentation and organisation in four each, and manufacturing in a single requirement, whose fix is mandatory and lies outside the code. — The natures of the fix counted over the table: firmware almost never comes alone.

The sum passes 21 because most requirements need more than one nature of fix at the same time. That overlap is what makes the sequencing of the work, the subject of entry 003, the real value of the service, rather than the list itself.