Core Security Principles Guide: Least Privilege, Separation of Duties and Fail Secure

Most serious breaches do not defeat a clever control, they walk through a place where a basic security principle was never applied: a role with far more access than its job, an unchecked path, a default left open. Core security principles are the short list of design rules that make systems harder to misuse: least privilege, need to know, separation of duties, fail secure, complete mediation, economy of mechanism, open design and secure defaults. Most of them were set out by Jerome Saltzer and Michael Schroeder in 1975 and are still the basis of modern guidance from NIST and CISA. This guide defines each principle in plain language, then shows how practitioners apply and test it, with examples from service accounts, API keys and other non-human identities where these principles fail most often. It is written for security architects, engineers, IAM teams and auditors.

Key takeaways

• Least privilege limits the blast radius. Every user, process and machine identity should hold only the permissions its task needs, for only as long as it needs them; this one principle would have shrunk many of the largest cloud breaches.
• Separation of duties stops one identity finishing a harmful job alone. Splitting request, approval and execution between different people or identities makes fraud and mistakes need collusion, and it applies to pipelines and bots as much as to staff.
• Fail secure and fail safe answer different questions. Fail secure keeps assets protected when a control breaks; fail safe keeps people safe. Decide which applies for each control, in writing, before the failure happens.
• Complete mediation means every request is checked, every time. Cached decisions, trusted internal networks and long-lived tokens are all ways of skipping the check, and attackers look for them.
• Zero trust is these principles applied continuously. NIST SP 800-207 builds on least privilege, per-request authorisation and no implicit trust, so a programme that gets the principles right is most of the way to a zero trust architecture.

The principles at a glance

Saltzer and Schroeder's paper "The Protection of Information in Computer Systems" listed eight design principles. Six of them appear below; the other two (least common mechanism and psychological acceptability) are touched on later. Need to know, separation of duties in its modern form, and secure defaults come from later practice and NIST guidance.

NIST SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems, carries the same ideas forward in its Appendix E, using names such as Least Privilege (E.16), Mediated Access (E.19), Protective Defaults (E.22), Protective Failure (E.23), Reduced Complexity (E.25) and Domain Separation (E.12). NIST SP 800-53 control SA-8 Security and Privacy Engineering Principles lists the principles as 33 enhancements that organisations can select.

Least privilege and need to know

Saltzer and Schroeder put it this way: "Every program and every user of the system should operate using the least set of privileges necessary to complete the job." Need to know is the information-focused version: even with permission to use a system, a person or process sees only the data its task requires. The two work together: least privilege limits what an identity can do, need to know limits what it can see.

Practitioner depth

• Scope by action and resource: grant specific actions on specific resources (read on one bucket) rather than wildcards (all actions on all storage). Wildcard grants in cloud IAM policies are the single most common least privilege failure in machine identities.
• Limit time as well as scope: standing privilege is privilege an attacker can steal at any hour. Just-in-time elevation, short-lived workload tokens and time-bound role assignments reduce exposure. See the JIT Access Guide.
• Separate privileged and everyday identities: AC-6(2) Non-privileged Access for Nonsecurity Functions and AC-6(5) Privileged Accounts expect administrators to use separate accounts, and the same applies to automation: a deployment identity should not double as a monitoring identity.
• Log privileged use: AC-6(9) Log Use of Privileged Functions makes privilege visible, which is what lets you reduce it later.
• Right-size from evidence: grant broad permissions only in a sandbox, record what the workload actually calls, then replace the policy with one generated from that activity. Cloud providers' access analysis tools support this pattern.

Non-human identities are where least privilege erodes fastest, because nobody feels the friction of an over-permissioned service account. See the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide and the Service Account Security Guide.

Separation of duties

Separation of duties (also called segregation of duties) means dividing a sensitive task so that no single person or identity can carry it out alone. Saltzer and Schroeder called a related idea separation of privilege: a mechanism that needs two keys to unlock is more robust than one that needs a single key. NIST SP 800-53 AC-5 Separation of Duties asks organisations to identify and document the duties that must be separated and to define access authorisations to support that separation.

Practitioner depth

• Classic conflicts: request versus approve, develop versus deploy to production, create a vendor versus pay a vendor, administer the audit log versus be audited by it.
• Machine identities count: a pipeline identity that can merge code, sign the artefact and deploy it has collapsed three duties into one credential. Require a separate approval identity, or a human approval step, for production deployment.
• Security administration: those who manage identity and access policies should not be the only reviewers of their own changes; route policy changes for privileged roles through a second approver.
• Small teams: where staff numbers make full separation impossible, use compensating controls: peer review of changes after the fact, immutable logging (AU-9) and periodic independent review.

See the Segregation of Duties Guide for conflict matrices and SoD testing in ERP and cloud environments.

Fail secure and fail safe

Every control eventually fails: a policy engine times out, a certificate expires, a door controller loses power. The principle asks you to decide in advance what the failure state is. Fail secure (fail closed) means the failure leaves the asset protected: access is denied. Fail safe, in the safety sense, means the failure leaves people safe, even if that opens access: a fire door that unlocks when power is lost. Saltzer and Schroeder's "fail-safe defaults" is a related but different idea: "Base access decisions on permission rather than exclusion", in other words default deny.

NIST SP 800-53 SC-24 Fail in Known State and SA-8(24) Secure Failure and Recovery capture this. Test failure modes deliberately: cut the policy engine off in a staging environment and see what the application does. Emergency access paths must be deliberate and audited. See the Break-Glass Account Guide.

Complete mediation

In the original paper: "Every access to every object must be checked for authority." In plain terms, the system asks "is this allowed?" on every request, not once at the door. Complete mediation fails whenever a decision is cached too long, a back-end trusts anything on the internal network, or a long-lived token keeps working after the identity's rights have changed.

• Tokens: short token lifetimes and revocation checks keep authority current; a 90-day bearer token is 90 days of unmediated access.
• Service to service: authenticate and authorise every internal call (mutual TLS plus a policy decision), rather than trusting network location.
• AI agents and tools: authorise each tool call against the user and task, not just the agent session. See the Zero Trust for AI Agents Guide.
• Object level: check that the caller may access this specific record; broken object level authorisation is API1:2023 in the OWASP API Security Top 10.

Economy of mechanism and open design

Economy of mechanism: "Keep the design as simple and small as possible." Complex security code has more places for errors and is harder to review. In practice this means centralising authentication and authorisation (one identity provider, one policy engine) instead of re-implementing checks in every service, and removing unused features (CM-7 Least Functionality).

Open design: "The design should not be secret." Security should rest on secrets that are easy to change, such as keys and passwords, not on hiding how the system works. Use published, reviewed algorithms and protocols (TLS, OAuth 2.0, standard cryptography), and assume attackers can read your source code. Obscurity can add delay, but never count it as a control. The corollary for NHIs is that the key must be the only secret: an API key embedded in a public repository breaks open design's one assumption.

Secure defaults

A secure default means the product or configuration is safe without the user doing anything. CISA's Secure by Design guidance describes secure-by-default products as safe to use out of the box with little or no configuration and at no extra cost, citing examples such as multi-factor authentication, logging of potential intrusions and control of access to sensitive information. NIST SP 800-53 SA-8(23) Secure Defaults and SC-7(5) Deny by Default, Allow by Exception express the same idea.

• Identity defaults: new accounts, human or machine, start with no permissions; MFA is on by default; default and vendor-supplied credentials are removed before go-live.
• Network defaults: deny all inbound, allow by exception, with each exception owned and reviewed.
• Platform defaults: storage private by default, logging on by default, test and demo tenants under the same baseline (CM-2) as production.

See the Security by Design and by Default Guide.

How the principles meet zero trust

Zero trust does not replace these principles, it applies them continuously and at every boundary. NIST SP 800-207 describes authentication and authorisation performed before each session with a resource, with no implicit trust granted on the basis of network location or device ownership, and its tenets grant access with the least privileges needed for the task.

See the NIST SP 800-207 Zero Trust Architecture Guide and the Zero Trust Identity Guide.

Putting the principles into practice

1. Inventory identities and entitlements. Include service accounts, API keys, workload identities and AI agents, each with an owner. You cannot reduce privilege you cannot see.
2. Set baselines. Write a default-deny baseline for new accounts, networks and storage, and make the build pipeline enforce it.
3. Find the biggest gaps first. Rank identities by privilege and exposure: wildcard admin roles, non-expiring keys, identities able to approve their own changes.
4. Right-size in audit mode. Generate a reduced policy from observed activity, run it alongside the current one in report-only or a staging ring, then switch. Keep the previous policy version for fast rollback if a job fails.
5. Introduce separation for high-risk duties. Production deployment, privileged role assignment and payment release first.
6. Test failure modes. Simulate the loss of the identity provider, policy engine and secrets manager; confirm each fails secure and that break-glass works.
7. Review on a cycle. Quarterly for privileged identities, at least annually for the rest, and on every ownership change. Treat a principle exception as a risk acceptance with an expiry date.

Decision guidance

• Strict versus pragmatic least privilege: fine-grained policies for production and data stores; broader, time-boxed rights in isolated sandboxes where speed matters and data is synthetic.
• Small organisations: start with secure defaults and separate admin accounts, which cost little; use compensating review where full separation of duties is not possible.
• Large organisations: invest in central policy engines and automated entitlement analysis; manual reviews do not scale to thousands of machine identities.

Metrics

• Unused permission ratio: share of granted permissions not used in 90 days, for human and machine identities separately.
• Standing privileged accounts: number of always-on admin identities, trending towards zero with JIT.
• Wildcard policies: count of IAM policies granting all actions or all resources.
• SoD conflicts: open conflicts and the age of each accepted exception.
• Owned NHIs: share of service accounts and keys with a named owner and reviewed in the last cycle.
• Fail-secure test pass rate: share of critical controls whose failure mode was tested and denied access as designed.

Framework mapping

Common failure patterns

• Permissions granted for convenience and never removed: roles start broad "to get it working" and stay broad. A quarterly unused-permission report is the cheapest fix.
• Non-production outside the principles: test tenants, demo accounts and legacy apps often run without MFA, ownership or least privilege, yet connect to production.
• Fail open by accident: exception handlers that return "allow" on error, or a library default that skips validation when a key server is unreachable.
• One pipeline identity doing everything: build, sign and deploy under a single credential, so one leaked secret is a full supply chain compromise.
• Long-lived tokens that defeat mediation: access continues after a role change or offboarding because the token is never re-checked.
• Defaults left in place: vendor default passwords, public-by-default storage, single-factor sign-in permitted.

Lessons from incidents

• Least privilege: in the Capital One Breach 2019, the cloud role used by a web application firewall could list and read many storage buckets of customer data, access a firewall never needed. The over-broad role, more than the firewall flaw itself, explains the scale: about 100 million people in the US and 6 million in Canada.
• Secure defaults and complete mediation: in the Microsoft Midnight Blizzard Breach 2024, a legacy non-production test account without MFA led to a legacy OAuth application that Microsoft said had elevated access to the corporate environment. The attacker used it to grant the Exchange Online full_access_as_app role, an application permission that reads mailboxes without any user's sign-in.
• Secure defaults at platform level: after the Snowflake Breach 2024, in which customer accounts without MFA were accessed with infostealer credentials, Snowflake moved to block single-factor password sign-ins for human and service users, turning a configurable option into a default.

Practitioner checklist

• Inventory every human and non-human identity with an owner, purpose and permission set.
• Remove wildcard actions and resources from production IAM policies, starting with machine identities.
• Replace standing administrative access with just-in-time elevation where the platform supports it.
• Document conflicting duties and enforce separation for production deployment and privileged role changes.
• Write down the failure state (fail secure or fail safe) for each critical control, and test it.
• Authorise every service-to-service and agent-to-tool call; shorten token lifetimes to match.
• Apply a default-deny baseline to new accounts, networks and storage, including test tenants.
• Review privileged and machine identities at least quarterly and expire every principle exception.

Standards and references

• Saltzer and Schroeder: The Protection of Information in Computer Systems
• NIST: SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems
• NIST: SP 800-53 Rev. 5
• NIST: SP 800-207 Zero Trust Architecture
• NIST: Cybersecurity Framework 2.0
• CISA: Secure by Design
• ISO: ISO/IEC 27001:2022 Information security management systems, Requirements
• OWASP: API Security Top 10 2023

Related NHI Mgmt Group resources: Privileged Access Management Guide · JIT Access Guide · Segregation of Duties Guide · Defence in Depth Guide · CIA Triad Guide