What is secure by design?

Secure by design is an approach to building software and systems in which security requirements, risks, and protective measures shape decisions from the earliest design stages. Instead of relying only on checks after implementation, teams consider how architecture, data flows, trust boundaries, and user access affect security throughout development and operation.

The UK NCSC describes secure by design as integrating security from the beginning of the development lifecycle through deployment. The approach can reduce preventable weaknesses, but it cannot make a product vulnerability-free. Requirements can be incomplete, code can contain defects, dependencies can change, and threats can evolve after release.

Secure by design does not have one universal checklist. Government guidance and engineering frameworks differ in how they organize the practices, but several recurring ideas help explain the approach.

• Understand risks before design decisions harden: identify the system's purpose, valuable data, trust boundaries, and plausible threats. Threat modeling is one way to make assumptions visible while architecture can still change.
• Reduce opportunities for compromise: keep the exposed functionality and access rights appropriate to the system's purpose. Least privilege, separation, and careful handling of untrusted input can reduce avoidable paths to sensitive resources.
• Limit the impact of a failure: design for containment and resilience so that a compromise in one component does not automatically expose every connected system or data set.
• Make security maintainable: consider logging, updates, dependency handling, and vulnerability response so protections can be reviewed as the product changes.

CISA's Secure by Design guidance places responsibility for customer security outcomes on software manufacturers and describes a specific set of principles. That framing is useful, but it is CISA's guidance rather than a single definition adopted by every organization. The common engineering point is to make security part of product decisions, not a final inspection alone.

Secure by design addresses how security shapes a product's architecture and development process. Secure by default addresses whether users receive safer settings and protections without having to enable them manually. A product can be one without the other, though both together are stronger.

For example, a service might enforce HTTPS and disable legacy protocols out of the box (secure by default) but lack threat modeling in its architecture (not secure by design). Conversely, a system built with careful threat modeling (secure by design) might still ship with permissive defaults that users must harden.

Secure by design concerns how security shapes the product's architecture and development. Secure by default concerns the initial security posture users receive, including whether protective settings are enabled without requiring customers to discover and configure them themselves.

For example, an application can be designed to support strong authentication and also enable safer authentication settings when first installed. The concepts reinforce each other: design makes protective behavior possible, while defaults make it more likely that users receive that protection. CISA's guidance discusses both principles, but they describe different parts of product security.

Secure by design begins before implementation and continues through release and maintenance. The exact activities depend on the product and its risks, but the lifecycle typically connects several kinds of decisions.

During requirements and design, teams identify assets, threats, trust boundaries, and security expectations. Architecture choices determine how components communicate, where sensitive data moves, and which actors can access it. These assumptions should be documented well enough to revisit when the system changes.

During development, teams apply secure coding practices, review changes, and consider risks in dependencies and the development environment. Verification then checks whether intended protections exist in the implementation. Depending on the system, this can include code review, static application security testing, dynamic testing, or targeted manual assessment.

Deployment and operation bring new considerations: configuration, monitoring, updates, and vulnerability handling. NIST's Secure Software Development Framework describes practices that can be integrated into different SDLC models. It is a framework for secure software development, not a claim that one lifecycle model guarantees security.

Findings from testing, incidents, and updates should feed back into requirements and architecture reviews. A control that worked for the original deployment may not cover a new integration or a changed trust boundary.

These terms overlap, but they describe different ideas. Secure by design focuses on the security of the product and the decisions that shape its architecture. Shift left means moving security activities earlier in development so issues can be found sooner. DevSecOps integrates security practices into development, delivery, and operations processes. Mad Devs' glossary explains DevSecOps in that delivery context.

A team can use shift-left checks and DevSecOps practices to support secure development, while still needing to consider whether the underlying product design handles its risks appropriately. Conversely, a sound architecture does not remove the need for ongoing security practices in code, pipelines, and production. These approaches can complement one another without being synonyms.

No. Design choices can reduce avoidable risk, but they need verification. Implementation mistakes, changed dependencies, misconfiguration, and incorrect assumptions can still introduce weaknesses. Testing and review help determine whether the intended protections work in the system that was actually built.

Depending on the product, verification may include code review, SAST, DAST, vulnerability assessment, or penetration testing. The mix should reflect the system and its risks; no single test is required for every product, and no clean test result proves that a system has no vulnerabilities.

If it is unclear whether security issues are isolated defects or part of deeper architecture and codebase problems, Mad Devs' Technical Audit can help review the system and prioritize findings. A technical audit is not a certification or a substitute for a scoped penetration test.