Fail closed when a wrong "yes" costs more than a temporary outage, such as authentication, authorization and payment checks. Fail open when a wrong "no" does more harm, such as safety exits or a non-critical enrichment step. Decide per system, write the choice down, and test it.
Why this is a decision, not a default
Every control that depends on something else will eventually lose that something. A policy service times out. A token validator cannot reach its key store. A scanner crashes. At that moment the code does one of two things: it lets the request through (fail open) or it refuses (fail closed).
Most teams never chose. The behavior came from an exception handler somebody wrote on a Friday. The first step is to find out what each control does today.
Four questions that settle most cases
- What does a wrong "allow" cost? Data exposure, money moved, a privileged action taken. If the answer is severe or irreversible, lean closed.
- What does a wrong "deny" cost? Lost sales, locked out staff, a blocked emergency fix. If people could be hurt by denial, lean open.
- How long will the failure last? A blip of seconds favors a short grace period. An hour-long outage makes open dangerous and closed painful, which argues for a planned degraded mode.
- Who can override, and is it logged? A fail-closed system with an audited break-glass path is easier to live with than one with no exit.
A rough map
Authentication and authorization checks: closed. If the identity provider is unreachable, do not invent identities. You can still honor sessions that were already validated, for a short and bounded time.
Input validation and file upload scanning: closed. A validator that skips on error is a bypass with extra steps.
Rate limiting and bot filtering: often open for logged-in users with a good history, closed or tightened for anonymous traffic. Mixed behavior is fine if you write it down.
Recommendation widgets, analytics, A/B assignment: open. These are not security controls.
Physical safety paths such as emergency exits: open, because the harm of denial is injury. The distinction between fail-safe (no harm to people) and fail-secure (nothing leaks) is a well known one in lock design, and the two can pull in opposite directions.
Make the choice visible
Put the decision in a table next to the architecture doc: control, failure behavior, who approved it, last test date. Then make the setting explicit in configuration rather than implied by code. For example, many policy engines expose the choice as a flag, and the safe value is the one you want after hours when nobody is watching.
Avoid a third trap: a fail-open path that nobody monitors. If a control fails open, an alert should fire the moment it does, because the failure is silent to users by design.
Test it
Break the dependency on purpose in a test environment and watch what happens. See the chaos experiment posts in this series for how to scope that safely. The point is not to prove the control is perfect. It is to confirm the failure mode matches the entry in your table.
Safeguard's policy gates let you set whether a pipeline check blocks or only reports, so the failure behavior of a gate is a visible setting rather than a surprise.
Quick check
Is fail closed always the secure choice?
No. It is the safer choice for access decisions, but for life safety systems denial can cause harm. Choose by the cost of each wrong answer.
Can I mix both in one system?
Yes. Different controls can fail differently, as long as each choice is documented, monitored and tested.
Sources
- CWE-636: Not Failing Securely ('Failing Open')
- Fail-safe (Wikipedia)
- OWASP Secure Product Design Cheat Sheet
Last reviewed: 19 October 2026.
