In 1975, Jerome Saltzer and Michael Schroeder published "The Protection of Information in Computer Systems" in the Proceedings of the IEEE. It set out eight design principles: least privilege, fail-safe defaults, economy of mechanism, complete mediation, open design, separation of privilege, least common mechanism and psychological acceptability.
The eight, with a modern example
Least privilege. Every program and user should operate with the minimum privileges needed. Example: a CI job that only needs to read a repository should not hold a token that can delete it.
Fail-safe defaults. Access decisions should rest on granted permission, not on the absence of an exclusion. Example: a new service starts with no network access and gains it by rule, rather than starting open and being closed later.
Economy of mechanism. Keep the design as small and simple as possible. Example: one well-reviewed authentication path beats five slightly different ones.
Complete mediation. Every access to every object must be checked. Example: a cached allow decision that outlives a permission change breaks this.
Open design. The design should not depend on being secret. Example: published cryptographic algorithms with secret keys, not secret algorithms.
Separation of privilege. Where possible, a mechanism needing two keys is stronger and more flexible than one key. Example: production deploys that need review by a second person.
Least common mechanism. Minimise shared mechanisms that many users depend on. Example: avoid one shared service account across all pipelines.
Psychological acceptability. The interface should be easy enough that people apply protections correctly. Example: a secure setup that takes forty steps will be skipped.
Why this paper keeps coming back
The definitions above follow the summary in the Wikipedia article on the paper. They are short enough to fit on a card, and they apply across eras. A supply chain incident often turns out to be a broken principle: an over-privileged token, a trusted dependency nobody checked, or a default left open.
Using it as a review checklist
When you review a design, walk the eight in order and ask where each one is weakest. You will rarely fail all eight. Usually one or two stand out, and that is where to spend your time.
Keep the tone practical. The goal is a design that is simpler to defend, not a perfect score.
Where teams usually fail
In practice, the principles that fail most often are least privilege, complete mediation and psychological acceptability. Tokens grow broad because narrowing them is tedious. Caches outlive permission changes because no one thought to invalidate them. Secure setups get skipped because they are painful. Notice that none of these is a mystery about cryptography. They are about everyday engineering habits. A short review once a quarter, asking which tokens could be narrowed and which steps developers are working around, tends to find more than a large audit does.
Quick check
Which principle says to avoid depending on secrecy of the design?
Open design.
Which principle does a shared service account across all pipelines violate?
Least common mechanism, and often least privilege as well.
Safeguard supports policies, gates and guardrails that put least privilege and review into practice, and offers a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
