Contents
- 1 Secure by Design
- 1.1 Why Secure by Design Matters
- 1.2 Secure by Design Lifecycle
- 1.3 Core Secure by Design Principles
- 1.4 Defence in Depth
- 1.5 Secure by Design in Cloud Platforms
- 1.6 Secure vs Traditional Development
- 1.7 Secure Defaults
- 1.8 Threat Modelling
- 1.9 Secure by Design Across the SDLC
- 1.10 Example: Building a Customer Portal
- 1.11 Common Secure by Design Technologies
- 1.12 Secure by Design Checklist
- 1.13 Frameworks That Support Secure by Design
- 1.14 Key Takeaways
Secure by Design
Secure by Design, often shortened to SbD, means building security into systems, services, cloud platforms and data solutions from the very beginning. It is the opposite of treating security as a late-stage review, bolt-on tool, or compliance checkbox.
Simple definition: Secure by Design means a system is intentionally designed to be secure before it is built, deployed or exposed to users.
Why Secure by Design Matters
Traditional security often focused on finding and fixing weaknesses after a system was already built. That approach is no longer enough. Modern cloud platforms, APIs, containers, SaaS products, identity systems and data platforms change quickly. A weak design decision can expose sensitive data, create excessive privilege, or leave an organisation dependent on detection after the damage has already started.
Good design reduces risk before code is written or infrastructure is deployed.
Users and engineers should not have to remember to turn basic protection on.
Controls should be embedded into pipelines, policies, templates and platforms.
Secure by Design Lifecycle
Secure by Design runs through the full system lifecycle. It starts before development and continues after deployment.
Core Secure by Design Principles
Least Privilege
Users, workloads, services and applications should only receive the permissions they actually require.
Defence in Depth
Use multiple overlapping controls so that one failed control does not lead directly to compromise.
Secure Defaults
Encryption, logging, MFA, secure configuration and safe settings should be enabled by default.
Reduced Attack Surface
Remove unnecessary ports, services, accounts, APIs, internet exposure and unused software.
Assume Breach
Design systems so compromise is contained, detected quickly and recovered from safely.
Continuous Verification
Security should be tested repeatedly through scanning, policy checks, monitoring and assurance.
Defence in Depth
Secure by Design does not rely on a single control. A well-designed system uses several layers, each reducing the chance that an attacker can move from initial access to data compromise.
Secure by Design in Cloud Platforms
Cloud security is not only about buying cloud security tools. It is about designing the platform so secure patterns are easy, repeatable and enforced. Good cloud security engineering uses guardrails, templates, identity controls and policy automation.
| Cloud Area | Secure by Design Controls |
|---|---|
| Identity | MFA, Conditional Access, managed identities, role-based access control and just-in-time privilege. |
| Network | Private endpoints, segmentation, restricted inbound access, bastion access and secure egress. |
| Storage | Encryption, private access, access logging, data classification and immutable backups. |
| Compute | Hardened images, patching, endpoint protection, container scanning and secure configuration. |
| Monitoring | Centralised logs, SIEM integration, alerting, behavioural detection and continuous compliance. |
Secure vs Traditional Development
Secure Defaults
A key part of Secure by Design is making the safe option the default option.
Good Defaults
- MFA enabled
- Encryption enabled
- Logging enabled
- Secrets stored in a vault
- Least privilege roles
- Private access preferred
Poor Defaults
- Default passwords
- Anonymous access
- Public storage buckets
- Over-permissive admin roles
- Disabled audit logging
- Internet exposure by default
Threat Modelling
Threat modelling is one of the most useful Secure by Design activities. It helps teams identify what they are building, what could go wrong, and what controls are needed before the system is live.
Secure by Design Across the SDLC
| Phase | Secure by Design Activities |
|---|---|
| Requirements | Define security, privacy, regulatory and data protection requirements. |
| Design | Threat modelling, architecture review, identity design and data flow review. |
| Development | Secure coding standards, peer review, dependency hygiene and secrets management. |
| Build | SAST, SCA, container scanning, secret scanning and Infrastructure as Code checks. |
| Testing | DAST, penetration testing, abuse-case testing and security acceptance criteria. |
| Deployment | Policy-as-code, secure templates, approval gates and automated configuration validation. |
| Production | Logging, alerting, vulnerability management, incident response and continuous monitoring. |
Example: Building a Customer Portal
Traditional Approach
- Build the application first
- Add security review later
- Discover missing logging
- Find excessive permissions
- Add MFA after deployment
- Fix design issues under pressure
Secure by Design Approach
- Threat model before development
- Define authentication requirements
- Use least-privilege access
- Store secrets in a vault
- Encrypt sensitive data
- Enable monitoring from launch
Common Secure by Design Technologies
| Area | Example Technologies |
|---|---|
| Identity | Microsoft Entra ID, Okta, Auth0, AWS IAM, Google Cloud IAM. |
| Secrets | Azure Key Vault, AWS Secrets Manager, HashiCorp Vault, Google Secret Manager. |
| Infrastructure as Code | Terraform, Bicep, CloudFormation, Pulumi. |
| Security Testing | Semgrep, SonarQube, Trivy, Checkov, Snyk, OWASP ZAP. |
| CI/CD | GitHub Actions, GitLab CI, Azure DevOps, Jenkins. |
| Monitoring | Microsoft Sentinel, Splunk, Elastic, Grafana, cloud-native logging tools. |
Secure by Design Checklist
- Have security requirements been defined?
- Has a threat model been completed?
- Is authentication strong by default?
- Are permissions least privilege?
- Is data encrypted in transit and at rest?
- Are secrets stored securely?
- Is infrastructure deployed as code?
- Are security checks included in CI/CD?
- Is logging enabled by default?
- Are alerts configured?
- Are backups immutable and tested?
- Is compliance continuously monitored?
Frameworks That Support Secure by Design
| Framework or Guidance | How It Helps |
|---|---|
| CISA Secure by Design | Encourages vendors and engineering teams to make technology secure by default and secure from the start. |
| NIST SSDF | Provides secure software development practices across people, process and technology. |
| OWASP ASVS | Defines application security verification requirements. |
| OWASP Top 10 | Highlights common application security risks that Secure by Design should reduce. |
| CIS Controls | Provides prioritised security controls for practical cyber defence. |
| NIST Cybersecurity Framework | Supports governance, risk management, protection, detection, response and recovery. |
Key Takeaways
Secure by Design shifts security from a late-stage review into an engineering discipline. It helps organisations design cloud platforms, systems, services and data platforms that are safer by default, easier to operate, and more resilient against modern threats.
