Fail-safe means a failure causes minimal or no harm, usually to people. Fail-secure, also called fail-closed, means a failure keeps unauthorized access out. The two can demand opposite behavior, which is why a door lock is the textbook example and why software teams should name which one they mean.
The door example
In a fire, a fail-safe door unlocks so people can leave and responders can enter. A fail-secure door stays locked to keep intruders out. Same failure, opposite outcome. Building codes and risk assessments decide which applies where, and a single building usually has both kinds.
How it maps to software
Software borrowed the language loosely. A few translations:
- Fail-secure maps to fail closed. An authorization service errors, so the request is denied.
- Fail-safe maps to behavior that limits damage. A watchdog timer that resets a stuck system is a classic fail-safe mechanism in computing.
- "Fail functional" is the third option people rarely name: keep working in a reduced mode. CWE-636 notes that systems often fail open because developers chose to keep things functional and cut support costs, rather than failing safe.
A short test for ambiguous cases
Ask who gets hurt by each outcome. If a denial could endanger a person, you want fail-safe. If an approval could expose data or move money, you want fail-secure. If neither applies, pick the option that is easiest to recover from.
For a payment authorization service, the answer is closed. For an alarm panel that also controls a door, the answer may be open with a loud alert. For an internal wiki search that depends on a ranking service, the answer is degraded mode with plain results.
Common mistakes
Treating the terms as synonyms. They are not. A system can be fail-secure and still harm people.
Applying one default everywhere. A global "deny on error" setting can lock operators out of the very tools they need to fix an outage.
Forgetting the override. Fail-secure systems need a documented, audited manual path. Without one, teams invent unaudited shortcuts during the first real incident.
Never testing the failure. A fail-secure claim that has never been exercised is a hope.
What to write down
For each control: the failure it is designed for, the chosen behavior, the reason, the owner, and how an operator overrides it. Review the list when architecture changes.
Quick check
Is fail-secure the same as fail closed?
In common usage, yes. Both mean the protected resource stays protected when the control fails.
Why not always pick fail-secure?
Where denial can injure people or block emergency response, fail-safe is the right priority. Context decides.
Sources
Last reviewed: 19 October 2026.
