Two default behaviors
Fail-open systems, when they cannot complete a check, let the action proceed anyway — often because blocking legitimate traffic looks worse in a dashboard than an unnoticed gap in enforcement. Fail-closed systems do the opposite: an incomplete, missing, stale, or unverifiable check is treated as a denial, not a pass.
The difference is invisible during normal operation, when every check completes cleanly. It becomes decisive during exactly the situations that matter most for security: an outage, a misconfiguration, an attacker deliberately causing a dependency to fail in order to slip through the gap it leaves behind.
Why fail-open is the more common default
Fail-open is usually not a deliberate security decision; it is what happens when a system is built for availability first and a security check is added afterward without being designed to fail safely. A team under pressure to keep a system running through an incident will often reach for fail-open, since it makes the immediate outage go away, at the cost of removing enforcement precisely while things are already going wrong.
Fail-closed design has a real cost: it means a broken dependency can turn into a denial-of-service problem instead of a silent security gap. That tradeoff has to be made deliberately, with the operational maturity to detect and fix the underlying failure quickly, rather than discovered by accident during an incident.