Fail-Open vs Fail-Closed: Choosing Which Way a Control Breaks

Every control fails eventually, and it fails in one of two directions. Fail-open means access is permitted when the control stops working — availability is preserved, security is lost. Fail-closed, or fail-secure, means access is denied — security is preserved, availability is lost. Choosing is a business decision, and defaults frequently choose for you.

The general principle and its exception

Security controls should generally fail closed. A control that stops enforcing when it breaks provides an attacker with an obvious strategy: break the control. An authentication system that admits everyone when its database is unreachable is not an authentication system.

The exception is life safety, and it overrides everything. Doors on emergency exit routes must unlock when power or control fails, because people trapped in a burning building is a worse outcome than an unauthorized entry. Fire codes require this and they are not negotiable — a security design that conflicts with them is illegal as well as wrong.

This produces a deliberate asymmetry in physical security. Perimeter and exit doors fail safe (unlocked); interior doors protecting equipment or data fail secure (locked), because nobody needs to escape through a server room. Recognizing which rule applies to which door is the exam point.

Where each is correct

Fail closed for anything protecting confidentiality or integrity. An authentication or authorization service that cannot reach its directory must deny. An inline security appliance that crashes should block rather than pass traffic uninspected. A signature verification that cannot complete must reject rather than accept.

Fail open where the consequence of denial exceeds the consequence of permitting. Industrial safety systems, medical devices, emergency communications and building egress all fall here — and the common thread is that unavailability causes physical harm.

Some controls are legitimately configurable and the answer depends on context. A network access control deployment that fails closed during a RADIUS outage takes the entire office offline; failing open leaves unauthenticated devices on the network. Many organizations choose a middle path — failing into a restricted VLAN with limited access — which is the pattern worth knowing because it appears throughout: fail into a degraded but safe state rather than choosing between two absolutes. The mechanism is the guest and restricted VLAN handling described under 802.1X.

The failures that happen by accident

The dangerous cases are the ones nobody decided.

Certificate and revocation checking is the classic. Most clients fail open when an OCSP responder is unreachable, because failing closed would break browsing whenever a responder has a bad day. The result is that revocation checking is advisory, which matters when you are relying on it — the caveat under certificate lifecycle.

Logging. When a logging pipeline fails, does the application stop or continue unlogged? Continuing is usually right operationally and means an attacker who breaks logging gains invisibility. At minimum, alert loudly on log delivery failure — silence from a log source is a signal, and few organizations monitor for it.

Security agent crashes. If the endpoint agent stops, does the endpoint keep working? Almost always yes, which makes stopping the agent a productive first move for an attacker. Tamper protection and alerting on agent absence are the compensations.

Rate limiting and WAF bypass on failure. Many deployments pass traffic when the inspection component is overloaded, which means generating load is a way to disable inspection.

In each case the behaviour was chosen by a default, not by an assessment. The useful exercise is to walk through each control and ask what happens when it breaks — the answers are frequently surprising.

Reducing how often it matters

The best answer to the dilemma is not to face it. Redundancy means a single component failure does not trigger the fail state at all: multiple authentication servers, clustered inline devices, hardware bypass in appliances that engages only on total failure.

Where the fail state is reached, make it visible. A control that fails open silently is the worst case, because the organization believes it is protected. Alert on entry into the degraded state and treat it as an incident rather than a condition — the automation equivalent is the circuit breaker discussed under automation guardrails, which stops and escalates rather than continuing blindly.

Then test it. Disconnect the authentication server in a maintenance window and observe what actually happens, because the documented behaviour and the real behaviour differ more often than anyone expects.

Exam angles

Define fail-open as permitting access on failure (availability preserved) and fail-closed or fail-secure as denying it (security preserved). Know that security controls default to fail-closed except where life safety applies, and that emergency egress doors must fail safe and unlocked by fire code while interior secure areas fail locked. Recognize a degraded but restricted state as the common middle option, and know that silent fail-open behaviour in revocation checking, logging and inline inspection is a frequent unexamined risk.