Update architecture and failure handling
An over-the-air (OTA) update delivers software or firmware over a wireless connection. Remote updating can also use wired networks; automatic installation is a separate property. A secure design authenticates the update and its intended target, protects signing keys, checks version policy and handles power loss safely. A/B partitions are one recovery strategy, not a universal requirement. RFC 9019 describes an IoT firmware-update architecture, not a finished mandatory manifest format. The device needs verification material, not the manufacturer’s fleet-wide private signing key. Test corrupted images, wrong targets, interrupted writes, revoked keys and attempts to install disallowed older versions.
CRA: requirements and engineering choices
CRA requirements are outcome-oriented and technology-neutral, based on the product’s cybersecurity risk assessment and applicability. Secure boot, a hardware root of trust, TPM, TrustZone and wireless OTA can be appropriate engineering controls; they are not universal legal mandates for every product. Document why the chosen controls satisfy the applicable requirements rather than equating one architecture with compliance.
Support, updates and SBOM
CRA Annex I requires applicable secure vulnerability-handling and update mechanisms. Automatic security updates have conditions and exceptions; automatic does not mean wireless. The support period is determined under Article 13(8), normally at least five years; where expected use is shorter, it corresponds to that use, while longer-use factors can require longer support. An SBOM must be machine-readable and cover at least top-level dependencies.
CRA scope and application dates
The CRA entered into force on 10 December 2024. Article 14 reporting has applied since 11 September 2026; the main product requirements apply from 11 December 2027. Article 69 contains transitional rules for previously placed products. Products subject to MDR or IVDR are excluded under Article 2(2); other exclusions and non-commercial free/open-source scope must also be checked.
Practical checklist
- Identify the product, intended use, market and applicable legal scope.
- Record the exact legal provisions, dates and applicable standard editions, including restrictions.
- Select the permitted assessment route and document the evidence needed.
- Link risk assessment, tests, product versions and declarations in the technical documentation.
- Assign responsibility for changes, support and responses to authorities.
This checklist supports planning; the applicable legal requirements determine the final assessment.