← Reference · Nestor G Pestelos Jr

Software Engineering · Safety

Fail-Closed

Reference entry · last updated August 25, 2026

Fail-closed is a failure mode in which a system withholds a requested action when it cannot determine that the action is permitted or safe. The default under uncertainty is to deny or stop. The term is engineering speech, not an IETF headword. The nearest recommended glossary term is fail-secure: a shutdown that preserves a secure state.[1]

Fail-secure and fail-safe

RFC 4949 (Internet Security Glossary, Version 2) defines fail-secure as a mode of termination that prevents loss of a secure state when a failure occurs or is detected. Damage to some resource may still happen. It defines fail-safe two ways: as a synonym of fail-secure, and as a mode that prevents damage to specified resources (data, property, life) even if a security compromise still occurs. Those two senses oppose each other. The glossary tells authors not to use fail-safe without a local definition, and to prefer fail-secure when the intent is to keep a secure state.[1]

The NIST CSRC glossary repeats those definitions and cites CNSSI 4009-2015 from RFC 4949.[2]

In practice, fail-closed is used for the fail-secure choice: if the decision cannot be made, the door stays locked, the request is denied, the process stops. Fail-open is the other choice: if the decision service is down, the request is allowed.

Fail-safe defaults

Jerome Saltzer and Michael Schroeder stated the access-control form in 1975 as fail-safe defaults: base access decisions on permission rather than exclusion. The default situation is lack of access. The protection scheme lists the conditions under which access is permitted. They credit the principle to E. Glaser (1965).[3]

A conservative design argues why an object should be accessible. It does not argue why it should be refused and then miss a case. When an authorization check cannot complete, Saltzer's default is to refuse.

Last-known-good

Last-known-good is a related recovery, not a synonym of fail-closed. Instead of stopping, the system keeps a previously validated configuration and falls back to it when a new configuration fails to load or validate.

The Kubernetes Node API documents this as status.config.lastKnownGood on NodeConfigStatus. The node falls back to that checkpoint when it cannot use the assigned config. Assigned becomes last-known-good after a soak period in which it has been active without error. If the config source is cleared, last-known-good is cleared too, because local defaults are treated as good.[4]

The dynamic kubelet-config feature that populated that field is deprecated in Kubernetes 1.22. The field remains the documented example of a last-known-good fallback in the API.[4]

Fail-closed refuses the new action. Last-known-good continues with an older validated state. Both avoid applying an unvalidated new state. They differ on whether work stops or continues on the last good copy.

Software agents

This site uses fail-closed for an agent that stops or escalates when the next action is not licensed by policy or evidence, rather than guessing. That usage applies Saltzer's default and RFC 4949 fail-secure to a tool-calling loop. It is not a separate standard term.

A public example is the guest-stay agent demo: act, escalate to a host, or stop. The split is the product of the control plane, not a prompt vibe.[5]

What it is not

Exponential backoff is a retry schedule after a failed attempt. It can sit next to a fail-closed policy (retry a transient 429, stop when the action is not allowed). It is not the same decision.[6]

Fail-soft, in RFC 4949, is selective termination of non-essential functions. The system keeps running in a reduced form. Fail-closed on a given action may still leave other functions running; fail-soft is about which functions are dropped, not about whether an uncertain action is permitted.[1]

A circuit that retries without a stop rule is fail-open under uncertainty. A demo that always produces an answer when evidence is missing is the same choice.

See also

References

  1. ↑ R. Shirey, Internet Security Glossary, Version 2, RFC 4949, August 2007. Entries fail-safe, fail-secure, fail-soft, failure control. https://www.rfc-editor.org/rfc/rfc4949.html
  2. ↑ NIST Computer Security Resource Center, glossary term fail secure, citing CNSSI 4009-2015 from IETF RFC 4949 Ver 2. https://csrc.nist.gov/glossary/term/fail_secure
  3. ↑ Jerome H. Saltzer and Michael D. Schroeder, “The Protection of Information in Computer Systems,” 1975. Principle: fail-safe defaults. Teaching copy: https://www.cs.virginia.edu/~evans/cs551/saltzer/
  4. ↑ Kubernetes, Node API, NodeConfigStatus.lastKnownGood. Dynamic kubelet configuration that used this field is deprecated since 1.22. https://kubernetes.io/docs/reference/kubernetes-api/core/node-v1/
  5. ↑ Guest-stay agent demo (public Play). Act, escalate, host override, stop. https://guest-agent-demo.ngpcloud.org/. Source: https://github.com/ngpestelos/guest-stay-agent
  6. ↑ Nestor G. Pestelos Jr., “Exponential backoff,” reference entry. https://ngpestelos.com/reference/exponential-backoff/