Documentation / Platform glossary / Fail-closed / Fail-open

Fail-closed and fail-open

In Short

When a control cannot reach a decision — the policy service is unavailable, a check times out — it must still do something. Fail-closed denies access; fail-open permits it. The choice trades availability against security, and it has to be made deliberately per control rather than inherited from a framework default.

Fail-closed / Fail-open concept diagram

Definition

These terms describe behaviour under failure of the decision path itself, which is different from a decision to deny. A control that denies because policy says no is working correctly. A control that cannot determine what policy says is in an error state, and its configured posture determines the outcome.

Fail-closed denies when the answer is unknown. The security property holds under failure: an outage cannot become unauthorized access. The cost is that a dependency failure becomes an availability failure, potentially for everyone.

Fail-open permits when the answer is unknown. Service continues during a dependency outage, at the cost of a window in which policy is not being enforced. Where it is chosen, it should be paired with loud alerting and a durable record of what was allowed without a check — an unmonitored fail-open is indistinguishable from having no control.

The choice depends on what the control protects. Authentication and authorization are conventionally fail-closed, because the consequence of wrongly permitting exceeds the consequence of unavailability. Non-security enrichment — a reputation lookup, an optional signal — is often reasonably fail-open, because blocking legitimate traffic to protect a non-essential check is a poor trade.

Why It Matters

The dangerous case is neither posture chosen on purpose. Code that treats an exception as a falsy result frequently fails open by accident, and because the control still appears present nobody notices until an audit or an incident.

Stating the posture per control makes it reviewable, and makes the availability implications of a fail-closed dependency visible before it causes an outage.

How QueryTek Uses It

QueryTek treats authentication and authorization as fail-closed: when a decision cannot be made, access is refused. Where a non-authorization signal is unavailable, degradation is explicit and recorded rather than silent. Specific control postures are documented internally, not published.

Related Terms