Category: Security Controls & Tailoring

Fail-Safe Defaults

Also known as: Fail Safe Defaults, Secure by Default, Default Deny

Simply put

Fail-safe defaults is a design approach in which a system's out-of-the-box configuration is set to the most secure option, so access is denied unless it is explicitly granted. The goal is that when something goes wrong or is left unconfigured, the system stays in a protected state rather than an open one. It reflects the broader idea of being 'secure by default.'

Formal definition

Fail-safe defaults is a secure design principle holding that access decisions should be based on explicit permission rather than explicit exclusion: absent an affirmative grant, access is denied by default. In practice this means default configuration settings are set to the most restrictive, most secure values, so that unconfigured, erroneous, or failure conditions resolve to a denied or protected state. Note a distinction that experts insist on and that is frequently blurred: NIST defines 'fail safe' as a mode of terminating system functions to prevent damage when a failure occurs, which is not identical to 'fail secure,' defined as preventing loss of a secure state. A fail-safe condition prioritizes preventing damage and can, in some scenarios, still permit a security compromise, whereas fail-secure specifically preserves the secure state. Readers should confirm the intended behavior against the specific control, standard, or design requirement rather than treating fail-safe, fail-secure, and fail-soft as interchangeable.

Why it matters

Fail-safe defaults address one of the most common root causes of security exposure: systems that ship or operate in a permissive state and grant access unless someone deliberately restricts it. When the default posture is 'allow,' every unconfigured setting, overlooked account, or misapplied policy becomes a potential opening. By inverting that logic so access is denied unless explicitly granted, the principle ensures that gaps and oversights resolve toward a protected state rather than an exposed one. This is why the principle is frequently described as being 'secure by default,' and why OWASP and secure-design guidance treat default-deny as a foundational expectation rather than a hardening add-on.

The principle also demands a precision that practitioners often lose. NIST distinguishes 'fail safe', a mode of terminating system functions to prevent damage when a failure occurs, from 'fail secure,' which specifically preserves the secure state. These are not interchangeable. A fail-safe condition prioritizes preventing damage to resources and can, in some scenarios, still permit a security compromise, whereas a fail-secure condition is designed to prevent loss of a secure state. Assuming that a design labeled 'fail-safe' automatically preserves confidentiality or access restrictions is a mistake an assessor should catch, because the intended behavior depends entirely on which property the design is meant to protect.

For compliance and authorization purposes, this distinction matters because control language, standards, and design requirements may specify fail-safe, fail-secure, or fail-soft behavior deliberately. Treating them as synonyms during design review, security assessment, or authorization can lead to a system that behaves differently under failure than the control intended. Readers should confirm the required behavior against the specific control, standard, or design requirement rather than relying on the generic 'fail-safe defaults' label.

Who it's relevant to

System and Security Architects

Architects apply fail-safe defaults when establishing baseline configurations, ensuring that default settings resolve to the most restrictive secure values and that access is denied absent an explicit grant. They must decide, per requirement, whether a component needs to fail safe, fail secure, or fail soft, since these dictate different behaviors under failure and are not interchangeable.

Information System Security Managers and Engineers

ISSMs and security engineers implement and document how default-deny and default configuration hardening are applied across a system. They should verify that the failure-handling behavior deployed matches what the governing control or standard specifies, rather than assuming a 'fail-safe' label guarantees preservation of a secure state.

Security Assessors and Auditors

Assessors evaluate whether a system's defaults are genuinely secure-by-default and whether failure and error conditions resolve to a protected state. They are well positioned to flag the common conflation of fail-safe and fail-secure, since a fail-safe condition prevents damage but can, in some scenarios, still permit a security compromise.

Compliance Officers and Authorizing Officials

Those responsible for authorization decisions rely on fail-safe defaults as evidence that a system does not silently default to a permissive state. They should confirm that design documentation distinguishes the intended failure mode against the applicable control or requirement, and should verify current authoritative text rather than treating the general principle as sufficient proof of the specific behavior required.

Inside Fail-Safe Defaults

Fail-Safe Defaults (Design Principle)

A foundational security design principle, associated with Saltzer and Schroeder's work and referenced in NIST security engineering guidance such as NIST SP 800-160, holding that access decisions should be based on explicit permission rather than explicit exclusion. In most implementations this means the default state denies access, and access is granted only when an affirmative, verifiable condition is met. Readers should verify the current authoritative text of the applicable publication for exact wording.

Default-Deny Posture

The operational expression of fail-safe defaults, in which the absence of an explicit grant results in denial. This generally applies to access control lists, firewall rulesets, and authorization logic, where anything not expressly permitted is refused.

Fail-Safe Condition

As distinguished in NIST usage, a fail-safe condition is one that prevents harm or damage to system resources when a failure occurs. Importantly, a fail-safe outcome is oriented toward protecting resources and personnel and does not, by itself, guarantee that a secure state is preserved; a fail-safe condition can in some cases still permit a security compromise.

Fail-Secure Condition

A distinct concept in NIST usage: a fail-secure condition is one that preserves a secure state and prevents loss of that secure state when a failure occurs. Fail-secure is not synonymous with fail-safe. A given system may be designed to fail safe, to fail secure, or to balance both, and the appropriate choice depends on mission and safety trade-offs. Readers should confirm the definitions in the applicable NIST publication.

Relationship to NIST SP 800-53 Controls

Fail-safe and fail-secure concepts are reflected in control families addressed in NIST SP 800-53 (maintained by NIST), including system and information integrity and system and communications protection controls that concern behavior upon failure. Specific control identifiers, baselines, and tailoring vary across revisions and agency implementations and should be verified against the applicable revision.

Common questions

Answers to the questions practitioners most commonly ask about Fail-Safe Defaults.

Are 'fail-safe' and 'fail-secure' the same thing?

No. They are distinct concepts and should not be treated as interchangeable. In NIST usage, a fail-safe condition is generally oriented toward preventing damage to resources or people when a failure occurs, whereas a fail-secure condition is generally oriented toward preserving a secure state so that a failure does not result in loss of security. Importantly, a fail-safe outcome can still permit a security compromise. When defining requirements, confirm which property you actually need, and verify the exact definitions against the applicable NIST publication, because the two can impose conflicting behaviors in the same system.

Does designing a system to 'fail-safe' automatically mean it fails in a secure state?

Not necessarily. This is a common misconception. Prioritizing fail-safe behavior focuses on avoiding damage, and depending on the design that failure mode may leave the system in a state that is not secure. Preserving a secure state on failure is the concern addressed by fail-secure behavior. Because these objectives can diverge, an expert would insist on identifying which outcome is required for a given component and confirming the intended failure behavior against current authoritative definitions rather than assuming one guarantees the other.

How do I decide whether a given control should fail-safe or fail-secure?

Generally, the decision follows from what the failure most threatens: potential harm to resources or people (which points toward fail-safe considerations) versus potential loss of the secure state (which points toward fail-secure considerations). In most implementations these are evaluated per component rather than for the system as a whole, since different functions may warrant different failure behaviors. Document the rationale and the intended failure mode, and confirm the choice against the applicable NIST guidance and any agency- or program-specific tailoring.

How should the intended failure behavior be documented for an assessment?

In most implementations, the intended failure behavior is captured in system design documentation and reflected in the relevant control implementation descriptions so that an assessor can trace the requirement to how it is realized. Because terminology and expectations can vary by revision and by agency tailoring, state which property is being satisfied and avoid describing a fail-safe behavior as if it also guarantees a secure state. Verify documentation expectations against the current authoritative text and any assessment guidance that applies to your system category.

Does implementing fail-safe or fail-secure defaults, by itself, satisfy the related security requirement?

Not on its own. Establishing a default failure behavior is one element, but demonstrating that the requirement is met generally depends on how the behavior is implemented, tested, and maintained over the system life cycle. Compliance with a stated control is also distinct from being secure in practice. Confirm what evidence is expected for your applicable baseline and, where relevant, how continuous monitoring applies, since requirements can change across revisions.

Can the same system need both fail-safe and fail-secure behavior in different places?

Yes, this is common. Because the two objectives can conflict, a system may require components that prioritize avoiding damage while others prioritize preserving the secure state on failure. Treating the system as uniformly one or the other can obscure real risk. Identify the failure behavior needed per function, resolve conflicts deliberately, and confirm the design choices against the applicable authoritative definitions and any program-specific tailoring rather than assuming a single default applies everywhere.

Common misconceptions

Fail-safe and fail-secure mean the same thing, and either simply means a failure denies access.

NIST distinguishes the two: a fail-safe condition is oriented toward preventing damage to resources, while a fail-secure condition is oriented toward preventing loss of a secure state. These are not interchangeable. A fail-safe condition can still allow a security compromise, so treating fail-safe as automatically equivalent to a secure denial is inaccurate. Practitioners should determine which property a given design actually provides.

Applying fail-safe defaults means a system is compliant with the relevant access control requirements.

Fail-safe defaults are a design principle, not a compliance determination. Compliance is assessed against the applicable control set (such as NIST SP 800-53 or NIST SP 800-171) as tailored for the system, and compliance is distinct from actual security. Adopting a default-deny posture supports certain controls but does not by itself satisfy a baseline or substitute for assessment and authorization.

Choosing to fail safe is always the more secure choice.

The appropriate failure behavior depends on mission, safety, and risk trade-offs. A design that fails safe to protect resources or personnel may not preserve a secure state, whereas a fail-secure design preserves the secure state but may deny availability. The correct choice is context-dependent and should be justified in the system's security engineering and risk documentation.

Best practices

Explicitly distinguish fail-safe from fail-secure in design and requirements documentation, and state which property each failure mode is intended to provide rather than using the terms interchangeably.

Default to explicit permission (default-deny) in access control lists, firewall rulesets, and authorization logic so that the absence of a grant results in denial.

Analyze and document the mission, safety, and security trade-offs of failure behavior, recognizing that a fail-safe condition may protect resources yet still permit a security compromise.

Map failure-behavior design decisions to the applicable NIST SP 800-53 controls as tailored for the system, and verify control identifiers and baselines against the current applicable revision.

Treat fail-safe defaults as one design principle supporting security rather than as evidence of compliance, and confirm that failure behavior is validated during security assessment.

Verify definitions and requirements against the current authoritative NIST publications, since terminology and control tailoring can change across revisions.