Security by Design

Security by design is the principle that cybersecurity must be integrated into a product from the design phase. Instead of adding security as a layer on top of a finished product, security measures are built into the architecture from the outset. The principle is a binding requirement under the Cyber Resilience Act (CRA).

Back to Dictionary

What is security by design?

Security by design is an approach where security is treated as a fundamental design requirement rather than an afterthought. The idea is straightforward: it is cheaper, more effective and more secure to build security in from the start than to patch vulnerabilities afterwards.

Traditionally, many software producers developed functionality first and then attempted to secure the product. The result has been products with architectural weaknesses that are expensive or impossible to remedy without redesigning the entire system. Security by design reverses that logic.

The concept is closely linked to "security by default", which means the product is delivered in its most secure configuration without requiring action from the user. Together, the two principles form the foundation of CRA's approach to product security.

Legal requirements in CRA and GDPR

The Cyber Resilience Act makes security by design a binding requirement for all products with digital elements. CRA Annex I specifies that products must be "designed, developed and produced in a manner that ensures an appropriate level of cybersecurity based on the risks."

Concretely, CRA requires manufacturers to:

Deliver products without known, exploitable vulnerabilities
Apply secure default configuration
Protect against unauthorised access with appropriate access control
Protect data with encryption or equivalent mechanisms
Minimise the attack surface
Ensure that the product can be updated

GDPR sets a corresponding requirement in Article 25 on "data protection by design and by default". Whilst GDPR focuses on personal data, CRA focuses more broadly on cybersecurity. The two frameworks complement each other, and organisations already working with privacy by design have a solid starting point.

NIS2 also presupposes security by design in organisations' risk management measures, and DORA sets corresponding requirements for ICT systems in the financial sector.

Core principles

Security by design builds on a range of well-established principles that together reduce the risk of security gaps:

Least privilege: Users and components should only have the permissions necessary to perform their function. A component that only needs to read data should not have write permissions.

Defence in depth: Security should not depend on a single control. Multiple independent security layers ensure that compromise of one layer does not lead to complete exposure. Network segmentation is a classic example.

Minimisation of the attack surface: The fewer entry points a product exposes, the fewer opportunities an attacker has. Unnecessary ports, protocols and features should be disabled by default.

Secure default configuration: The product must be secure out of the box. No default passwords, no open admin interfaces, no unnecessary services enabled.

Fail securely: When something goes wrong, the system should fail to a secure state. An authentication failure should result in denial, not access.

These principles are not new. They have been described for decades by security professionals. CRA's contribution is making them legal requirements with real sanctions for non-compliance.

Implementation in practice

Implementing security by design requires changes throughout the development process:

Threat modelling: Start by identifying what can go wrong. Threat modelling in the design phase uncovers potential attack vectors before the first line of code is written. Use methods such as STRIDE or PASTA to structure the analysis.

Security requirements: Define security requirements as part of the requirements specification. It is not sufficient to state "the product must be secure." Specify concrete requirements for authentication, encryption, logging and error handling.

Secure coding practices: Apply recommendations from OWASP and similar resources. Conduct code reviews with a security focus and use static analysis tools to catch common vulnerabilities.

Testing: Security testing must be an integral part of the testing process. Penetration testing and vulnerability scanning supplement functional testing and ensure that security requirements are actually met.

Update mechanism: Design the product so it can receive security updates throughout its lifetime. CRA requires manufacturers to deliver updates for at least five years.

Frequently Asked Questions about Security by Design

What does security by design mean?

Security by design means that cybersecurity is considered from the very start of a product's development. Instead of adding security measures after the product is built, security is integrated into architecture, design and development processes from day one.

Is security by design a legal requirement?

Yes. The Cyber Resilience Act (CRA) requires products with digital elements to be designed and developed with security as an integral part. GDPR sets a corresponding requirement for data protection by design (Article 25). NIS2 also presupposes security by design in organisations' risk management.

What is the difference between security by design and security by default?

Security by design concerns integrating security into the design process itself. Security by default means the product is delivered in its most secure configuration as standard, without the user needing to make further adjustments. CRA requires both.

What concrete requirements does CRA set for security by design?

CRA requires, among other things, minimisation of the attack surface, secure default configuration, encryption of data, access control, protection against unauthorised access, and that the product is delivered without known exploitable vulnerabilities. The product must also be able to receive security updates.

How does one implement security by design in practice?

Start with threat modelling in the design phase. Define security requirements as part of the specification. Apply secure coding principles, conduct code reviews and security testing continuously. Minimise the attack surface, implement the principle of least privilege and ensure secure default configuration.