Two approaches clash when it comes to security: building it in from the design stage or adding it after the fact. The first requires a greater initial effort but produces naturally robust systems. The second looks faster but generates a security debt that always ends up being paid, often at the worst moment. This page compares the two approaches with concrete examples, relies on the CISA Secure-by-Design principles and on the OWASP Top 10:2025, places each control in the secure development lifecycle (Secure SDLC), and gives a method to move a team over to built-in security.
What you will learn
- Distinguish security by design from security after the fact and spot which one dominates in your organisation.
- Apply the five fundamental principles of secure design (least privilege, defence in depth, fail secure).
- Compare the CISA Secure-by-Design and Secure-by-Default principles, and understand what has changed since their publication.
- Place each control in the secure development lifecycle (Secure SDLC), and argue the cost of a late fix without an unverifiable multiplier.
- Connect these principles to the OWASP Top 10:2025 and its new categories.
- Start a concrete transition towards security by design in an existing team.
What is security by design?
Security by design means building security requirements into the first phases of a project: design, architecture, technology choices. It is not an added layer, it is an intrinsic property of the system. The idea joins that of shift-left (in French): the earlier a problem is dealt with, the cheaper it is to fix.
Five principles structure this approach:
- Attack surface reduction: expose only what is strictly necessary.
- Least privilege: each component has only the rights it needs, no more.
- Defence in depth: several independent layers of protection, so that a single flaw does not compromise everything.
- Secure defaults: the system is secure without any extra configuration by the user.
- Fail secure: in case of error, the system denies access rather than granting it by default.
These principles are not options added later. They shape the architecture from the start, which explains why it is so difficult (and costly) to inject them after the fact into a system already built.
Where does security enter the development lifecycle?
The Secure SDLC (Secure Software Development Life Cycle) is the concrete form of security by design: each step of the cycle carries its own security question and its own control, instead of a single audit at the end of the project. The steps below follow those of the OWASP DevSecOps Guideline process, from design to operation, preceded by the requirements stage. The last column shows where the DevSecOps course teaches each control.
| Step | Security question | Typical control | Where to learn it |
|---|---|---|---|
| Requirements | What must the system guarantee? | Security criteria in the Definition of Done | this lesson |
| Design | What are we protecting, and against whom? | Threat model, architecture review | Threat modeling with STRIDE |
| Code | Is a flaw or a secret getting into the repository? | Pre-commit, SAST, secret detection | Gitleaks, Semgrep |
| Build | Are the dependencies and the image sound? | SCA, image scan, IaC scan | SCA, Checkov |
| Test | Does the running application hold up? | DAST, security tests in CI | DAST |
| Release | What are we delivering, and who built it? | SBOM, signing, provenance | SBOM, Cosign |
| Deployment | What is allowed to run, with which rights? | Gates, short-lived identities, admission policy | Secure pipeline, workload identity |
| Operation | What is happening in production? | Runtime detection, vulnerability management | Container security, CVE management |
Two common mistakes can be read directly in this table. The first is to concentrate everything on the Test row, a scan just before the release: that is the very definition of security after the fact. The second is to skip the Requirements and Design rows, because they produce no tool alert; yet they are the only ones where fixing costs only a decision.
Secure-by-Design vs Secure-by-Default: the CISA principles
In 2023, CISA (Cybersecurity and Infrastructure Security Agency, the US cybersecurity agency) and some twenty international agencies published the guide "Shifting the Balance of Cybersecurity Risk", which distinguishes two complementary concepts.
| Concept | Definition | Responsible party | Example |
|---|---|---|---|
| Secure-by-Design | Security is built into the architecture | Software vendor | Use of memory-safe languages (Rust, Go) |
| Secure-by-Default | Default configurations are secure | Software vendor | MFA enabled by default, admin ports closed |
In May 2024, CISA extended this guide with a pledge (a voluntary commitment), signed by 68 vendors at launch, including Microsoft, Google, Amazon Web Services, Cisco and Fortinet, and by more than 250 by the end of 2024. The pledge rests on seven measurable goals on which the vendor commits to make progress within a year: enable MFA (multi-factor authentication, an identity check that combines a password with a second factor) by default, eliminate default passwords, reduce entire classes of vulnerabilities (for example SQL injection through prepared statements enforced by the framework), make it easier to apply security patches, publish a vulnerability disclosure policy, guarantee the completeness of published CVEs, and provide usable evidence of intrusions (logs).
Signatory vendors publish public progress reports, available on the CISA website: they are a good indicator to assess a supplier's security maturity before choosing it.
What are the 3 CISA Secure-by-Design principles?
Beyond the seven measurable goals of the pledge, CISA sets out three guiding principles aimed at software-producing organisations, not only at the products themselves. They frame the responsibility for and governance of security, where the measurable goals frame the features.
-
Take ownership of customer security outcomes
The software vendor is responsible for the security of its product, not the customer. If users suffer avoidable compromises, it is a product failure, not a user error.
-
Embrace radical transparency
Publish CVEs, document the flaws fixed, share internal security practices. Transparency drives continuous improvement rather than concealment.
-
Build a supportive organisational structure
Security must be driven at executive level. Development teams must have the power (and the time) to prioritise security rather than sacrifice it to deadlines.
Practical difference between by-design and by-default
The following table puts the two notions side by side on concrete cases, to clear up a common confusion: many teams think they have done security by design by simply enabling secure options, whereas they have only done secure-by-default. Both are useful, but only the first changes the architecture itself.
| Situation | By-Design | By-Default |
|---|---|---|
| SQL injection | Impossible because the architecture uses only prepared statements | Not applicable at configuration level |
| MFA | Not applicable at architecture level | Enabled at account creation, no option to disable it easily |
| Admin access | Architecture with no shared admin account (federated IAM) | Admin console disabled by default, requires explicit configuration |
| Secrets | Architecture where secrets are never in the code (runtime injection) | Environment variables not logged by default |
| Logs | Security events traced by design (structured schema) | INFO log level by default, not DEBUG |
What is security after the fact?
Security after the fact is the default approach in most organisations: you first develop a working system, then add security measures to it afterwards. This approach looks faster at the start, but it generates a security debt that gets paid sooner or later, often with interest.
Common manifestations:
- Adding a web application firewall (WAF) in front of a vulnerable application.
- Encryption added after the data is already flowing in clear text.
- Security audit carried out just before going to production.
- Patches applied after a flaw is discovered in production.
- Hardening of a server already in production, without revisiting the architecture.
This approach treats the symptoms rather than the causes. It creates layers of protection that compensate for structural weaknesses without ever eliminating them, which explains why threats and vulnerabilities regularly come back on the same systems.
Comparison of the two approaches
The table below sums up the structural differences between the two approaches. It helps to make objective a choice often settled by urgency rather than by analysis: security after the fact almost always wins in the short term, security by design almost always wins in the medium term.
| Aspect | Security by design | Security after the fact |
|---|---|---|
| When it happens | Design, architecture | Late development, production |
| Cost of fixing | Low (design decision) | High (refactoring, patches) |
| Effectiveness | Treats the causes | Treats the symptoms |
| Coverage | Systemic | One-off |
| Maintainability | Consistent architecture | Stacked layers |
| Technical debt | Minimal | Accumulation |
The cost of fixing depending on the moment
The later a flaw is discovered in the lifecycle, the more it costs to fix, and every step passed adds actions to the fix. The figure-based multipliers that circulate (x5, x30, x100), on the other hand, have no verifiable source, as the lesson Shift-left shows: you therefore reason about what each step adds, not about a coefficient.
| Phase | What the fix involves |
|---|---|
| Design | Change a diagram or an architecture decision |
| Development | Rewrite a module, rerun the tests |
| Testing | Fix, then rerun the regression tests |
| Production | Emergency fix, redeployment, exposure window |
| After an incident | Investigation, communication, regulatory obligations, loss of trust |
An architecture decision taken in 5 minutes can require weeks of refactoring if it has to be fixed in production, not counting the cost of the incident itself if it has already happened.
OWASP Top 10:2025: secure design enters the ranking
The OWASP Top 10 lists the ten most critical application risks, drawn up from the analysis of tens of thousands of CVEs and surveys of thousands of organisations. The 2025 edition, announced in November 2025 and finalised in January 2026, confirms the underlying trend described on this page.
Two new categories join the ranking: Software Supply Chain Failures (which goes beyond the mere management of vulnerable components to cover build, dependency and registry compromises) and Mishandling of Exceptional Conditions (that is, errors and badly handled edge cases that produce unpredictable behaviour).
These two additions confirm that the most costly flaws today are no longer just isolated code bugs, but architecture and process defects: a build chain with no verified integrity, error handling that exposes sensitive information. These are exactly the categories that security by design treats at the root, where security after the fact can only mask them with one more scanner. The guide OWASP Top 10 applied to DevSecOps details each category; the topic of the software supply chain is developed in Software supply chain security.
Concrete examples
To illustrate the difference between the two approaches, let us look at three areas where the choice of by design vs after the fact has a major impact on maintainability and the real cost.
Authentication
By design: the architecture provides from the start for a centralised authentication service. All applications use it. Tokens are signed, sessions managed uniformly. Adding MFA affects a single component.
After the fact: each application manages its own authentication. Some store passwords in MD5, others in bcrypt, others in clear text. Adding MFA requires changing every application. Some cannot be changed (legacy). An authentication proxy is added in front, creating an inconsistent architecture and an extra point of failure.
Secrets management
By design: secrets (API keys, passwords) are never in the source code. The architecture provides for a secrets manager from the start. Applications know where to fetch their credentials at startup.
After the fact: secrets are in the code, the configuration files, the environment variables, sometimes in clear text in the logs. A secrets manager is added, but migrating the existing applications takes months. Meanwhile, the old secrets remain exposed.
Logging
By design: a structured log format is defined from the start. Each security-relevant event is traced with the necessary information (who, what, when, from where). Logs are centralised and indexable.
After the fact: each component logs in its own format. Some in text, others in JSON, others not at all. After an incident, you discover that critical information is missing. Logs are added, but the history is lost.
Scenario 1: the legacy application
A company runs a business application developed ten years ago. At the time, security was not a priority. The application:
- Uses SQL queries built by concatenation (SQL injection).
- Stores passwords in unsalted MD5.
- Exposes an API without authentication on the internal network.
- Runs with a system administrator account.
The security team asks for remediation. Two options compete, with very different costs and results.
Option A, fix after the fact:
- Add a WAF in front of the application (cost: 2 weeks).
- Force password renewal (cost: 1 week).
- Add authentication at reverse proxy level (cost: 1 week).
- Create a dedicated service account (cost: 3 days).
- Total: about 1 month, structural flaws still present.
Option B, redesign by design:
- Rewrite the queries with prepared statements.
- Migrate to bcrypt with progressive password rotation.
- Implement native authentication.
- Apply the principle of least privilege to the service account.
- Total: about 3 months, but problems solved at the root.
Option A is chosen for reasons of time. Two years later, an SQL injection is exploited despite the WAF, by bypassing it. The cost of the incident far exceeds that of the redesign that had been ruled out.
Scenario 2: the greenfield project
A team starts a new project ("greenfield", that is, without the constraint of an existing system to evolve). From the kickoff, a security architect takes part in the design discussions.
Decisions taken during the design phase:
- Authentication: use of an existing OIDC provider (OpenID Connect, a standard protocol that delegates authentication to an already proven third-party service), no password management in the application.
- Authorisation: RBAC model (Role-Based Access Control, access control based on roles rather than individual permissions) defined in a dedicated service, no access logic scattered through the code.
- Secrets: native integration with the company's secrets manager.
- Logs: structured JSON format, security events defined in a shared schema.
- Sensitive data: encryption at rest and in transit, PII columns (Personally Identifiable Information, the data that identifies a person) identified in the data model from the design stage.
Result after 18 months:
- Zero critical flaws discovered during audits.
- Regulatory compliance achieved with no extra effort.
- Incident response time reduced thanks to usable logs.
- Security maintenance cost built into normal development, with no separate budget line.
How to move to security by design
Involve security from the start
Security is not a final validation. It takes part in:
- Architecture reviews: identify structural risks before they are coded.
- Technology choices: assess the security posture of components (memory-safe language, framework with prepared statements by default).
- Story definitions: include security criteria in the definition of "done" ("Definition of Done").
Define standards
Rather than reinventing everything on each project, an organisation benefits from documenting:
- Approved authentication patterns.
- Standardised secrets management methods.
- A logging format common to all services.
- A secure design checklist used in architecture reviews.
Automate the checks
Bringing the controls into the pipeline turns security into a continuous safeguard rather than a one-off audit:
- Static analysis of the code (SAST, Static Application Security Testing, which spots flaws by reading the code without running it).
- Scanning of vulnerable dependencies.
- Configuration checks (IaC, Infrastructure as Code, infrastructure described in versioned files rather than configured by hand).
- Automated security tests in continuous integration.
These controls detect regressions before they reach production, which ties in directly with the logic of the secure CI/CD pipeline.
Key points
-
Security by design builds protection in from the design stage: it treats the causes rather than the symptoms and produces naturally robust systems.
-
Secure-by-Design and Secure-by-Default are complementary: one shapes the architecture, the other the default configurations.
-
The CISA pledge rests on seven measurable goals (MFA by default, removal of default passwords, reduction of vulnerability classes, patches, disclosure, CVEs, intrusion logs), tracked through public progress reports.
-
The cost of fixing rises with every step passed: a design decision is fixed by changing a diagram, the same flaw in production requires an emergency fix and a redeployment. The figure-based multipliers that circulate are not sourced.
-
The OWASP Top 10:2025 confirms the trend: two new categories, Software Supply Chain Failures and Mishandling of Exceptional Conditions, are architecture defects, not mere bugs.
-
Legacy systems accumulate security debt: each added patch makes the architecture more complex without eliminating the fundamental risks.
-
Moving to security by design requires a cultural change: involve security from the start, define standards, automate the checks in the pipeline.
Knowledge check
Check that you have the essentials of this guide. The questions cover only what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Shift-left: detecting problems as early as possible
A new full quiz with random questions
Work again only on the questions you missed
Resources
These official references let you check every claim on this page at the source, and follow how they evolve: the CISA pledge publishes its progress reports, OWASP revises its ranking every three to four years.
- CISA Secure by Design, Official guide with the 3 principles and the pledge
- Secure by Design Pledge, progress reports, Public tracking of the commitments of signatory vendors
- OWASP Top 10:2025, Edition finalised in January 2026, with its two new categories
- OWASP DevSecOps Guideline, The process steps (Design to Operate) used in the Secure SDLC table
- CWE Top 25, The 25 most dangerous software weaknesses
FAQ: frequently asked questions
These short answers cover the questions asked most often about security by design: CISA principles, the cost of a late fix, moving a team over. Each one can be read on its own.