Fail Open vs. Fail Closed
Two opposite ways a system can behave when a component fails: fail open lets everything through, fail closed blocks everything, and choosing between them is a deliberate design decision.
Also known as: Fail-Open, Fail-Closed, Fail-Secure, Fail-Safe vs Fail-Secure, Fail Open, Fail Closed
Category: Software Development
Tags: security, cybersecurity, software-design, software-architecture, reliability, fault-tolerance, defaults
Explanation
Every system with a check in it will, one day, have that check break. The authentication service times out. The firewall process crashes. The power goes out on an electronic door lock. What happens next?
- **Fail open**: When the check can't run, the system allows the action. Availability wins
- **Fail closed**: When the check can't run, the system denies the action. Security wins
Neither is right in general. What matters is that you choose on purpose, instead of discovering the answer during an incident.
**Examples**:
- **Authentication service down**: An API gateway that fails open lets anyone in. Failing closed is almost always the right call here
- **Rate limiter unavailable**: Failing open is usually acceptable. A few extra requests beat a full outage
- **Spam filter crashes**: Failing open delivers some spam. Failing closed holds back legitimate mail until the filter is back
- **Fraud check times out**: A payment system has to choose between blocking good customers and letting fraud through
- **Firewall or intrusion prevention failure**: Some devices cut all traffic (fail closed), others have a bypass mode that keeps the network up (fail open). Know which one you're running
- **AI guardrail classifier unreachable**: Letting the model answer without the check is fail open
**The terminology trap**:
"Fail-safe" doesn't mean the same thing everywhere. In physical safety, an electric lock that is fail-safe UNLOCKS when it loses power, so people can escape a fire. A fail-secure lock stays locked, to protect what's behind the door. Wikipedia's example: a gate that gives vehicle access to homes uses a fail-safe design, so the fire department can get in. In computer security, "fail-safe defaults" (from Saltzer and Schroeder) means the opposite direction: deny access unless it's explicitly granted.
So when someone says "fail-safe", ask: safe for whom? People, data or uptime?
**How to choose**:
1. **Compare the two failures**: What's worse here, wrongly blocking a legitimate user, or wrongly letting a bad action through?
2. **Decide per component**: An app can fail closed on authentication and fail open on analytics
3. **Write the decision down**: Make it explicit in the design and the code, not an accident of how an exception gets caught
4. **Test it**: Kill the dependency on purpose and check that the system does what you decided
5. **Soften the impact**: Fail closed with a clear error message, a retry, a circuit breaker or a degraded mode (see graceful degradation)
**Watch out for accidental fail open**:
A lot of fail-open behavior isn't designed at all. A `try/catch` that logs the error and returns `true`. A permission check that treats "unknown" like "allowed". A missing config value that disables a check. Those are footguns hiding in error handling.
For access decisions, the default should be fail closed (see Secure by Default). It's the Pit of Success applied to failure: when something breaks, the safe outcome happens without anyone having to think about it.
Related Concepts
← Back to all concepts