What is Secure by Design? | News | iSecureByDesign

Article<br>2026-07-09

What is Secure by Design?

Executive Summary

Secure by Design is the practice of shaping a system’s security by analysing architectural intent before implementation. Modern approaches increasingly extend this philosophy by translating that analysis into requirements, controls, constraints, implementation guidance and evaluation criteria that remain connected to implementation and delivery.

Contents

Introduction - Why Secure by Design has multiple interpretations

Part 1: Principles and Engineering Practice - How Secure by Design moved from design principles into engineering practice

Part 2: Governance, Regulation and Cloud Delivery - How Secure by Design became an organisational and regulatory expectation

Part 3: AI-Assisted Development and Executable Architecture - Why AI coding tools need explicit design context

Conclusion - Why early security analysis remains the foundation

Introduction

In engineering circles, few terms are used as widely—or interpreted as differently—as Secure by Design . Secure by Design has no single universally accepted definition. Instead, governments, standards bodies and engineering organisations emphasise different aspects of a shared underlying philosophy. These are not competing definitions so much as complementary interpretations of a common principle:

OrganisationPrimary emphasisSaltzer & SchroederSecurity principles and secure system designMicrosoftSecure development lifecycle and threat modellingOWASPArchitecture, design reviews and secure engineeringNISTSecure software development practicesCISAVendor responsibility and secure defaultsEuropean UnionLifecycle security and organisational accountabilityCloud providersSecure architecture, governance and operational guardrails

While these perspectives differ, they all reinforce the same underlying principle:

Security should be analysed and shaped while architectural intent is still being defined, before implementation begins.

Architectural intent is the set of design decisions that define how a system is expected to behave, be secured and be governed. It is not sufficient on its own: Secure by Design depends on analysing that intent early, identifying its security implications and translating the results into requirements, controls, constraints and delivery guidance.

Part 1: Principles and Engineering Practice

Secure by Design began as a set of system design principles and gradually became a practical engineering discipline. This first part looks at how the idea moved from foundational security principles into secure development lifecycles, threat modelling, architecture reviews and software engineering practice.

The Evolution of Secure by Design

Understanding how Secure by Design has evolved helps explain why it has become central to software engineering—and why AI-assisted development is bringing renewed attention to architectural intent.

1975 Saltzer & Schroeder<br>Early 2000s Microsoft SDL and STRIDE threat modelling<br>2000s–2020s OWASP threat modelling and secure design guidance<br>2021 OWASP Top 10: Insecure Design<br>2022 NIST SSDF<br>2023 CISA Secure by Design<br>2024 Cyber Resilience Act<br>2020s OWASP Secure-by-Design Framework<br>Today Architecture as Executable Knowledge

From Principles to Practice

Although the phrase Secure by Design is relatively modern, the philosophy behind it stretches back decades.

In 1975, Jerome Saltzer and Michael Schroeder published The Protection of Information in Computer Systems, introducing design principles that continue to influence secure systems today.[1] These included least privilege, fail-safe defaults, complete mediation and economy of mechanism—principles that remain relevant despite enormous changes in programming languages, deployment models and computing platforms.

Operationalising Secure by Design

As software systems became larger and more connected, these architectural principles evolved into structured engineering practices.

Microsoft's Security Development Lifecycle (SDL) integrated security throughout software development rather than treating it as a final testing activity.[2] Threat modelling became a core practice, encouraging teams to identify assets, trust boundaries and potential attacks before implementation. Microsoft's threat-modelling approach, supported by the STRIDE threat-classification model, demonstrated how architecture diagrams could become practical security tools rather than simply documentation.[3]

Over time, the OWASP community promoted architecture-focused practices through its guidance on threat modelling, trust boundaries, security requirements and secure design. This direction became especially visible in 2021 when Insecure Design entered the OWASP Top 10, distinguishing design flaws from implementation defects and encouraging organisations to address security before coding. OWASP has since consolidated these ideas in its Secure-by-Design Framework, which provides...