Secure by Design

Secure by design is an engineering philosophy in which security properties — confidentiality, integrity, availability, and resilience — are treated as first-class functional requirements from the earliest stages of product conception. Rather than treating security as a layer applied at the end of development (or, worse, only after a breach), secure-by-design organisations define security requirements alongside feature requirements, conduct threat modelling during architecture design, apply secure coding standards throughout development, and integrate security testing at every stage of the build pipeline. The approach recognises that the cost of fixing a security flaw increases exponentially the later in the lifecycle it is discovered.

The CRA's Annex I Part I requires manufacturers to ensure their products are designed, developed, and produced to achieve an appropriate level of cybersecurity based on the risks involved. The use of 'designed' as the first verb in this formulation is deliberate: the regulation requires security to be addressed at the design stage, not retrofitted. Article 13(1) reinforces this by requiring the cybersecurity risk assessment to be incorporated into the product during planning and design. The essential requirements in Annex I — including least privilege, attack surface reduction, and data minimisation — are architectural properties that can only be achieved through design-stage decisions.

Implementing secure by design requires embedding security into the Software Development Lifecycle (SDLC). Key practices include: defining security requirements and acceptance criteria before development begins; conducting formal threat modelling (e.g. using STRIDE or attack trees) during architecture design; applying secure coding standards such as OWASP Top 10 for web components or MISRA C for embedded firmware; conducting peer code review with security focus; integrating Static Application Security Testing (SAST) and dependency scanning into CI/CD pipelines; and requiring sign-off on security test results before any release reaches production. Security champions embedded in engineering teams help sustain this culture at scale.

The most common failure of secure-by-design intent is treating threat modelling as a compliance checkbox — producing a document at the start of a project and then never revisiting it as the architecture evolves. A second error is siloing security reviews to a specialist team that only engages at the end of development sprints, removing engineers from security decision-making. Manufacturers also frequently focus secure-by-design efforts on the application layer while neglecting the hardware abstraction layer, bootloader, and update mechanism — components that often have greater security impact. Secure-by-design must extend to every tier of the product.