What are the key principles of effective security design?

The most durable security design rules come from a 1975 paper by Saltzer and Schroeder: economy of mechanism, fail safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism and psychological acceptability. Modern guidance from NIST and CISA builds on the same ideas.

Why still use a 1975 paper?

Technology changed. The shape of the problems did not. The paper, titled The Protection of Information in Computer Systems, lists eight principles for protection mechanisms, and design reviews today still reduce to them. NIST's SP 800-160 Volume 1 describes principles and activities for engineering trustworthy secure systems "regardless of the system's purpose, type, scope, size, complexity, or the stage of its system life cycle". The common thread: security is a property you design in, not a layer you add at the end.

What does each principle mean in practice?

Economy of mechanism. The paper says to keep the design "as simple and small as possible". Review question: can one person read and understand the access control code? An authorization system spread across five services and three languages is where bugs hide.

Fail safe defaults. Base access on permission, not exclusion, so the default is no access. Review question: what happens to a new endpoint or a new role that nobody configured? It should be denied.

Complete mediation. Every access to every object must be checked. The paper calls this the primary underpinning of protection. Review question: is the check done on the server for each request, or only when the user first signed in? A cached "allowed" decision that outlives a role change breaks this.

Open design. The design should not depend on secrecy of the mechanism, only on secrecy of keys. Review question: if an attacker read our source and architecture documents, what would still protect us?

Separation of privilege. Where feasible, require two keys, not one. Review question: can a single compromised account both approve and deploy a production change? Two person approval for sensitive operations applies this.

Least privilege. Every program and user should operate with the least set of privileges needed to do the job, which limits damage from accident or compromise. Review question: what is the worst thing this service account can do, and does the job truly need it?

Least common mechanism. Minimize mechanisms shared among users, since shared channels are paths for leaks. Review question: do tenants share a cache, a queue or a service identity that one of them could abuse?

Psychological acceptability. The human interface must be easy enough that people apply protections correctly. Review question: if the secure path takes six steps and the insecure one takes one, which will people use under deadline pressure?

What do modern guides add?

CISA's Secure by Design publication, updated in October 2023 with a group of international partners, names three principles for software manufacturers: take ownership of customer security outcomes, embrace radical transparency and accountability, and lead from the top. The first two echo open design and psychological acceptability at organization scale. The third is about who funds and prioritizes the work.

A constructed example

A team designs an internal tool for issuing refunds. In review they find a single admin role can create, approve and pay a refund (separation of privilege), the approval check runs only in the browser (complete mediation), and new staff accounts default to the admin role (fail safe defaults). They fix each in the design document before writing code, which costs a day instead of a quarter of rework.

How to check or apply this

1. Add the eight principles as a short checklist in your design review template.
2. For each new service, write one sentence per principle describing how it is met or why it is not.
3. Review default settings, not only chosen ones.
4. Test authorization on the server for every request type.
5. Record exceptions with an owner and expiry.
6. Revisit the checklist after each incident, and add what it missed.

Safeguard's policies and gates can enforce parts of this automatically in pull requests and pipelines, such as blocking changes that break a rule you wrote down.

Quick check

Sources

• Saltzer and Schroeder, The Protection of Information in Computer Systems
• NIST SP 800-160 Vol. 1 Rev. 1
• CISA Secure by Design

Last reviewed: 18 October 2026.