What does secure by design mean?

Secure by design is the principle that a product, hardware or software, is designed and built from the ground up to be secure by construction, rather than secured with patches added on after release, when a wrong architectural choice has already been made and changing it costs far more time, money and engineering effort than getting it right from the start. The principle has a complementary twin, secure by default, which concerns the configuration the product ships with rather than the design choices behind it: not how it was built, but what is active on day one, before anyone touches an admin panel. Both principles were jointly promoted by CISA, the US cybersecurity agency, in the guidance published in 2023, signed by dozens of software manufacturers, and are now cited as essential cybersecurity requirements by the Cyber Resilience Act for products with digital elements sold in the European Union.

See also: Cyber Resilience Act (CRA) · EU regulation imposing mandatory cybersecurity requirements on products with digital elements: SBOM, vulnerability notification, CE marking.

Design versus configuration: the sharp difference

Secure by design concerns the decisions made upstream, when the architecture is laid out: which protocols to use, how to isolate components, how to manage permissions between services, how to minimize the attack surface starting from the data model itself. Secure by default instead concerns the state the product ships in: whether multi-factor authentication is already on or has to be switched on manually, whether unnecessary ports are closed or left open for convenience, whether a default password still exists somewhere. A product can have a solid architecture and still ship with a weak configuration, which is why the two principles need to be treated together rather than as interchangeable synonyms: one is a quality of the design, the other is a quality of the first experience of using it.

An enterprise example

A vendor of collaboration software for large organizations can ship its platform with multi-factor authentication mandatory for every administrative account, access logging on by default, and no management port exposed publicly without explicit configuration. That is the exact opposite of a product that ships with security turned off by default, perhaps to keep onboarding simple, leaving it to each individual customer to notice the risk and turn the protections on. In the first case the least attentive customer is still protected; in the second, security depends on how competent and diligent whoever installs the product happens to be, a bet that large organizations cannot afford to make across hundreds of different vendors.

Why it matters for decision makers

Fixing an architectural flaw after release costs orders of magnitude more than designing it well from the start: an isolation problem between services discovered in production often requires a rewrite, not a patch. Under the Cyber Resilience Act, security by design is also no longer just good practice but a legal requirement for anyone selling products with digital elements in the EU, with liability falling on the manufacturer. It should be kept distinct from the privacy by design principle in Article 25 of the GDPR, an adjacent but not equivalent concept: that one concerns protecting personal data from the design of the processing itself, this one concerns the technical security of the product as a whole. Operationally, the principle is translated into day-to-day development practice through DevSecOps, which builds security checks into the release pipeline; but the decision to design for security comes first, and it is an architectural choice, not a tool to bolt onto a pipeline.