When embracing the Security by design approach you must embrace at least the following principles:
Remove unnecessary features, endpoints, and entry points.
Default configurations should be secure out of the box (e.g., deny by default).
Every component and user should have only the minimum privileges necessary to function. (Keep once, not twice.)
No single person or process should have excessive authority; split critical functions across multiple actors.
Layer multiple, independent security controls so that failure of one does not lead to system compromise.
When a system fails, it should default to a closed (deny) state, not an open (allow) state.
Every access request must be checked against authorisation rules, without relying on cached decisions.
Keep security-critical designs as simple and small as possible.
This principle is also known as:
Simplicity is better than complexity.
Security mechanisms should be as simple and small as possible. Complex systems have more vulnerabilities, are harder to verify, and increase the attack surface.
A complicated solution often fails because:
It’s harder to review. No one can fully understand all the interactions.
It’s harder to configure correctly. Admins will make mistakes.
It’s harder to maintain. Fixing one bug often creates two more.
It often relies on “security by obscurity.” The complexity feels secure because it’s hard to understand, but that’s an illusion.
Security must not depend on secrecy of the design or implementation (security by obscurity is explicitly avoided).
This means the architecture, design and software used should be fully transparent. Assume that bad actors have access to the software and crucial documentation.
Never implicitly trust internal or external services; verify everything.
Isolate components so that a breach in one area does not compromise the whole system.
Data must be protected at rest (storage), in transit (network) and when ‘in-use’ , so when processed at CPU level or touched by applications. So critical data should be even protected when applications perform actions on it. So data should always be encrypted.
Systems must be able to receive and apply security patches safely and reliably.
If you think a principle is not applicable for your situation: Think again. Or better write down your motivation and ask for an expert review on your motivation.
Cheat sheet¶
| Principle | Summary | Key Rule |
|---|---|---|
| Minimise attack surface area | Remove unnecessary features, endpoints, entry points. | Less code → fewer holes. |
| Establish secure defaults | Default configs must be secure out-of-the-box. | Deny by default. |
| Least privilege | Every component/user gets minimum privileges to function. | Keep once, not twice. |
| Separation of duties | No single actor has excessive authority. | Split critical functions across multiple actors. |
| Defence in depth | Layer independent security controls. | One failure ≠ system compromise. |
| Fail securely | On failure, default to closed (deny) state. | Never fail open. |
| Complete mediation | Every access request must be checked. | No cached decisions. |
| Economy of mechanism | Keep security-critical designs simple and small. | complexity = NOT secure. |
| Open design | No security by obscurity. | Assume attackers have your docs/code. |
| Zero Trust | Never implicitly trust internal/external services. | Verify everything. |
| Compartmentalisation | Isolate components. | Breach in one ≠ breach of all. |
| Protect data everywhere | Encrypt data at rest, in transit, and in-use. | Even during processing. |
| Design for secure updates | Systems must safely apply patches. | Update ability is a security feature. |
Learn more¶
These Security by Design principles represent distilled wisdom and long-standing experience from the field. You must always apply them when shaping an architecture or making design decisions.