For decades, much of the software industry shipped first and patched later, and handed customers long hardening guides to close what was left open. Secure by design reverses that: security becomes a requirement decided when the product is designed, and the manufacturer takes responsibility for the outcome. It has moved from a slogan to government policy and, in the EU, to law.
What it means
A product that is secure by design:
- has security requirements identified and decided during design, alongside functional requirements;
- eliminates entire classes of vulnerability where possible, rather than fixing instances one at a time (memory-safe languages, parameterised queries, framework-level output encoding, authorization enforced in one layer);
- ships secure by default: safe out of the box, with essential protections such as MFA and logging turned on rather than left for the customer to configure;
- is maintained with a clear vulnerability disclosure and patching process for its whole supported life.
CISA's secure by design principles
The US Cybersecurity and Infrastructure Security Agency (CISA), with partner agencies from several countries, published guidance in 2023 built on three principles for software manufacturers:
- Take ownership of customer security outcomes. Don't push the burden of security onto customers through complex configuration and paid add-ons.
- Embrace radical transparency and accountability. Publish vulnerability data accurately (including CWE root causes in CVE records), and share what you've learned.
- Lead from the top. Make security a business priority owned by executives, not only by the security team.
In 2024 CISA added a voluntary Secure by Design Pledge, in which software companies committed to measurable goals such as increasing MFA use, eliminating default passwords and reducing whole vulnerability classes.
Secure by design in law: the Cyber Resilience Act
The EU Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force in December 2024. It applies to most products with digital elements sold in the EU, software included, and requires them to be designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks, to ship with a secure default configuration, and to receive security updates. Manufacturers must carry out and document a cybersecurity risk assessment. The obligation to report actively exploited vulnerabilities and severe incidents applies from September 2026; most other obligations apply from December 2027.
For EU-regulated organisations, NIS2 adds "security in network and information systems acquisition, development and maintenance" to the risk management measures in Article 21, which in practice pushes the same expectations onto suppliers.
How threat modeling makes it concrete
"Be secure by design" is an aspiration. Threat modeling is the activity that turns it into decisions. Each of the four questions maps to part of the idea:
| Secure-by-design need | Threat modeling output |
|---|---|
| Understand the risks before building | DFD with trust boundaries and assets |
| Address threats in the design, not after release | Threats found per element, attack trees for the serious ones |
| Eliminate classes, not instances | Treatments that change the design (avoid) or enforce controls in one place |
| Documented risk assessment (CRA, ISO 27001) | Risk register with scores, decisions, owners and residual risk |
| Accountability | Named owners and accepted residual risks |
Worked example: Invoicely
Several decisions in the Invoicely model are secure by design in the strict sense, because they remove classes of problem rather than patching instances:
- Authorization in the data access layer: every query is scoped to the customer, so new endpoints can't reintroduce IDOR (T2).
- No raw storage links in email: PDFs are reached through the app, which removes T3 and most of T10 at once.
- Session in an httpOnly cookie: script can't read it, so any future XSS can't steal sessions (T8).
- Card data never touches Invoicely: the payment provider's hosted fields collect it, avoiding a whole compliance scope.
- Secure defaults: MFA offered to every customer at no extra cost, and audit logging on from day one.
Common mistakes
- Equating secure by design with a security review before launch. By then the design is fixed. The point is to influence it.
- Hardening guides instead of hardened defaults. If customers must follow a 40-page guide to be safe, most of them won't.
- No evidence. A design decision that isn't recorded can't be shown to an auditor or regulator, or remembered by the next team.
Key takeaways
- Secure by design treats security as a requirement decided at design time, not a defect found after release.
- CISA's version rests on three principles: take ownership of customer security outcomes, embrace radical transparency, and lead from the top.
- Secure by default is its partner: the product is safe in its default configuration, without hardening guides.
- Threat modeling is how secure by design becomes concrete: it turns "be secure" into specific design decisions with owners.
Frequently asked questions
What is the difference between secure by design and secure by default?
Secure by design is about how the product is built: security requirements, architecture and development practices from the start. Secure by default is about how it ships: the out-of-the-box configuration is the secure one, for example MFA on and logging enabled, without extra effort from the customer.
What are CISA's secure by design principles?
CISA's guidance, developed with international partners and first published in 2023, sets out three principles for software manufacturers: take ownership of customer security outcomes, embrace radical transparency and accountability, and build organisational structure and leadership to achieve these goals.
Is secure by design a legal requirement?
Increasingly, yes. The EU Cyber Resilience Act requires products with digital elements sold in the EU to be designed, developed and produced to ensure appropriate cybersecurity, and to ship with a secure default configuration. Its vulnerability reporting obligations apply from September 2026 and most other obligations from December 2027.
How does threat modeling support secure by design?
Threat modeling is the design-time activity that finds what can go wrong before code is written and records what will be done about it. Its outputs, the threats, decisions and residual risks, are also the evidence that a product was designed with security in mind.