What is the difference between fail open and fail closed in access control?

How fail open and fail closed differ in access control

Fail open and fail closed describe what happens when an access control decision or control dependency does not work as intended. The practical difference is the default outcome: one mode preserves service continuity, while the other preserves enforcement. In access control, that default matters because the wrong fallback can quietly turn an authorization check into an availability or security problem.

Fail open is a permissive fallback. If the policy engine, directory lookup, token validation, or another control path cannot complete, the system continues and may allow access rather than interrupting the workflow. That can be acceptable for low-risk functions, but it is dangerous when the missing decision is the only barrier between a user and sensitive data, privileged action, or cross-tenant access.

Fail closed is a restrictive fallback. When the control cannot make a reliable decision, access is denied or the operation is blocked until the system can verify what it needs to know. That reduces the chance of unauthorized access, but it can also create service disruption if the control is part of a critical user journey or production workflow. The choice is therefore a trade-off between availability and assurance, not just a technical setting.

Where the security trade-off becomes material

The distinction becomes most important when the access decision protects something with meaningful blast radius, such as administrative functions, customer data, high-value transactions, or systems that can trigger downstream changes. In those cases, a permissive fallback is not just a resilience choice, it can become an authorization bypass. A restrictive fallback is usually the safer default when the system cannot confidently evaluate identity, context, or policy.

For teams designing policy enforcement, the real question is not whether the application should always stay up, but whether it is acceptable to continue when the enforcing control is uncertain. That is why fail closed is commonly preferred for sensitive operations: uncertainty should not become implicit approval. By contrast, fail open is sometimes tolerated where the cost of a temporary denial is higher than the security exposure, but that decision should be explicit and tightly scoped.

Access control architectures also matter. If the decision point sits in the application itself, a failure may be obvious. If it sits in an external policy service, identity provider, gateway, or token-introspection path, a broken dependency can widen the failure mode across many systems at once. For a broader treatment of access model design, see the Authorisation Models Guide, which helps distinguish where policy belongs and how access decisions should be enforced.

What practitioners should check before choosing a fallback

First, identify which controls are allowed to fail open and which must never do so. A sensible design separates low-risk convenience checks from controls that protect confidential data, privileged actions, or tenant boundaries. If the same fallback applies everywhere, the system is usually over-permissive or too brittle.

Second, test the failure path, not just the happy path. Access control is often assumed to work because the policy is correct in the normal case, but the real risk appears when the identity provider is unavailable, a token cannot be validated, a policy store is slow, or an authorization cache is stale. If the system cannot prove a decision, the fallback behavior should be deliberate, documented, and exercised in testing.

Third, treat logging and alerting as part of the control, not an afterthought. If a system is forced to deny access because a check cannot be completed, operators need to know whether that is an expected outage, a dependency failure, or a sign of interference. The same is true for permissive fallback, which should be rare enough that it becomes an actionable security signal rather than background noise. For implementation detail on how failure handling and secure defaults should be written, the OWASP Top 10 A10 Guide and the Secure Error Handling and Logging Guide are directly relevant.

Risk and Threat Considerations

Fail open creates exposure when an attacker can induce a control failure and then benefit from the permissive fallback. In access control, that can turn a dependency outage, cache issue, malformed token, or upstream lookup problem into unauthorized access, especially where the system is meant to enforce deny-by-default behavior.

Failure mechanism: The decision point cannot complete validation, so the implementation substitutes availability for assurance and allows the request to proceed.

Impact: Unauthorized actions may succeed, policy boundaries may be bypassed, and the failure can scale quickly if the same control protects many users, APIs, or tenants.

Practitioner Guidance

Decision rule: If the access decision protects sensitive data, administrative functions, or cross-boundary access, default to fail closed unless you can clearly justify a bounded exception. If the consequence of denial is mostly inconvenience, not security exposure, a stricter fallback is usually the safer choice.

What to verify: Confirm that teams can state, for each major access path, what happens when the policy engine, directory, token verifier, or entitlement source is unavailable. The acceptable answer should be specific, tested, and visible in monitoring rather than assumed from architecture diagrams.

What good looks like: Sensitive paths deny when they cannot make a trustworthy decision, while non-sensitive paths may degrade in a controlled way. The key judgement is that convenience controls never silently inherit the same permissive fallback as high-risk authorization checks.

Practitioner takeaway: Fail open is an availability choice, fail closed is an assurance choice, and the correct default depends on how much harm the system can cause when the access decision is uncertain.

Related resources from NHI Mgmt Group

• Fail-Closed Access Control
• When does policy-based access control fail for workloads and agents?
• Why do permission boundaries fail as a scale control for cloud access?
• How should security teams control access to sensitive data in open shares?