Security Principles

Security architecture principles, such as "zero trust", “security by design”, “defence in depth”, “security by default”, “default deny”, “fail securely”, “distrust input from external applications”, “security in deployment”, “assume breach”, „least privilege“, “usability and manageability” and “least functionality”, are becoming a requirement in secure software development and in secure ICT environment development and maintenance. These differ in application, some overlap, other compliment and can even work against each other.

The clean way to think about these principles is that they are not alternatives in a single category. They operate at different layers:

some are trust and access assumptions: zero trust, assume breach, least privilege, default deny
some are engineering design principles: security by design, fail securely, distrust input from external applications, least functionality
some are architectural resilience patterns: defence in depth
some are operational or lifecycle principles: security in deployment, security by default
one is a human and operational effectiveness principle: usability and manageability

That is why they sometimes overlap, often reinforce each other, and occasionally create tension.

1. Overview of each principle

Security by design

Meaning	Security is built into requirements, architecture, implementation, testing, and operations from the start, rather than added later.
Select it when	Always. This is the umbrella principle for secure software and ICT environments.
Best contribution	Prevents structural weaknesses early, when they are cheapest to fix.
Complements	Everything else, especially security by default, least privilege, fail securely, distrust input, and security in deployment.
Can conflict with	Usually not in principle, but in practice it can be diluted by strong usability or delivery-speed pressures.
Best fit with others	Use it as the governing method, then choose concrete subordinate principles according to system risk.

Zero trust

Meaning	Never assume trust based on network location, device location, or prior access. Every request, identity, device, and session must be verified continuously and contextually.
Select it when	Distributed systems, cloud environments, remote work, partner integration, APIs, east-west traffic in data centres, high-value assets, regulated environments.
Best contribution	Reduces implicit trust and lateral movement.
Complements	Assume breach, least privilege, default deny, defence in depth, distrust input from external applications.
Can conflict with	Usability and manageability if over-applied with too many prompts, checks, or policy fragments. Can also create operational complexity if tooling maturity is low.
Best fit with others	Use least privilege for access scope, default deny for policy baseline, assume breach for monitoring/segmentation rationale, and usability/manageability to keep the control set operable.

Defence in depth

Meaning	Multiple independent or semi-independent layers of preventive, detective, and corrective controls.
Select it when	Always for important systems, especially where impact of failure is significant.
Best contribution	Prevents single-point security failure.
Complements	Zero trust, assume breach, fail securely, security in deployment, least functionality, security by default.
Can conflict with	Usability/manageability if too many layers create friction or alert fatigue. Can undermine clarity if controls duplicate each other without purpose.
Best fit with others	Assign each layer a distinct role: hardening, access control, input validation, monitoring, segmentation, backup/recovery.

Security by default

Meaning	Out-of-the-box or initial state is secure without requiring extra hardening.
Select it when	Always, especially for products used by many customers, platforms, shared services, and administrative tooling.
Best contribution	Reduces misconfiguration risk and dependency on expert operators.
Complements	Default deny, least functionality, least privilege, fail securely, security in deployment.
Can conflict with	Usability if defaults are too restrictive or hard to work with. Business adoption can suffer if secure defaults block legitimate setup without clear guidance.
Best fit with others	Pair with usability/manageability so secure defaults are understandable, discoverable, and overridable only through controlled mechanisms.

Default deny

Meaning	Deny actions, access, traffic, or execution unless explicitly allowed.
Select it when	Access control, firewalling, API authorization, privileged actions, workload communication, application allow-listing.
Best contribution	Shrinks exposure by making permission explicit.
Complements	Zero trust, least privilege, security by default, assume breach.
Can conflict with	Usability/manageability and business agility if policy design is immature. It can also create outages if the allow rules are incomplete.
Best fit with others	Use with fail securely so errors stay closed, and with good observability and staged rollout to avoid availability damage.

Fail securely

Meaning	When errors occur, the system should default to a safe state rather than an unsafe one.
Select it when	Always, especially in authentication, authorization, cryptography, transaction handling, secrets access, and safety-critical or regulated systems.
Best contribution	Prevents exception paths from becoming attack paths.
Complements	Default deny, security by default, distrust input, defence in depth.
Can conflict with	Availability and usability in some cases. “Secure failure” may mean denial of service to legitimate users when dependencies fail.
Best fit with others	Balance with resilience design. Fail closed on trust decisions but use graceful degradation for non-sensitive features.

Distrust input from external applications

Meaning	Treat all input from outside the trust boundary as untrusted until validated, normalized, sanitized, and authorized.
Select it when	Always for APIs, file uploads, web forms, partner integrations, message queues, client-side data, machine-to-machine integrations.
Best contribution	Reduces injection, deserialization, parsing, and business logic abuse.
Complements	Security by design, fail securely, zero trust, assume breach, defence in depth.
Can conflict with	Mostly operationally, where heavy validation can add latency, interoperability friction, or development effort.
Best fit with others	Apply explicit trust boundaries, schema validation, content-type enforcement, parameterized interfaces, and authorization checks after validation.

Security in deployment

Meaning	Security depends not just on code, but on environment configuration, infrastructure, secrets handling, runtime controls, patching, logging, monitoring, and hardening.
Select it when	Always. Especially cloud, containerized, hybrid, and infrastructure-as-code environments.
Best contribution	Closes the gap between secure code and insecure runtime.
Complements	Security by design, security by default, defence in depth, assume breach, least functionality.
Can conflict with	Usability/manageability if deployment controls are too fragmented or manual.
Best fit with others	Use hardened baselines, immutable infrastructure where practical, secure CI/CD, secrets management, segmented networks, centralized logging, and deployment policy checks.

Assume breach

Meaning	Design and operate as though an attacker will eventually gain some foothold.
Select it when	Always for modern enterprise environments. Essential for high-value and internet-exposed systems.
Best contribution	Shifts focus from pure prevention to detection, containment, recovery, and resilience.
Complements	Zero trust, defence in depth, least privilege, security in deployment, fail securely.
Can conflict with	Rarely conflicts conceptually but can produce cost and operational overhead if every control path is optimized for adversarial persistence.
Best fit with others	Use it to justify segmentation, telemetry, endpoint controls, privileged access restrictions, recovery playbooks, and blast-radius reduction.

Least privilege

Meaning	Users, processes, services, and devices get only the minimum permissions needed for the minimum time required.
Select it when	Always. Especially IAM, service accounts, admin rights, APIs, databases, and cloud roles.
Best contribution	Limits damage from compromise, error, and insider misuse.
Complements	Zero trust, default deny, assume breach, security by default.
Can conflict with	Usability/manageability if privileges are too granular, constantly expiring, or hard to request.
Best fit with others	Use role design, just-in-time elevation, separation of duties where needed, and continuous permission review.

Usability and manageability

Meaning	Security must be understandable, operable, supportable, and sustainable for users, admins, developers, and operators.
Select it when	Always, but especially in broad user populations, high-change environments, and platforms with many administrators or customers.
Best contribution	Prevents security controls from being bypassed, misconfigured, or ignored.
Complements	Security by default, security by design, zero trust, least privilege.
Can conflict with	Almost every restrictive principle if taken to extremes. This is the main balancing principle.
Best fit with others	Use it as a design constraint: secure paths should be the easiest paths, administration should be centralized, policies should be explainable, and exceptions should be controlled.

Least functionality

Meaning	Enable only necessary features, services, ports, protocols, libraries, interfaces, and administrative surfaces.
Select it when	Always, especially for servers, appliances, embedded systems, containers, and high-assurance systems.
Best contribution	Reduces attack surface and maintenance burden.
Complements	Security by default, security in deployment, defence in depth, assume breach.
Can conflict with	Usability/manageability and flexibility if teams need dormant functionality for troubleshooting or future use.
Best fit with others	Use modular deployment, feature flags, controlled admin tooling, and approved extension patterns instead of broadly enabling everything.

2. Which principles are strongest together

These pairs or groups usually reinforce each other very well.

Zero trust + least privilege + default deny

This is a very coherent access-control model.

Zero trust says do not trust by location or prior state
least privilege says grant minimal access
default deny says everything else is blocked

This combination is especially effective for identity, service-to-service communication, API access, and privileged administration.

Security by design + security by default + fail securely

This is a strong engineering baseline.

build secure architecture intentionally
ship secure settings by default
make error paths safe

This is the best trio for product teams and platform teams.

Assume breach + defence in depth + security in deployment

This is a strong resilience and operations model.

assume one control will fail
put multiple layers in place
make runtime environment hardened, observable, and controllable

This works well for enterprise infrastructure, cloud, SOC-driven environments, and regulated operations.

Distrust external input + fail securely + security by design

This is particularly effective for application security.

all external inputs are untrusted
parsing and validation errors do not open insecure states
design trust boundaries and validation patterns early

This reduces common application attack classes.

Security by default + least functionality

This is ideal for attack-surface reduction.

the system starts locked down
only required features are enabled

Very effective for servers, containers, endpoints, and embedded or operational technology components.

3. Which principles are harder to use together

Not impossible, but they need careful balancing.

Zero trust vs usability and manageability

Common friction:

frequent authentication prompts
overly granular policy administration
inconsistent access decisions across tools
support burden

How to make them fit:

use risk-based and context-aware access, not blanket prompts
centralize policy management
favor strong device and session assurance over constant user interruption
make access requests and approvals auditable but streamlined

Default deny vs availability and operations

Common friction:

blocked legitimate traffic or workflows
outages during rollout
emergency changes under pressure

How to make them fit:

stage policies in monitor mode first where possible
build precise allow-lists from observed legitimate behavior
maintain break-glass access with strong controls
log denials clearly

Fail securely vs resilience/usability

Common friction:

dependency failures can lock out legitimate users
“fail closed” may halt business operations

How to make them fit:

fail closed for authorization, secrets, and integrity checks
degrade gracefully for non-sensitive convenience features
classify functions by criticality and security sensitivity

Least privilege vs manageability

Common friction:

role explosion
constant entitlement requests
brittle service interactions

How to make them fit:

use role-based or attribute-based grouping
add just-in-time elevation for rare admin tasks
review and prune privileges periodically rather than over-customizing everything

Least functionality vs operational flexibility

Common friction:

troubleshooting becomes harder
future integrations require change effort
admins may want dormant services available “just in case”

How to make them fit:

keep disabled components installable but not enabled
use controlled temporary enablement
maintain documented hardened profiles per environment

4. Practical selection guidance: when to emphasize which principle

If the main concern is unauthorized access

Prioritize:

zero trust
least privilege
default deny
assume breach

If the main concern is insecure application behavior

Prioritize:

security by design
distrust input from external applications
fail securely
security by default

If the main concern is lateral movement or compromise containment

Prioritize:

assume breach
zero trust
defence in depth
least privilege

If the main concern is misconfiguration and operational drift

Prioritize:

security by default
security in deployment
least functionality
defence in depth

If the main concern is broad deployability and sustainable operations

Prioritize:

usability and manageability
security by default
security by design

This does not mean weakening security. It means designing security so it can actually be operated correctly.

5. Best ways to combine more than one

The most effective approach is to combine them by layer, not as a flat checklist.

Layer 1: Foundational mindset

Use:

security by design
assume breach

These establish how the system is conceived.

Layer 2: Access and trust model

Use:

zero trust
least privilege
default deny

These define who and what can do anything.

Layer 3: Secure behaviour of the software

Use:

fail securely
distrust input from external applications
least functionality
security by default

These define how the system behaves under normal and abnormal conditions.

Layer 4: Runtime and environment

Use:

security in deployment
defence in depth

These define how the system survives in production.

Layer 5: Human factors

Use:

usability and manageability

This ensures the whole model remains workable.

6. A recommended combined model

For most modern software systems and ICT environments, the best composite model is:

Security by design as the umbrella principle
Assume breach as the threat posture
Zero trust + least privilege + default deny for trust and access
Distrust external input + fail securely for application behavior
Least functionality + security by default for attack-surface reduction
Security in deployment + defence in depth for runtime resilience
Usability and manageability as the balancing constraint across all of the above

That combination is coherent because each principle has a different job.

More later.

This text was created with the help of ChatGPT, Claude and Gemini that were used for researching the topic and comparing with my own study, experience and expert knowledge. I then finally combined the information into this document/page.