Secure by Design: The Philosophy That Became Policy?

Six years ago, arguing for Secure by Design meant justifying the upfront cost to people who weren’t convinced the risk was real. The EU Cyber Resilience Act now mandates secure-by-default configurations by law. NIS2 holds management personally liable for how software gets developed and procured. ISO/IEC 27001:2022 names “security by design” verbatim.

The case for Secure by Design has been made. By regulators, but above all by its success. This means the conversation for C-level leaders has shifted: not whether SbD applies to your organization, but how prepared you are when enforcement does.

Secure by Design Before It Was Mandatory

We started building Secure by Design services six years ago. At the time, it was a bet: security built into a system from the start produces fewer vulnerabilities, lower remediation costs, and fewer architectural surprises later. While most clients understood this, convincing their procurement teams took longer.

What has changed is not the principle. Regulators did not invent Secure by Design. They looked at what happened when organizations applied it consistently, and what happened when they didn’t. CRA, NIS2, and ISO 27001:2022 reflect those findings. Compliance started to require Secure by Design principles because they work. Not the other way around.

What CRA, NIS2, and ISO 27001 Require

EU Cyber Resilience Act: “Secure by default” as a product requirement

In force since December 2024, the CRA requires manufacturers of products with digital elements to ensure those products are “designed, developed and produced” in line with essential cybersecurity requirements (Art. 13, Annex I). The specifics: products must ship with “a secure by default configuration,” must “limit attack surfaces, including external interfaces,” and must include mechanisms to minimise exploitation impact.

Non-compliant products cannot carry the CE mark. They cannot enter the EU market. Reporting obligations begin September 2026, full enforcement December 2027. Penalties reach €15 million or 2.5% of global turnover.

NIS2 and Its DACH Implementations: Where SbD becomes a board-level liability

Art. 21(2)(e) requires essential and important entities to address “security in network and information systems acquisition, development and maintenance.” Art. 21(3) pulls suppliers into scope: organisations must verify that vendors follow “secure development procedures.” Security in the development process is now a procurement criterion.

The liability is personal. Art. 20 requires management bodies to approve cybersecurity measures and holds them accountable when those measures fall short. Germany’s revised BSIG (§38, in force December 2025) makes this explicit at the national level. Austria’s NISG 2026 follows in October 2026.

ISO/IEC 27001:2022, Control A.8.27:The standard most organisations already certify against now names it directly

The 2022 revision introduced Control A.8.27 “Secure system architecture and engineering principles.” Its guidance lists “security by design” and “security by default” as required architectural principles alongside least privilege, defence in depth, and fail securely. Controls A.8.25 and A.8.28 cover the secure development lifecycle and secure coding respectively.

The transition deadline was October 2025. Certificates issued after that date carry a formal commitment to these controls. The harder question is whether the engineering practice behind them does too.

The Regulatory Momentum Behind Secure by Design

CRA, NIS2, and ISO 27001 are the most visible pressure points but the direction runs deeper. DORA requires financial sector firms to “design, procure and implement” ICT security from the ground up. The EU AI Act mandates that high-risk AI systems be “conceived and developed” with cybersecurity built in. The revised Product Liability Directive makes a cybersecurity vulnerability sufficient grounds for a product defect claim. IEC 62443 lists Secure by Design as an explicit development practice for industrial systems.

Those regulations apply to different sectors and come from different regulatory bodies, but the underlying logic stays consistent: security has to be designed in from the start.

Secure by Design as a C-Level Compliance Risk

Three consequences reach beyond the security team:

Personal liability is no longer theoretical. NIS2 Art. 20, Germany’s §38 BSIG, and DORA Art. 5 establish direct management accountability for cybersecurity failures. This cannot be delegated to a CISO. Approving a budget without approving the security measures it funds is no longer a defensible position.

Your supply chain is now your compliance perimeter. NIS2 Art. 21(3) and CRA Art. 13 require organisations to verify that vendors follow secure development procedures. Vendor questionnaires that ask about certifications but not development practices will not hold up under audit. What your suppliers build, and how they build it, is part of your risk profile.

Certification without practice creates a new category of risk. Holding an ISO 27001 certificate issued after October 2025 implies Control A.8.27 compliance. If your development teams are not building to those principles, the gap between your certificate and your practice is a liability in an audit, and potentially in court under the revised Product Liability Directive.

Secure by Design as Competitive Advantage

Meeting the regulatory threshold for Secure by Design, however, is not the same as doing it well. Organizations that approach CRA and NIS2 as a checklist will spend more on remediation than those that treat SbD as a design principle because retrofitting compliance into an existing architecture is consistently more expensive than building to it from the start.

Organizations that move early also tend to move through audits faster, pass supplier security assessments more cleanly, and spend less time rebuilding their security posture each time regulation shifts. But while compliance sets the floor, the real competitive position sits above it.

Why We Built on Secure by Design Before It Was Law

When we started offering Secure by Design consulting six years ago, there was no CRA, no revised ISO 27001, no management liability under NIS2. We committed to SbD early because the logic was already clear: security decisions made at the architecture stage are cheaper, more effective, and easier to validate than decisions made under pressure later. That has not changed.

Secure by Design is not the regulatory standard because legislators decided it should be. It became the standard because organisations that applied it built systems that held up under attack, under audit, under pressure. Legislators looked at that record and wrote it into law.

For organisations ready to move from principle to practice, ENISA’s Security by Design and Default Playbook (March 2026) provides the operational detail: 22 engineering checklists covering the full product lifecycle, designed for teams that want to implement SbD rather than retrofit it. Read the playbook here.