Adding security to a system once it has been designed and built can be difficult, expensive and ineffective. If the design of the system never included security, it might not even be possible to add security afterwards.

You might think that this is something that used to happen, but no longer does – you’d be wrong.

Applications are developed, networks are configured, users are given access, systems go into production.

And then someone asks “How are we going to secure this?”

The principle of Secure by Design takes a different approach:

Security should be considered and incorporated into a system from the beginning of its design and development, rather than being added as an afterthought.

The objective is to make security part of the architecture rather than something bolted on afterwards.

What is Secure by Design?

Secure by Design means deliberately incorporating security requirements into the design, architecture, development and operation of a system. Here, security is considered before the system is built.

This means asking questions such as:

• What could go wrong?
• What could an attacker try to do?
• What information needs protecting?
• Who should have access?
• What should happen if something fails?
• What happens if an account is compromised?
• What should the system do by default?
• How will security events be detected?
• How will the system recover from an attack?

Security therefore becomes a design requirement, rather than simply a feature.

Security as a requirement

Traditionally, organisations sometimes think about software requirements in terms of functionality.

For example:

“Users need to be able to upload documents.”

“Customers need to reset their passwords.”

“Managers need to approve transactions.”

These describe what the system needs to do – the term used here is functional requirements.

Secure by Design adds another set of requirements:

“Users must only be able to access their own documents.”

“Password-reset requests must be authenticated securely.”

“Managers must not be able to approve their own transactions.”

These describe how the functionality needs to operate securely.

A secure system therefore considers two questions:

• What should the system do?
• How should it do it securely?

Why is Secure by Design important?

Security problems discovered late in development can be very expensive to fix.

Imagine a development team builds an application where every user has access to every database record.

Six months later, security testing identifies the problem and insists the issue is rectified.

Fixing it may require changes to:

• The database
• The application
• The user interface
• The authorization model
• APIs
• Testing
• Documentation

If the requirement for access control had been included during the initial design, the system could have been built correctly from the start.

This leads to a common principle in secure development:

The earlier a security problem is identified, the easier and cheaper it is generally to fix.

Security shouldn’t be an afterthought

Security should be considered throughout the entire design and development lifecycle.

By considering the security aspects of the system being designed, it becomes much easier to identify security problems before they become expensive or dangerous.

Secure by Design isn’t just about software

Although the term is often associated with software development, the principle applies much more broadly.

It can be applied to:

• Networks
• Cloud infrastructure
• Applications
• Databases
• Operating systems
• Hardware
• APIs
• Identity systems
• Physical security
• Business processes
• Industrial systems
• IoT devices

Whenever something is being designed, security should be considered as part of that design.

Secure by Design and threat modelling

One of the most useful techniques for Secure by Design is threat modelling.

Threat modelling involves thinking about potential threats before the system is built.

For example, imagine designing an online banking application.

The design team might ask:

• Who might attack the system?
• What are they trying to obtain?
• What could they manipulate?
• What happens if an account is compromised?
• What happens if an API is abused?
• What happens if an administrator account is compromised?

The team can then design controls to address those threats.

Security therefore becomes part of the architecture rather than something discovered after deployment.

Secure defaults

One of the most important Secure by Design principles is that of secure by default.

Secure by default instils the principle that a system should initially operate in the safest reasonable configuration.

The user or administrator should not have to discover dozens of security settings before the system becomes safe enough to operate.

Instead, the secure option should be the default option whenever practical.

Secure by Default vs Secure by Design

These two concepts are related.

• Secure by Design means security is incorporated into the architecture and development process.
• Secure by Default means the resulting system starts in a secure configuration.

For example:

A system could be designed to support strong authentication – That’s Secure by Design.

If strong authentication is enabled automatically rather than requiring an administrator to find and enable it manually – that’s Secure by Default.

A secure system should ideally have both.

Least Privilege by design

The principle of least privilege should also be considered during system design.

Instead of building an application where every component has unrestricted access, the architecture should define exactly what each component requires.

The application has the permissions required to perform its function – Nothing more.

This means that if the application is compromised, the attacker doesn’t automatically inherit unnecessary privileges.

Least privilege is therefore not something that should simply be configured after deployment – It should be designed into the system.

Defence in Depth by design

Secure by Design also means considering what happens when individual security controls fail.

Rather than relying on a single control, a secure architecture might incorporate multiple layers.

The architecture is designed on the assumption that no individual security control is perfect.

This is Secure by Design working together with defence in depth.

Fail Secure by design

The same principle applies to system failures.

A designer should ask “What happens if this security control stops working?”

For example, what happens if the authentication server becomes unavailable?, or if the authorization service fails?

A secure design should deliberately choose an appropriate failure state.

This is the principle of Fail Secure being incorporated into the architecture from the beginning.

Authentication and authorization by design

Authentication and authorization should also be designed into applications from the start.

A common mistake is to consider adding authentication at some later date.

This can result in applications that weren’t designed around identity and access control and can’t be easily retro-fitted with them.

A better approach is to define from the beginning:

• Who are the users?
• How are they authenticated?
• What resources can they access?
• What actions can they perform?
• How are permissions assigned?
• How are privileged actions controlled?
• How are sessions managed?
• How are access decisions logged?

Security becomes part of the application’s fundamental architecture.

Secure APIs by design

Modern applications frequently communicate through APIs. A badly designed web API designed without security in mind might expose:

GET /customers
GET /accounts
GET /payments
DELETE /customers
POST /admin/users

If authentication and authorization are added later, the development team may discover that the API exposes far more functionality than intended.

A Secure by Design approach considers:

• Authentication
• Authorization
• Input validation
• Rate limiting
• Data validation
• Error handling
• Logging
• Encryption
• API versioning
• Abuse prevention

before the API is deployed.

Data protection by design

Sensitive information should also be considered during the architecture stage.

For example – the question “What data do we actually need to collect?” is a very important one.

If an application doesn’t need someone’s date of birth, perhaps it shouldn’t collect it. If it doesn’t need their full payment information, perhaps it shouldn’t store it.

This reduces the amount of sensitive information that needs to be protected.

A useful principle to remember is – You can’t lose data you never collected.

Data minimisation therefore becomes part of Secure by Design.

Encryption by design

Encryption is another example of secure by design. Rather than storing sensitive information in plain text and deciding later that encryption would be useful, the system should determine from the beginning:

• What data needs encryption?
• Where should encryption be applied?
• What encryption algorithms are appropriate to use?
• How are keys managed?
• Who can decrypt the data?
• What happens if keys are lost?
• How are keys rotated?

Encryption should therefore be considered part of the architecture.

Privacy by design

Secure by Design is closely related to Privacy by Design.

Security asks:

How do we protect information and systems?

Privacy asks:

How should personal information be collected, used and protected?

For example, a system might be designed so that:

• It collects only necessary personal information
• Access is restricted
• Data is encrypted
• Information isn’t retained indefinitely
• Users can exercise appropriate rights
• Data isn’t unnecessarily shared

Privacy and security therefore overlap significantly.

See the section on Privacy by design for more information.

Secure software development lifecycle

Secure by Design is most effective when security is incorporated throughout the Software Development Life Cycle (SDLC).

A simplified lifecycle might look like:

Requirement scoping
     ↓
Threat modelling
     ↓
Secure architecture
     ↓
Development
     ↓
Code review
     ↓
Security testing
     ↓
Deployment
     ↓
Monitoring
     ↓
Maintenance

Security isn’t a single phase.

It is a continuous activity throughout the entire lifecycle.

Security requirements

Security requirements should be written alongside functional requirements.

For example, a functional requirement might be:

Users must be able to reset their passwords.

The security requirements might be:

Password reset requests must require appropriate verification.

Reset tokens must expire.

Reset tokens must not be reusable.

Passwords must not be sent in plain text.

The functional requirement describes what the system does, whereas the security requirements describe how it must do it securely.

Secure coding

Software developers need to consider security while writing code.

This includes avoiding common vulnerabilities such as:

• SQL injection
• Cross-site scripting
• Command injection
• Path traversal
• Insecure deserialization
• Broken access control
• Improper authentication
• Sensitive information exposure

Secure coding practices can include:

• Input validation
• Output encoding
• Parameterised queries
• Safe API usage
• Secure error handling
• Dependency management
• Strong authentication
• Proper authorization

The goal is to prevent vulnerabilities from being introduced in the first place.

Code reviews

Code reviews provide another opportunity to identify security problems.

A second developer can review a change to a system and ask “Does this introduce a security problem?”

For sensitive applications, organisations may also use specialist security reviewers.

Automated tools can help identify potential problems, but human review remains important.

The principle is Find security problems before the software reaches production.

Security testing

Secure by Design doesn’t mean assuming the system is secure. The design needs to be tested.

Testing can include:

• Vulnerability scanning
• Static Application Security Testing
• Dynamic Application Security Testing
• Penetration testing
• Dependency scanning
• Configuration testing
• Authentication testing
• Authorization testing
• Fuzz testing

The exact combination depends on the system and its risk.

Testing should attempt to determine whether the security controls designed into the system actually work.

Security and usability

There is an important relationship between security and usability – A security control that is extremely difficult to use may encourage users to bypass it.

For example:

An authentication system requiring an unnecessarily complicated process every few minutes may encourage users to find workarounds.

Secure by Design therefore means considering:

How can we make the secure behaviour the easiest behaviour?

Security should ideally work with users rather than constantly fighting against them.

Security shouldn’t depend on perfect users

A secure system should not assume that every user will always make the correct decision. Peopl make mistakes.

People will:

• Click links
• Lose devices
• Choose poor passwords
• Make mistakes
• Misconfigure systems
• Forget procedures

Secure by Design attempts to make these mistakes less damaging.

For example:

• If a user clicks a malicious link, endpoint protection should provide another layer.
• If a user’s password is stolen, MFA should provide another barrier.
• If a user accidentally accesses a sensitive system, authorization should prevent unauthorised actions.
• If a user deletes something important, backups should provide recovery.

The architecture should assume that people will eventually make mistakes.

Secure by Design and attack surface

Secure by Design also supports the principle of minimising the attack surface.

During design, the organisation can ask:

• Does this feature actually need to exist?
• Does this service need to be exposed?
• Does this API need to be public?
• Does the application need administrator privileges?
• Does this data need to be collected?

Removing unnecessary functionality before the system is built is often easier than removing it later.

Security therefore begins with what you choose not to build.

Secure by Design and Zero Trust

Zero Trust principles can also be incorporated during the architecture of the system.

Instead of designing systems around “Everything inside the network is trusted.”, the system can be designed around “Access must be explicitly authenticated and authorized.”

Security boundaries are designed into the architecture rather than added later.

Secure by Design and resilience

Security isn’t just about preventing attacks. A secure system also needs to withstand failures and recover from incidents.

Design considerations can include:

• Redundancy
• Backups
• Disaster recovery
• Fail-secure behaviour
• Monitoring
• Incident response
• Recovery procedures

This creates a cycle in which security improves over time.

Security is everyone’s responsibility

Secure by Design isn’t solely the responsibility of the security team.

It involves:

• Developers
• Architects
• Network engineers
• System administrators
• Product managers
• Project managers
• Senior management
• Security professionals
• Operations teams

The security team can provide expertise and guidance, but if security is only considered by the security team at the end of a project, many important design decisions will have already been made.

Security needs to be considered throughout the organisation.

This is achieved with the process of DevSecOps – Developers / Security / Operational teams all working together to achieve the same end goal – usable, secure systems.

In summary

Secure by Design is the principle of incorporating security into the architecture, design and development of systems from the beginning rather than treating security as something that can be added later.

It involves considering:

• Threats
• Security requirements
• Authentication
• Authorization
• Least privilege
• Data protection
• Encryption
• Secure defaults
• Attack-surface reduction
• Fail-secure behaviour
• Monitoring
• Resilience
• Recovery

It can be supported through:

• Threat modelling
• Secure architecture
• Secure coding
• Code review
• Security testing
• Secure configuration
• Data minimisation
• Strong identity management
• Secure development lifecycles

The key idea is:

Security should be an architectural property, not an optional feature.

If security is considered from the beginning, it can influence what gets built, how it is built and how it operates.

If security is considered only after deployment, the organisation may be trying to compensate for weaknesses that are already embedded in the design.

The best time to fix a security problem is before it becomes a vulnerability.

Don’t build it first and secure it later. Build security into it from the start.