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.

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:

Organisation	Primary emphasis
Saltzer & Schroeder	Security principles and secure system design
Microsoft	Secure development lifecycle and threat modelling
OWASP	Architecture, design reviews and secure engineering
NIST	Secure software development practices
CISA	Vendor responsibility and secure defaults
European Union	Lifecycle security and organisational accountability
Cloud providers	Secure 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
              │
Early 2000s Microsoft SDL and STRIDE threat modelling
              │
2000s–2020s OWASP threat modelling and secure design guidance
              │
2021        OWASP Top 10: Insecure Design
2022        NIST SSDF
2023        CISA Secure by Design
2024        Cyber Resilience Act
2020s       OWASP Secure-by-Design Framework
              │
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 structured guidance for translating security requirements into architectural controls before development.^[4]

Similarly, the NIST Secure Software Development Framework (SSDF) encourages organisations to define security requirements, protect software artefacts and integrate security throughout the development lifecycle rather than relying on testing alone.^[5]

Although these frameworks differ in implementation, they all move security earlier in the engineering process. Instead of asking how to secure completed software, they encourage teams to analyse security while architectural intent is still being formed.

A Common Thread

By the early 2020s, Secure by Design had become far more than a collection of engineering principles.

It had grown into a philosophy expressed through secure development lifecycles, threat modelling, architectural reviews and software engineering frameworks.

Despite their different terminology, Microsoft, OWASP and NIST all reinforce the same fundamental idea:

Security should be established by analysing architectural intent before software is implemented.

This perspective provides a useful way to understand the many definitions of Secure by Design. Rather than viewing it as a single framework, it is better understood as a family of approaches that use architectural intent as the point where security decisions are analysed, expressed and carried into implementation.

In recent years, governments have expanded this philosophy beyond engineering practice. Secure by Design is now becoming a regulatory expectation through initiatives such as CISA's Secure by Design guidance, the European Union's Cyber Resilience Act and NIS2.

Part 2: Governance, Regulation and Cloud Delivery

Secure by Design is no longer only an engineering concern. It now appears in public policy, regulatory expectations, cloud architecture guidance and DevSecOps practice. This second part looks at how the idea expanded from secure development methods into broader governance and lifecycle responsibility.

Modern Interpretations of Secure by Design

By the early 2020s, Secure by Design had evolved beyond a software engineering philosophy.

It had become a guiding principle for governments, regulators, cloud providers and software vendors alike. While each organisation emphasises different aspects of Secure by Design, they all share a common objective: reducing cybersecurity risk by ensuring security is established before deployment rather than corrected afterwards.

The result is not a new definition of Secure by Design, but an expansion of its scope. What began as an architectural and engineering discipline increasingly became an organisational and regulatory expectation.

Secure by Design as Public Policy

Perhaps the clearest example of this evolution is the guidance published by the United States Cybersecurity and Infrastructure Security Agency (CISA).

In 2023, CISA published Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default, arguing that software manufacturers should bear greater responsibility for the security of their products rather than expecting customers to compensate through complex configuration or operational controls.^[6]

Rather than focusing solely on engineering techniques, CISA emphasises outcomes.

Software producers should aim to:

Eliminate entire classes of vulnerabilities where practical.
Deliver secure default configurations.
Reduce customer security burden.
Support secure updates.
Design products that remain resilient throughout their lifecycle.

This represents an important evolution in Secure by Design.

Earlier guidance concentrated on how software should be engineered.

CISA expands the discussion to include who should be responsible for secure outcomes.

These perspectives are complementary. Secure engineering remains essential, but organisations are increasingly expected to embed security into the products they deliver rather than relying on customers to compensate for insecure designs.

Secure by Design in Europe

A similar trend is emerging within the European Union.

Rather than defining a single Secure by Design framework, recent legislation reinforces the expectation that cybersecurity should be considered throughout the software lifecycle.

The Cyber Resilience Act

The Cyber Resilience Act (CRA) establishes cybersecurity requirements for products with digital elements placed on the European market.^[7]

The Act requires manufacturers to consider cybersecurity throughout the lifecycle of a product, including secure development, vulnerability management and the provision of security updates.

Although technology-neutral, the CRA reinforces a central Secure by Design principle:

Cybersecurity should be incorporated during design and maintained throughout the lifecycle of a product.

NIS2

The NIS2 Directive extends cybersecurity governance across essential and important sectors.^[8]

Unlike the CRA, NIS2 primarily addresses organisational responsibilities rather than product requirements.

Nevertheless, it reflects the same philosophy by requiring organisations to integrate cybersecurity into governance, risk management and operational decision making.

The AI Act

The European Union’s AI Act reflects a related lifecycle approach for regulated AI systems.^[9]

Although it is not a Secure by Design framework, it requires providers of high-risk AI systems to address matters such as risk management, governance, transparency, quality management and ongoing monitoring.

Together with the CRA and NIS2, it illustrates a broader regulatory movement towards addressing risk during design and maintaining controls throughout the lifecycle.

Cloud Computing and DevSecOps

Cloud computing changed the way software is designed, deployed and operated.

Infrastructure became programmable.

Networks became software-defined.

Security policies became code.

Architectural decisions increasingly determined not only how systems were designed but also how they were deployed and governed.

Cloud providers such as AWS, Microsoft Azure and Google Cloud now publish comprehensive architectural guidance that embeds security into reference architectures rather than treating it as an operational afterthought.^[10]^[11]^[12]

Similarly, DevSecOps integrates security throughout the software delivery pipeline.

Threat modelling, policy validation, dependency analysis, infrastructure-as-code scanning and automated testing all aim to ensure that implementation remains consistent with architectural intent.

DevSecOps therefore does not replace Secure by Design.

It operationalises it.

A Convergence of Ideas

Viewed individually, Microsoft’s SDL, OWASP, NIST, CISA, the Cyber Resilience Act and DevSecOps emphasise different aspects of Secure by Design. Viewed together, they reveal a remarkably consistent pattern: each contributes a different perspective, yet all begin from the same premise:

Security should be established before implementation rather than imposed afterwards.

This shared foundation provides a useful way to understand Secure by Design as an evolving philosophy rather than a fixed definition.

What has changed over time is not the principle itself, but the mechanisms used to analyse architectural intent, express the resulting security expectations and verify that delivery remains aligned with them.

That evolution raises an important question.

If architecture is increasingly expected to guide software engineering, governance and compliance, how should it guide AI systems that are now participating directly in software development?

Part 3 explores how AI-assisted development may represent the next evolution of Secure by Design.

Part 3: AI-Assisted Development and Executable Architecture

AI-assisted development changes the way architectural security analysis needs to be communicated. This third part looks at why static documentation is not enough when AI coding tools participate in implementation, and why architecture increasingly needs to express the results of security analysis in a structured, machine-consumable form.

AI-Assisted Development and the Next Evolution

Artificial intelligence is changing how software is developed, but it does not change the need to analyse fundamental security implications before implementation.

Historically, software developers interpreted architecture before writing code. Design documents, architecture diagrams and conversations with architects provided the context needed to make implementation decisions. Experienced engineers could often infer architectural intent even when documentation was incomplete.

AI coding assistants operate differently.

They primarily consume implementation context:

Source code
APIs
Documentation
Unit tests
Natural language prompts

Architectural intent is often implicit rather than explicit.

As AI-generated software becomes more common, this creates a new challenge. Software may be syntactically correct, compile successfully and even pass automated tests, yet gradually diverge from the architecture on which its security assumptions depend.

This is not simply a coding problem.

It is an architectural communication problem.

From Documentation to Executable Knowledge

Traditionally, architecture has often been treated as documentation.

Architects create diagrams, developers implement systems and the documentation gradually becomes outdated as the software evolves.

For human teams this is inconvenient.

For AI-assisted development it becomes a significant limitation.

Security analysis performed while architectural intent is being defined increasingly needs to become explicit, structured and consumable by both people and machines.

Rather than documenting systems only after they have been designed, architecture can become the source from which human developers and AI agents analyse security implications and derive:

Security requirements
Architectural controls
Design constraints
Trust-boundary rules
Implementation guidance
Assurance evidence
Evaluation criteria

This represents an evolution of Secure by Design rather than a departure from it.

Security still begins with design.

The difference is that architectural security knowledge becomes active within software development: human developers and AI agents can consume it, act upon it and evaluate implementation against it rather than treating architecture as passive documentation.

Architecture as Executable Knowledge

One emerging direction is to treat architecture as executable knowledge.

Rather than existing solely as diagrams or design documents, architecture models become structured representations of architectural intent that can guide software engineering throughout the development lifecycle.

Requirements, controls, constraints, implementation guidance and evaluation criteria become linked expressions of the security analysis applied to the underlying architectural model.

This provides several potential benefits:

Improved consistency between architecture and implementation.
Better traceability from design decisions to delivered software.
Reduced ambiguity for development teams.
Stronger support for governance and assurance workflows.
Richer contextual guidance for AI coding assistants.

As software development becomes increasingly AI-assisted, this approach enables architecture to remain the point where security is analysed and translated into delivery guidance rather than becoming a static record of past decisions.

One Emerging Implementation

Several organisations are exploring ways to make architectural knowledge more directly usable throughout software development.

One example is iSecureByDesign, which uses structured architecture models and policy definitions to produce policy-backed specifications, security objectives, context-specific constraints and implementation guidance for both human developers and AI coding assistants.

Rather than replacing existing practices such as threat modelling, secure coding or DevSecOps, this approach complements them by preserving the results of security analysis from architectural design through implementation and evaluation.

Whether achieved through specialised tooling or future software engineering platforms, the broader direction is clear.

Architecture is becoming more than documentation.

It is becoming an active source of engineering knowledge.

Conclusion

Secure by Design has evolved considerably over the past fifty years.

What began as a collection of engineering principles became secure development lifecycles, architectural review processes, cloud governance frameworks and, more recently, regulatory expectations.

Today, AI-assisted software development presents another opportunity for evolution.

Throughout these changes, however, one idea has remained remarkably consistent.

Security is strongest when architectural intent is analysed before implementation begins and the resulting expectations guide delivery.

Microsoft's Security Development Lifecycle, OWASP's design principles, the NIST Secure Software Development Framework, CISA's Secure by Design guidance, the European Union's Cyber Resilience Act and modern cloud architecture frameworks all reinforce this principle from different perspectives.

What differs is not the philosophy itself, but the mechanisms used to analyse architectural intent, express the resulting security expectations and verify that implementation remains aligned with them.

As AI increasingly participates in software engineering, the security implications of architectural intent can no longer remain implicit or confined to static documentation. They must become explicit, structured and capable of guiding both human developers and AI-assisted development tools.

The technologies used to build software will continue to evolve, but the principle that security should be analysed before implementation has endured for more than fifty years. The next evolution of Secure by Design is unlikely to change that principle; it is more likely to make the results of architectural security analysis explicit enough to guide human developers, AI agents and assurance processes throughout delivery.

Acknowledgements

This article was developed using an AI-assisted research and writing process. AI supported source synthesis, drafting and structural editing. The author directed the analysis, reviewed the cited sources, final content and conclusions.

References

[1] Saltzer, J. H., & Schroeder, M. D. The Protection of Information in Computer Systems (1975). https://web.mit.edu/Saltzer/www/publications/protection/

[2] Microsoft. Security Development Lifecycle. https://www.microsoft.com/securityengineering/sdl

[3] Microsoft Learn. Threat Modeling Tool. https://learn.microsoft.com/azure/security/develop/threat-modeling-tool

[4] OWASP Foundation. Threat Modeling Process. https://owasp.org/www-community/Threat_Modeling_Process; A04:2021 – Insecure Design. https://owasp.org/Top10/2021/A04_2021-Insecure_Design/; and OWASP Secure-by-Design Framework. https://owasp.org/www-project-secure-by-design-framework/

[5] NIST. Secure Software Development Framework (SP 800-218). https://csrc.nist.gov/pubs/sp/800/218/final

[6] CISA. Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default. https://www.cisa.gov/resources-tools/resources/shifting-balance-cybersecurity-risk-principles-and-approaches-security-design-and-default

[7] European Commission. Cyber Resilience Act. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act

[8] European Commission. NIS2 Directive. https://digital-strategy.ec.europa.eu/en/policies/nis2-directive

[9] European Commission. AI Act. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

[10] AWS. AWS Well-Architected Framework – Security Pillar. https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/

[11] Microsoft Learn. Azure Well-Architected Framework. https://learn.microsoft.com/azure/well-architected/

[12] Google Cloud. Google Cloud Architecture Framework. https://cloud.google.com/architecture/framework