Failure modes — SY0-701

WHAT IT IS

A failure mode describes the behavior a system exhibits when a fault occurs or is detected. Security architecture must specify failure modes deliberately, because an uncontrolled failure can either leave resources unprotected or render them unavailable. Two defined failure modes dominate security design decisions:

• Fail safe — "A mode of termination of system functions that prevents damage to specified system resources and system entities (i.e., specified data, property, and life) when a failure occurs or is detected in the system (but the failure still might cause a security compromise)." (CNSSI 4009-2015, derived from IETF RFC 4949 Ver 2, via NIST CSRC Glossary)

• Fail secure — "A mode of termination of system functions that prevents loss of secure state when a failure occurs or is detected in the system (but the failure still might cause damage to some system resource or system entity)." (CNSSI 4009-2015, derived from IETF RFC 4949 Ver 2, via NIST CSRC Glossary)

The two definitions create an explicit trade-off: preserving physical safety or operational continuity (fail safe) is a different goal from preserving the security posture (fail secure), and the right choice depends on what the system is protecting.

---

Mental model

Think of a controlled access door during a power failure:

• A door that unlocks when power fails — people can exit safely (physical safety preserved), but the secured space is now open to anyone. This is fail safe behavior: damage to physical entities is prevented, but a security compromise is possible.
• A door that locks when power fails — the space stays secure, but people inside may be trapped. This is fail secure behavior: the secure state is preserved, but a resource (the people) may be harmed.

Neither mode is universally "correct." The appropriate choice is determined by what the architecture is designed to protect: life-safety regulations may mandate fail-safe; a high-value data vault may mandate fail-secure.

---

When to use it

Design goal	Preferred failure mode	What is preserved on failure	What may be lost
Prevent harm to physical resources, life, or property	Fail safe	Physical integrity, operational continuity	Secure (closed/authenticated) state
Prevent loss of secure posture	Fail secure	Confidentiality and integrity of the secured state	Access to system resources or entities

The distinction matters for every security control that sits in a traffic path: firewalls, inline intrusion prevention systems, and network access control devices all face this choice at the architecture level.

---

COMMON MISCONCEPTION

The most common trap is conflating "fail safe" with "the safe security choice." The NIST definitions show these are orthogonal goals. A system that fails open (allows all traffic when it faults) may satisfy a fail-safe objective for operational continuity, but it explicitly trades away the secure state — which is exactly what fail-secure design aims to prevent. The NIST definitions make this explicit: fail safe "might cause a security compromise," and fail secure "might cause damage to some system resource." Neither mode eliminates risk; each accepts a different kind of loss. Choosing fail-secure for an access control system does not make the failure harmless — it merely channels the harm away from the security posture and onto availability.

---

How it shows up on the exam

Security+ questions on this concept target analysis and application, not recall. A scenario will describe a system — a firewall, an inline prevention sensor, a badge reader — and ask what happens, or what should happen, when that system encounters a fault. Candidates often confuse the terms because "safe" sounds universally positive. The cognitive task is recognizing that "safe" in fail-safe refers to physical or operational safety, not security posture, and that the NIST definitions carry an explicit caveat about what each mode does not protect.

Signal phrases to watch for: "device fails," "loss of power," "inline component crashes," "what behavior is expected," "which design principle," "the system should default to." When a scenario prioritizes keeping an environment operational at the cost of access control enforcement, fail-safe reasoning is in play. When a scenario prioritizes denying access even at the cost of service disruption, fail-secure reasoning is in play.

---

Related concepts

• Jump server
• Intrusion detection and prevention
• Load balancer