Security by design is a core requirement of the Cyber Resilience Act (CRA). Manufacturers preparing for conformity assessment must build verifiable evidence into their daily engineering workflows.
This guide explains the design expectations across the product lifecycle and how teams produce compliance evidence.
Core Security by Design Principles
Annex I establishes mandatory security requirements for products with digital elements:
- Products must ship in a secure default state.
- Designs must limit attack surfaces and external interfaces.
- Systems must prevent unauthorized access.
- Implementations must protect data confidentiality and integrity.
- Architecture must limit the blast radius if a component is compromised.
These are mandatory engineering requirements. A product must meet these standards before receiving CE marking.
Mandatory Risk Assessment
Article 13 requires manufacturers to conduct a cybersecurity risk assessment before placing a product on the market. This assessment guides the technical architecture and forms part of the Annex VII technical file.
The risk analysis must cover:
- Intended use and foreseeable misuse.
- System assets and communication flows.
- Threat vectors and potential attack paths.
- Likelihood and impact ratings for identified risks.
- Selected technical controls and mitigations.
Manufacturers must review and update the risk assessment throughout the product support period whenever new threats or system modifications occur.
Threat Modelling as an Engineering Standard
Threat modelling during early design phases identifies security gaps before code is written. Structured methodologies like STRIDE or PASTA help teams examine potential weaknesses systematically.
Addressing architectural flaws during design costs far less than releasing post-market patches. The CRA requires documented evidence that threats were evaluated systematically and mitigated in the final design.
Automated Security Testing
Annex I mandates pre-market security verification. Software components require a structured testing pipeline:
Static Application Security Testing (SAST). SAST tools inspect source code for vulnerability patterns without running the application. These tools detect memory issues, injection flaws, and hardcoded credentials.
Dynamic Testing and Fuzzing. Dynamic testing inspects running applications by sending crafted inputs to network interfaces. Fuzzing tests protocol handling and input validation boundaries under high-volume randomized traffic.
Software Composition Analysis (SCA). SCA tools monitor the Software Bill of Materials (SBOM) against vulnerability registries. Automated tracking alerts developers when third-party components disclose new vulnerabilities.
Generating Compliance Evidence
Testing outputs serve as evidence only when captured and linked to compliance records. Clean SAST reports, documented remediation of dynamic test findings, and structured threat models all prove conformity.
Connecting automated CI/CD pipeline results to the Annex VII technical file ensures continuous compliance and simplifies regulatory audits.
Summary
Security by design requires structured risk analysis, continuous threat reviews, automated testing, and auditable documentation. Embedding these practices early ensures smooth compliance for the December 2027 conformity deadline.
The Lifecycle Obligation
Security by design is not a project that ends when a product ships. The CRA requires manufacturers to maintain security throughout the support period, which must be a minimum period proportionate to the expected product lifetime. For most connected products, this means years of continued vulnerability monitoring, patch development, and reporting obligations.
The engineering and compliance processes described above must therefore be sustainable, not heroic. A threat model that is never updated, a SAST scan that runs once at release, or a dependency scan that nobody acts on are compliance artefacts without compliance value. The test is whether the processes function continuously, with the same rigour, for the life of every supported product in the portfolio.
The Practical Starting Point
For teams that do not yet have these practices in place, the priority ordering is: risk analysis first (it informs everything else), threat modelling next (it is cheapest at the design stage), dependency scanning third (it is the most likely source of an Article 14 trigger), and then SAST and DAST as the engineering pipeline matures.
None of these require new tooling that does not already exist. The barrier is almost always organisational: making security evidence capture part of the development workflow, not an afterthought that happens once before a compliance audit.