“Security by design” is a phrase that appears throughout the CRA and its accompanying guidance. It is also a phrase that can mean almost anything in practice. For manufacturers preparing for the December 2027 conformity deadline, the question is not whether they believe in security by design in principle. It is whether their development process produces the evidence that the regulation requires.
This post sets out what the CRA actually expects, at each stage of the product development and engineering (PDE) lifecycle, and what that means for teams building products with digital elements for the EU market.
What the CRA Means by Security by Design
Annex I of the CRA sets out the essential requirements that products with digital elements must meet. Several of these requirements directly reflect security-by-design principles:
- Products must be delivered with a secure default configuration.
- Products must be designed to limit attack surfaces, including external interfaces.
- Products must be designed to protect against unauthorised access.
- Products must protect the confidentiality and integrity of data they process.
- Products must minimise their own impact when compromised.
These are not documentation requirements. They are design requirements. A product that does not meet them cannot receive CE marking regardless of how thoroughly its documentation is prepared. The regulation assumes that a compliant product was built to be secure, not that it was built and then documented as secure.
Risk Analysis as a Starting Obligation
Article 13 requires manufacturers to conduct a cybersecurity risk assessment before a product is placed on the market. This assessment must inform the product design and must be documented as part of the technical documentation required under Annex VII.
The risk analysis must cover:
- The intended use and foreseeable misuse of the product.
- The assets present in or processed by the product.
- Threats to those assets and the attack paths available to an adversary.
- The severity and likelihood of each identified risk.
- The security controls selected to address those risks.
This is not a one-time exercise. The regulation requires the risk analysis to be reviewed and updated when the product changes, when new threats emerge, and at regular intervals during the product support period. The initial risk assessment that supports a conformity declaration must be kept current for the lifetime of the product.
Threat Modelling as an Engineering Practice
The most effective way to conduct the risk analysis the CRA requires is threat modelling at the design stage. Threat modelling is the practice of systematically identifying how an adversary could attack a system, using structured methods such as STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) or PASTA (Process for Attack Simulation and Threat Analysis).
For PDE development teams, the practical value of threat modelling is that it surfaces security gaps before they are embedded in code. A vulnerability that is identified during threat modelling costs a few hours of design revision. The same vulnerability identified post-release requires a patch, coordinated disclosure, potential reporting under Article 14, and customer communication. The cost differential is not marginal.
The CRA does not mandate a specific threat modelling methodology. What it requires is evidence that threats were considered systematically and that the design reflects the conclusions. A threat model document, or structured notes from a threat modelling session, forms part of the technical documentation that supports the conformity declaration.
The Role of Automated Testing
Annex I requires that products be tested against their security requirements before being placed on the market. For software components of products with digital elements, this typically involves a combination of static analysis, dynamic analysis, and dependency scanning.
Static analysis
Static application security testing (SAST) analyses source code for vulnerability patterns without executing the code. Common tools include Semgrep, CodeQL, and SonarQube. SAST is effective at finding memory safety issues, injection vulnerabilities, hardcoded credentials, and insecure API usage. For teams using compiled languages such as C or C++, SAST combined with fuzzing has historically found the majority of critical vulnerabilities before release.
Dynamic analysis
Dynamic application security testing (DAST) and fuzzing test the running application. DAST tools send crafted inputs to running interfaces and observe responses. Fuzzing generates large volumes of semi-random inputs to trigger unexpected behaviour. For products with network interfaces, web APIs, or parsing components, dynamic testing routinely finds vulnerabilities that static analysis misses, particularly in edge cases around protocol handling and input validation.
Dependency scanning
Products with digital elements frequently incorporate open source components with their own vulnerability histories. The CRA requires manufacturers to track the components in their products and to respond when new vulnerabilities are disclosed in those components. Automated Software Composition Analysis (SCA) tools cross-reference the SBOM against known vulnerability databases and generate alerts when a dependency becomes vulnerable. This is not optional tooling for CRA compliance. It is the operational mechanism through which a manufacturer discovers that one of their products may require a patch or an Article 14 report.
Turning Technical Results Into Compliance Evidence
The security testing outputs described above are only valuable for CRA compliance if they are captured, interpreted, and retained as evidence. A SAST scan that found no critical findings is evidence. A DAST test that identified and then remediated three vulnerabilities is evidence. A threat model document showing that a particular attack path was considered and mitigated at the design stage is evidence.
The challenge for development teams is that the tooling and the compliance documentation are typically owned by different functions. Engineers run scans in CI/CD pipelines; compliance managers maintain Annex VII technical documentation. Without a structured bridge between them, test results accumulate in build logs that nobody reads, and the technical documentation reflects what engineers intended to do rather than what they demonstrably did.
Building that bridge early, as part of the development workflow rather than as a compliance retrofit, is what separates organisations that will be able to produce a complete conformity declaration from those that will be reconstructing evidence under time pressure in late 2027.
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.