Security Design Principles
Why Principles Matter
Security controls fail. Patches get missed. Configurations drift. Attackers find new techniques. No specific control remains valid forever.
What does remain valid is the reasoning behind controls. Security design principles are the underlying logic that explains why certain controls work, why certain architectures are more resilient, and why certain decisions made in system design consistently lead to breaches decades later.
In 1975, Jerome Saltzer and Michael Schroeder published "The Protection of Information in Computer Systems" in the Proceedings of the IEEE. The paper introduced eight design principles for secure systems.[1] Those principles have proven more durable than any specific technology from that era. They are still cited, still taught, and still violated in systems being built today.
This chapter covers the classic principles, their modern interpretations, and the newer principles that have emerged from decades of experience building and breaking real systems.
The Saltzer and Schroeder Principles
1. Economy of Mechanism (Keep It Simple)
"Keep the design as simple and small as possible."
Complexity is the enemy of security. Every additional feature, every additional code path, every additional configuration option is a potential hiding place for vulnerabilities. Simple systems are easier to analyze, easier to test, easier to audit, and easier to reason about under adversarial conditions.
In practice:
The Heartbleed vulnerability (CVE-2014-0160) existed in a feature called "heartbeat" added to OpenSSL. The heartbeat feature sent a small message and expected a response of the same size, but the implementation did not verify that the response was actually the size claimed. An attacker could request a 64KB response to a 1-byte heartbeat, leaking 64KB of server memory per request, potentially including private keys, session tokens, and passwords.[2]
The feature was unnecessary for the core cryptographic function. Its complexity introduced a critical vulnerability that affected an estimated 17% of secure web servers at the time of disclosure.
Modern application: Prefer managed services over self-hosted complexity where security is not your core competency. Fewer lines of code means fewer vulnerabilities. Remove features and dependencies that are not actively used. Every library you include is attack surface you are responsible for.
2. Fail-Safe Defaults (Deny by Default)
"Base access decisions on permission rather than exclusion."
Systems should default to the secure state. If an action is not explicitly permitted, it should be denied. If a service fails, it should fail closed, not open.
The inverse, building systems that allow everything except what is explicitly denied, produces security that is permanently one missed rule away from failure. Allowlists are inherently more secure than denylists because new attacks are unknown and therefore not in the denylist.
In practice:
A firewall configured with a default-allow policy requires administrators to enumerate every dangerous connection to block. A firewall configured with a default-deny policy requires administrators to enumerate only the connections that are legitimate. The latter produces a dramatically smaller and more auditable rule set.
The same principle applies to IAM (Identity and Access Management): new principals should receive zero permissions by default. Permissions should be explicitly granted for specific resources and actions, not inherited broadly.
3. Complete Mediation (Check Every Access)
"Every access to every object must be checked for authority."
Access control decisions should not be cached, assumed, or skipped for performance. Every time a subject requests access to an object, the authorization should be verified against current permissions, not permissions that were valid when the session started.
In practice:
Insecure Direct Object Reference (IDOR), one of the most common web application vulnerabilities, is a failure of complete mediation. An application authenticates the user once but then uses a predictable identifier (user ID, order number) without re-verifying that the authenticated user is actually authorized to access that specific object. Change the ID in the URL, access someone else's data.
Every API endpoint must independently verify that the authenticated principal is authorized to perform the requested action on the requested resource.
4. Open Design (Security Through Obscurity Fails)
"The design should not be secret."
A system's security should not depend on the secrecy of its design or implementation. It should remain secure even when the attacker knows exactly how it works, because the attacker's ignorance cannot be relied upon.
This is Kerckhoffs's principle, independently derived: assume the adversary knows your algorithm. Your security comes from the secrecy of the key, not the algorithm.[3]
In practice:
Proprietary encryption algorithms developed by vendors who refuse to publish their design for review have a consistent track record of failure when they are eventually reverse-engineered. The A5/1 cipher used in early GSM mobile communications was kept secret, but was reverse-engineered and found to be significantly weaker than publicly designed alternatives.[4]
Open design enables peer review. The AES algorithm was published and subjected to five years of cryptanalysis by the world's best cryptographers before NIST standardized it. That review process gives users justified confidence in its security.
Open design does not mean exposing your secrets. It means the security mechanism does not depend on the mechanism being unknown. Your database schema being private is fine. Your encryption algorithm requiring secrecy to be secure is not.
5. Separation of Privilege (Two Keys to Unlock)
"Where feasible, a protection mechanism that requires two keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single key."
No single individual or component should have sufficient authority to complete a critical action alone. Requiring multiple independent conditions to be satisfied, or multiple independent parties to authorize an action, prevents a single point of failure or a single compromised account from causing catastrophic harm.
In practice:
Multi-factor authentication is a direct implementation: something you know (password) AND something you have (hardware token) AND/OR something you are (biometric). A compromised password alone is insufficient.
Code deployment pipelines that require both a developer approval and a security scan to pass before deployment can proceed implement separation of privilege. A compromised developer account cannot deploy malicious code unilaterally.
Financial controls requiring dual authorization for transfers above a threshold are the physical security analog. The Verizon DBIR consistently shows that the presence of MFA reduces the effectiveness of credential-based attacks dramatically.[5]
6. Least Privilege (Minimum Necessary Access)
"Every program and every user of the system should operate using the least set of privileges necessary to complete the job."
Principals (users, service accounts, processes) should have exactly the permissions required for their current task and no more. This limits the blast radius of a compromise: an attacker who gains access to a low-privilege account or process inherits only those limited permissions.
In practice:
A web application service account that only needs to read from a specific database table should have SELECT permission on that table only. Not db_owner, not INSERT, not access to other tables. If the application is compromised, the attacker's database access is bounded by what the service account can do.
The principle applies at every layer:
Operating system
Run services as non-root; use dedicated service accounts
Application
Request only OAuth scopes actually needed
Database
Grant table-level and operation-level permissions, not schema-wide
Cloud IAM
Scope policies to specific resources and actions
Network
Allow only required ports and protocols; block everything else
7. Least Common Mechanism (Minimize Shared Resources)
"Minimize the amount of mechanism common to more than one user and depended on by all users."
Mechanisms shared between multiple users or processes are potential covert channels, ways for one user to observe or influence another's behavior through side effects. Shared resources also mean that a compromise of the shared mechanism affects all users who depend on it.
In practice:
Containerization and microservices architectures implement this principle: each service runs in its own isolated environment with its own resources. A vulnerability in one service does not automatically compromise others sharing the same process space.
Multi-tenant cloud environments must carefully implement this principle. Microarchitectural side-channel attacks exploit shared CPU hardware to leak information between processes that should be isolated — a direct violation of this principle at the hardware level. Spectre and Meltdown (2018) opened this class; the line has continued with attacks like Zenbleed and Downfall (2023), each leaking data across boundaries through shared CPU components. The recurring lesson: when a mechanism is shared, isolation is only as strong as the hardware's weakest side channel.[6]
8. Psychological Acceptability (Usable Security)
"It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly."
Security mechanisms that are difficult to use will be circumvented. Users will write passwords on sticky notes, disable security software that slows their machines, share accounts to avoid complicated provisioning processes, or find workarounds for controls they cannot easily comply with.
In practice:
Password managers solve the usability vs. security tension in password management: users no longer need to remember complex, unique passwords for every account. The security outcome (unique, complex passwords everywhere) is achieved through a tool that is easier to use than the insecure alternative (reusing simple passwords).
Phishing-resistant MFA (hardware keys like YubiKey, passkeys) is more secure than TOTP codes and, for technical users, no harder to use. The adoption of passwordless authentication is as much a usability project as a security one.
Security controls that generate too many false positives train users to ignore alerts, which is exactly the condition that allowed the Target breach to go undetected despite automated alerts firing.[7]
Modern Principles
The 1975 list was developed for timesharing systems. Subsequent decades of experience, including networked systems, the internet, cloud computing, and mobile, have produced additional principles that are now as foundational.
Defense in Depth
No single security control is sufficient. Security architecture should layer independent controls such that the failure of any single layer does not result in a complete compromise. An attacker who bypasses the firewall should still face network segmentation. An attacker who gains a foothold on a workstation should face endpoint detection. An attacker who extracts data should find it encrypted.
Each layer independently reduces the probability of successful attack. The key word is independent. Two controls that both stop SQL injection — a web application firewall and parameterized queries — are good practice, but they address the same threat, so they aren't truly defense in depth against a different attack. Real depth comes from layers that address different attack types and fail for different reasons: network segmentation, endpoint detection, application authorization, and data-at-rest encryption each catch an attacker the others miss. Stacking redundant controls against one threat while leaving another threat single-layered is a common illusion of depth.
Zero Trust Architecture
Zero Trust is an architectural philosophy that abandons the assumption of a trusted internal network. The traditional model (trust everything inside the firewall, distrust everything outside) fails catastrophically when a threat actor gains internal access (through phishing, VPN compromise, or insider action), because internal traffic is largely unmonitored and unrestricted.
Zero Trust replaces the network perimeter with identity as the new perimeter. NIST SP 800-207 defines Zero Trust as:[8]
"Never trust, always verify. Assume breach. Verify explicitly."
Trust based on network location (inside = trusted)
Trust based on verified identity + device health + context
Wide lateral movement possible once inside
Micro-segmentation limits blast radius
Implicit trust for internal traffic
All traffic authenticated and authorized
VPN provides broad network access
Just-in-time, just-enough access to specific resources
Zero Trust is not a product. It is an architecture. Implementing it requires investment in identity infrastructure (strong MFA everywhere), device health verification (MDM/EDR integration), micro-segmentation (software-defined networking), and continuous monitoring.
The honest trade-off. Zero Trust is genuinely stronger than perimeter security, but it is not free, and it is not always the right first move. Full implementation carries real operational cost: MFA on everything increases user friction, continuous device-health checks need mature endpoint management, and micro-segmentation is complex to design and easy to misconfigure. For a five-person startup with everything in one SaaS-heavy cloud, "turn on MFA everywhere, enforce SSO, and monitor" captures most of the benefit at a fraction of the cost — full micro-segmentation would be over-engineering. The principle to apply is economy of mechanism: adopt Zero Trust incrementally, starting with identity and MFA (the highest-leverage pieces), and add segmentation as the organization's size and risk justify the complexity. Zero Trust is a direction to move, not a box to check overnight.
Secure by Default
Systems should be secure out of the box, without requiring administrators to take additional hardening steps. Default configurations should be the most secure configurations. Insecure features should require explicit opt-in.
Failures of this principle:
Network devices shipped with default credentials that users must actively change (Mirai botnet exploited this at scale)
Cloud services where storage is publicly accessible by default (multiple major breaches from misconfigured S3 buckets)
Software where debug endpoints are enabled in production builds
Services where logging and monitoring must be manually enabled
Microsoft's "Secure by Default" initiative and Google's approach to Android security both operationalize this principle: security improvements that do not require user action reach 100% of the user base; those requiring opt-in reach a fraction.
Minimize Attack Surface
The attack surface is the sum of all points where an attacker could attempt to enter a system. Reducing it (by disabling unused services, removing unnecessary accounts, eliminating unneeded network exposures, and reducing code complexity) reduces the number of opportunities for compromise.
This is distinct from defense in depth, which layers controls over existing attack surface. Attack surface reduction eliminates the attack surface entirely.
Principles in Conflict
Security design principles sometimes conflict, and resolving those conflicts requires judgment.
Usability vs. Least Privilege
Complex permission management drives users to request excessive permissions
Invest in tooling that makes least-privilege easy (permission wizards, role templates)
Complete Mediation vs. Performance
Checking every database access adds latency
Cache decisions with short TTLs; use policy engines (OPA, Cedar) that evaluate quickly
Open Design vs. Business Confidentiality
Publishing security architecture exposes business logic
Separate security mechanisms (which should be open) from business logic (which may be private)
Defense in Depth vs. Economy of Mechanism
Adding layers increases complexity
Prefer independent layers that each address different threat vectors; avoid redundant controls
There is no formula for these trade-offs. Security architecture is engineering judgment applied under constraints. The principles provide the vocabulary and reasoning framework; application requires understanding the specific system, threat model, and organizational context.
Principles Applied to AI Systems
AI and machine-learning systems are now everywhere, and the 1975 principles apply to them — with new wrinkles worth naming, because this is where a lot of design work is heading.
Least privilege for AI agents is now a frontline concern. An LLM-based agent that can call tools, query databases, or execute code is a process that should hold the minimum permissions for its task. An agent given broad credentials "so it can help with anything" is the modern over-privileged service account — and prompt injection (Chapter 15) can turn that privilege against you.
Fail-safe defaults meet probabilistic behavior. Classic systems are deterministic: a check passes or fails. A model's output is probabilistic, so "deny by default" means designing what happens when the model is uncertain or manipulated — validating and constraining model outputs before they trigger actions, never trusting them as authorization.
Open design vs. the model black box. Kerckhoffs's principle says security mustn't depend on the algorithm being secret. With ML, the model's weights may be proprietary, but security still can't rest on attackers not understanding how it works — they will probe it.
Complete mediation still applies. Every action an AI agent takes on a user's behalf should be authorized against that user's permissions at the moment of action, not assumed from the fact that the agent is "trusted."
These are covered in depth in the AI & LLM Security chapter; the point here is that the principles don't change — the threat surface does.
Case Studies: Principles Violated
Principles are abstract until you see what ignoring them costs. Each of these breaches maps cleanly to a violated principle.
Equifax (2017)
Economy of mechanism / minimize attack surface
An unpatched vulnerability in a complex web framework component (Apache Struts) exposed 147M records. The vulnerable feature was attack surface that careful minimization and patching would have removed.
Capital One (2019)
Least privilege
A misconfigured WAF held an over-privileged IAM role that could list and read S3 buckets. A server-side request forgery turned that excess privilege into 100M records exfiltrated. Scoped permissions would have bounded the blast radius.
Heartbleed (2014)
Economy of mechanism
An unnecessary "heartbeat" feature in OpenSSL, with a missing length check, leaked server memory including private keys. Complexity created the vulnerability.
Mirai botnet (2016)
Secure by default
Hundreds of thousands of IoT devices shipped with default credentials users never changed, enabling a record-setting DDoS. Secure-by-default (forced credential change) would have prevented it at scale.
The pattern: catastrophic breaches rarely require exotic technique. They exploit a design principle someone decided to skip.
Try This
Audit a system you use against least privilege. List the apps connected to your Google or GitHub account (in account settings) and the permissions each holds. How many have access far beyond what they need? Revoke the worst offender. You just performed a least-privilege review — the exact task security engineers do at organizational scale.
Find the principle in a real breach. Pick any breach writeup from the last year and identify which design principle(s) from this chapter were violated. Write two sentences linking the failure to the principle. This is precisely how post-incident reviews and security-architecture interviews reason.
Spot the conflict. Take one system you know and find a real tension between two principles in it (usability vs. least privilege is the most common). Describe how you'd resolve it. Naming trade-offs out loud is what separates an architect from a checklist-follower.
Key Takeaways
Controls expire; the reasoning behind them doesn't. The Saltzer & Schroeder principles from 1975 still explain why systems built today get breached.
The highest-leverage classics: economy of mechanism (simplicity), fail-safe defaults (deny by default), complete mediation (check every access), and least privilege (minimum necessary).
Defense in depth requires independent layers addressing different threats — redundant controls against one threat are an illusion of depth.
Zero Trust is stronger than perimeter security but costly; adopt it incrementally, starting with identity and MFA, not all at once.
The principles extend to AI systems unchanged — least privilege for agents, fail-safe handling of probabilistic output — even as the threat surface shifts.
Most major breaches map to a single skipped principle. Knowing them gives you both a design checklist and a post-incident diagnostic.
References
[1] Saltzer, J. H., & Schroeder, M. D. (1975). The protection of information in computer systems. Proceedings of the IEEE, 63(9), 1278-1308. doi:10.1109/PROC.1975.9939
[2] Durumeric, Z., Kasten, J., Bailey, M., & Halderman, J. A. (2014). Analysis of the HTTPS certificate ecosystem. Proceedings of the ACM Internet Measurement Conference, 2014. doi:10.1145/2663716.2663755
[3] Kerckhoffs, A. (1883). La cryptographie militaire. Journal des sciences militaires, 9, 5-38.
[4] Barkan, E., Biham, E., & Keller, N. (2008). Instant ciphertext-only cryptanalysis of GSM encrypted communication. Journal of Cryptology, 21(3), 392-429. doi:10.1007/s00145-007-9001-y
[5] Verizon. (2024). 2024 Data Breach Investigations Report. Verizon Business. Retrieved from https://www.verizon.com/business/resources/reports/dbir/
[6] Kocher, P., Horn, J., Fogh, A., Genkin, D., Gruss, D., Haas, W., Hamburg, M., Lipp, M., Mangard, S., Prescher, T., Schwarz, M., & Yarom, Y. (2019). Spectre attacks: Exploiting speculative execution. Communications of the ACM, 62(7), 93-101. doi:10.1145/3399742
[7] Krebs, B. (2014, February 12). Target hackers broke in via HVAC company. Krebs on Security. Retrieved from https://krebsonsecurity.com/2014/02/target-hackers-broke-in-via-hvac-company/
[8] Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture. NIST Special Publication 800-207. doi:10.6028/NIST.SP.800-207
Further Reading
Saltzer & Schroeder (1975)
The original paper; still worth reading in full. Available via IEEE.
The authoritative Zero Trust Architecture guide from NIST. Free.
Shostack, Threat Modeling: Designing for Security (Wiley, 2014)
Applies design principles in the context of practical threat modeling.
OWASP's application of design principles to web security.
Anderson, R. (2020). Security Engineering (3rd ed.). Wiley.
The most comprehensive text on security design; free online edition available.
Questions about security architecture, design principles, or applying Zero Trust? Join the community on Discord or reach out on LinkedIn. If this chapter helped, contribute back. This book is open source and your additions are welcome.
Last updated