Fail-closed

Every security component eventually fails. The process crashes, the extension is not loaded, the policy store is unreadable, the identity cannot be resolved, the state file does not validate.

The design question is what happens in that moment, and there are only two answers:

Cannot determine → allow
Cannot determine → deny

Fail-closed is the second. It is also, in practice, the rarer one.

Why “allow” is so common

Not malice — product pressure. A security tool that fails closed interrupts people, and interruptions generate support tickets, and support tickets generate pressure to make the tool less interrupting.

So the failure path quietly becomes the permissive path, and the consequence is specific: a broken enforcement component silently becomes a permission grant, and nobody finds out from the dashboard. The interface still says “Protected” because the interface is reporting configuration, not health.

Configured is not active

The distinction that makes fail-closed real:

Protection configured  ≠  protection active
Protection unavailable ≠  permission granted
Unknown critical state →  locked

A checkbox saying a boundary is enabled is a statement about configuration. Whether the boundary is currently answering is a different fact. A system that conflates them will tell you that you are protected while enforcing nothing.

Fail-closed, fail-secure, fail-lock

The terms are used loosely; the distinctions are worth keeping.

Fail-closed describes a single decision: this request could not be resolved, so it is denied.

Fail-secure is the broader property that the system’s failure modes preserve its security guarantees rather than its availability.

Fail-lock is what BitShout calls the escalation: when a required boundary can no longer be proven healthy, protection moves to a locked state where new authority is refused and existing grants are suspended — and recovery requires explicit revalidation rather than just the component reappearing. See fail-lock and tamper resistance.

The question to ask

When evaluating any security tool, ask directly: what happens when your enforcement component is not running?

If the answer involves a pause, or “it degrades gracefully”, or a change of subject, the answer is allow. There is no third option, and a vendor who has thought about it will say so plainly — including where the platform prevents fail-closed behaviour, which happens and should be documented rather than hidden.