The gateway requirement
Annex I Part I opens with the rule everything else hangs from: products must be designed, developed and produced so that they ensure an appropriate level of cybersecurity based on the risks, and must be made available without known exploitable vulnerabilities.
"Based on the risks" is the key phrase. There is no fixed technical checklist — the depth of each control is justified by your risk assessment (lesson: threat modelling). "Without known exploitable vulnerabilities" is much harder: it means at the moment of placing on the market you must know what is in your firmware and whether any of it has a published exploitable CVE.
The property requirements, translated
| Annex I requirement | What it means in firmware |
|---|---|
| Secure by default configuration | No default passwords. First-boot credential setup or per-device provisioned secrets. Debug interfaces disabled in production builds. Insecure protocols off unless explicitly enabled. |
| Protection from unauthorised access | Authentication on every management interface, including local serial and BLE commissioning. Identity and access management proportionate to the risk. |
| Confidentiality of data | Encryption at rest for stored credentials and personal data; TLS with certificate validation in transit. Keys held in a secure element or protected flash region, never in plain firmware. |
| Integrity of data, commands, configuration | Verified boot, signed firmware images, authenticated configuration writes, rollback protection. |
| Data minimisation | Process only data adequate and relevant for the intended use — the CRA imports a GDPR-shaped principle into product design. |
| Availability of essential functions | Resilience to DoS; a safe degraded mode when the network or cloud is unavailable. |
| Minimising negative impact on other systems | Do not become a DDoS bot or a network scanner. Rate-limit outbound traffic. |
| Limiting attack surface | Disable unused services, strip debug tooling, remove unused shell utilities and interpreters from the rootfs. |
| Mitigating exploitation | ASLR, stack canaries, W^X/MPU regions, compiler hardening flags, memory-safe languages where practical. |
| Security information recording and monitoring | An auditable security log with opt-out — record authentication events, config changes, update activity. |
| Secure updates and secure data removal | Automatic security updates where appropriate, with user opt-out; and a function to securely and permanently erase all user data and configuration. |
Two requirements teams routinely miss
Secure data removal. Factory reset must actually destroy keys and user data, not just clear a flag. On a device with a secure element, that means erasing or rotating the key material; on raw flash, it means considering wear-levelling and remapped blocks.
Security logging with opt-out. The record-and-monitor requirement is explicitly opt-out, so you need a logging subsystem, a defined event set, a retention policy, and a documented switch — plus a way for users to access the logs.
How to use this list
Turn it into a requirements matrix: one row per Annex I item, columns for "applicable / not applicable with justification", "how implemented", "evidence". That matrix is a required part of your technical documentation, and it is also the fastest way to find the gaps while you can still fix them cheaply.