Security by Design Under CRA Annex I: Practical Steps
Annex I requires products to be designed with security built in from the start — not added on afterwards. This post covers the practical security-by-design principles the CRA expects and how to implement them in your development process.
Security by Design Is No Longer Optional
Security by design means building security into a product from the requirements and architecture phase — not discovering gaps during a pre-release penetration test and patching them. Under the CRA, Annex I Part I makes security by design a legal requirement for all products with digital elements.
The key principles that Annex I encodes are:
1. Start with Threat Modelling
Before writing a line of code, identify what can go wrong. Threat modelling is the systematic analysis of a system's attack surface:
- STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is a widely used framework
- Map data flows, trust boundaries, and entry points
- Identify assets and their value to attackers
- Document mitigations for each identified threat
The output feeds directly into the Annex I risk assessment and the technical file.
2. Secure Defaults
Annex I Requirement 2 is explicit: products must ship in the most secure state possible. Practically, this means:
- No default passwords shared across devices — unique credentials per unit or mandatory first-boot change
- All unnecessary network services disabled by default
- Firewall rules set to deny-by-default
- Security logging enabled by default
- Automatic updates on by default where technically feasible
3. Least Privilege Architecture
Design components to run with the minimum permissions they need. A web server process should not have root access. A user-space application should not have kernel privileges. This limits the blast radius of exploitation.
4. Secure Update Mechanisms
Annex I requires update mechanisms that cannot be tampered with. Implement:
- Code signing for all firmware and software updates
- Verification of signatures before applying updates
- Rollback protection to prevent downgrade attacks
- Secure boot where applicable
5. Cryptography Done Right
Use current, standard cryptographic algorithms:
- AES-256-GCM for symmetric encryption
- RSA-2048 / ECDSA P-256 minimum for asymmetric
- TLS 1.2 minimum (TLS 1.3 preferred) for transport
- Argon2id or bcrypt for password hashing
- Avoid MD5, SHA-1, DES, 3DES, and RSA with padding vulnerabilities
6. Input Validation
Injection vulnerabilities (SQL injection, command injection, buffer overflows) are preventable. Validate all inputs at every trust boundary — especially inputs from untrusted sources (network, user input, external APIs).
7. Integrating Security into the SDLC
Security by design is not a one-time exercise — it requires security activities at every stage:
- Requirements: define security requirements, classify data, identify compliance obligations
- Design: threat modelling, security architecture review
- Development: secure coding standards, SAST scanning in CI
- Testing: DAST scanning, penetration testing, dependency scanning
- Release: final vulnerability scan, sign-off against Annex I checklist
- Operations: vulnerability monitoring, patch management, CVD process
Ready to assess your CRA compliance obligations?
Try the Free Applicability Checker