Security controls are designed to protect systems when everything is working normally.
But what happens when something goes wrong?
- A firewall crashes.
- An access-control system loses power.
- A database stops responding.
- A network connection fails.
- A security service becomes unavailable.
- A software component encounters an unexpected error.
In these situations, the system has to make a decision about what happens next.
- Does it allow access?
- Or does it deny access?
The principle of Fail Secure provides a simple answer:
When a security control fails, it should default to the more secure state rather than allowing unauthorised access.
This is an important principle in cybersecurity because security controls themselves are not immune to failure.
What is Fail Secure?
Fail Secure means that when a system or security control encounters a failure, it should transition to a state that maintains or improves security.
In many situations, that means Deny access rather than allow it.
For example, imagine an electronic door controlled by an access-card system.
If the access-control system fails, there are two possible approaches.
- Fail Open – The door unlocks when the system fails. This maintains physical access, but potentially compromises security.
- Fail Secure – The door remains locked when the system fails. Security is maintained, but legitimate users may also be unable to enter.
This illustrates one of the fundamental challenges of security engineering:
A more secure failure state can sometimes reduce availability.
Fail Secure vs Fail Open
The difference can be summarised very simply.
| Approach | When the system fails |
|---|---|
| Fail Secure | Access is denied or security is maintained |
| Fail Open | Access is allowed or restrictions are relaxed |
Consider a firewall.
If the firewall stops functioning, a fail-secure design might prevent network traffic from passing through, whereas a fail-open design might allow traffic to continue without inspection.
The second option preserves connectivity, but it potentially removes an important security control.
Why is Fail Secure important?
Security controls exist partly because we don’t trust the environment around them. If a security control fails and the system automatically becomes less secure, the failure itself can become an attack opportunity.
An attacker might deliberately attempt to cause a security control to fail.
A fail-secure design aims to break this type of attack.
The failure of the system may still cause an operational problem, but it doesn’t automatically create a security vulnerability.
Fail Secure and the principle of Default Deny
Fail Secure is closely related to another important security concept of Default Deny.
Default deny means If there is no explicit permission to perform an action, the action should be denied.
For example, a firewall might operate on the principle:
Allow HTTPS ✓
Allow DNS ✓
Allow VPN ✓
Everything else ✗ DENY
Here, instead of defining every possible malicious connection and blocking each one, the system allows only what is explicitly permitted.
This is often described as allow by exception rather than deny by exception.
Default deny therefore provides a natural foundation for fail-secure behaviour.
Fail Secure in authentication
Authentication systems provide another example of fail secure
Imagine a user attempts to log in, but the system cannot determine whether the supplied credentials are valid.
A fail-secure approach is:
Authentication result
|
+---- Valid ----> ALLOW
|
+---- Invalid --> DENY
|
+---- Unknown --> DENY
The system shouldn’t interpret “I can’t verify this person.” as “They must therefore be allowed in.”
Instead, if the system cannot establish that access is authorised, access is denied.
This is particularly important for sensitive systems.
What happens when an authentication server is unavailable?
Consider an organisation using a central authentication service.
A user attempts to access a sensitive application, and the application asks the authentication service to verify their identity.
But the authentication service is unavailable.
The application now has a choice.
- Fail open – “I can’t verify the user, so I’ll let them in.” – This preserves availability, but it potentially creates a serious security weakness.
- Fail secure – “I can’t verify the user, so I won’t allow access.” – This protects security, but legitimate users may be unable to work.
This illustrates why security architecture is often about balancing security and availability rather than maximising one at the expense of everything else.
Fail Secure and physical security
Fail Secure is particularly visible in physical access-control systems.
Examples include:
- Electronic doors
- Security gates
- Server rooms
- Data centres
- Safes
- Turnstiles
- Access-controlled cabinets
For example, a server room containing sensitive equipment might be designed so that a failure of the electronic access system leaves the door locked. This protects the equipment from unauthorised physical access, but adds an important complication:
What happens if someone needs to get out?
A system that simply locks everyone inside during a power failure could create a serious safety hazard.
This is where the distinction between fail secure and fail safe becomes extremely important.
Fail Secure vs Fail Safe
The two terms sound similar but address different objectives.
- Fail Secure – Prioritises security when a system fails. The system moves towards a state that prevents unauthorised access.
- Fail Safe – Prioritises safety when a system fails. The system moves towards a state that protects people from physical harm.
These objectives can sometimes conflict.
For example, a secure door might remain locked when power is lost, but people inside a building must still be able to escape during an emergency.
A real access-control system may therefore be designed so that:
- The outside remains secure
- People inside can exit
- Emergency systems override normal security controls
This is a good example of why security engineering cannot be considered in isolation.
Fail Secure and availability
One of the most important limitations of fail-secure design is that security and availability can sometimes pull in opposite directions.
Lets re-visit the above scenario where an organisation’s authentication system fails.
A fail-secure system may prevent everyone from logging in, so from a security perspective, that’s sensible.
However, from a business perspective, it could be disastrous.
Employees may be unable to:
- Access email
- Process orders
- Serve customers
- Access databases
- Operate business systems
This is why organisations need to consider the consequences of failure when designing security controls.
The question isn’t simply “What is the most secure failure state?”. It is “What is the most appropriate secure failure state for this system and its purpose?”
Fail Secure and the CIA Triad
This is where the CIA triad becomes particularly useful.
Fail-secure designs primarily protect:
Confidentiality – Unauthorised users aren’t automatically given access when a control fails.
Integrity – Unauthorised changes aren’t automatically permitted during a failure.
But fail-secure behaviour can potentially affect:
Availability – Legitimate users may be unable to access systems when a security control fails.
This isn’t necessarily a flaw – It is a security trade-off.
The organisation needs to determine which failure mode is appropriate for the system.
Fail Secure and defence in depth
Fail Secure is also an important part of defence in depth.
Imagine an organisation has several security layers:
Firewall -> Authentication -> Authorization -> Application security -> Data protection
If one layer fails, a fail-secure design means that the failed control doesn’t automatically remove the protection it was providing.
For example if the firewall fails, then traffic is blocked and the service is isolated. The other controls remain active
Fail-secure behaviour helps ensure that a failure in one layer doesn’t turn into an immediate security compromise.
Fail Secure and Zero Trust
Fail Secure also fits naturally with Zero Trust.
Remember that Zero Trust is based on the idea that access should be explicitly verified. So, if the system cannot verify that access should be allowed, a secure approach is generally to deny the request.
This is effectively a default-deny approach.
The absence of sufficient evidence for access isn’t treated as permission.
Fail Secure in applications
The principle of fail secure can also be applied within software.
Consider an application that needs to determine whether a user is allowed to access a particular record.
A dangerous design might allow access if permission checks fail
A safer approach is to only allow access if the permissions check returns an allow status, but to deny access in every other consideration – including no response
If the authorization system encounters an unexpected error, the application doesn’t simply assume permission.
This principle is particularly important for sensitive operations.
Fail Secure in access control
Access-control systems frequently follow a similar model.
Suppose a user requests access to a file.
The system checks:
- Who is the user?
- What role do they have?
- What permissions do they have?
- What is the classification of the file?
If the system cannot establish that the user is authorised, the request should normally be denied. This prevents situations where an error in the access-control mechanism accidentally exposes sensitive information.
Fail Secure in cloud environments
Cloud environments contain many security controls that can potentially fail.
For example:
- Identity services
- Network security groups
- Access policies
- Secrets management
- Encryption services
- API gateways
- Logging systems
A well-designed cloud architecture should consider what happens when these components are unavailable or return unexpected results.
Fail Secure and logging
Logging provides an interesting example because the correct behaviour isn’t always simply “deny access.”
Suppose a security monitoring system becomes unavailable. The organisation doesn’t necessarily want every system to stop operating.
Instead, it might:
- Continue normal operation
- Raise an alert
- Buffer logs locally
- Retry transmission
- Restrict particularly sensitive actions
- Escalate the failure
This demonstrates an important principle – Fail Secure doesn’t always mean “shut everything down.” It means that the system should fail in a way that doesn’t unnecessarily compromise its security objectives.
The appropriate response depends on the system.
Designing for graceful failure
A mature security architecture doesn’t simply assume that systems will either work perfectly or completely fail. It considers different failure states.
For example:
Normal operation
↓
Security service unavailable
↓
Restrict sensitive operations
↓
Continue essential services
↓
Alert administrators
↓
Restore security service
This can provide a better balance between security and availability than simply shutting down everything.
The important point is to design the failure behaviour deliberately – Don’t leave it to chance.
What about emergency access?
Sometimes organisations need to deliberately bypass normal security controls. For example, an administrator may need emergency access to a critical system during a major outage.
This can be handled through what’s called break-glass accounts or emergency access procedures.
The important thing is that the emergency mechanism should itself be controlled.
The objective is not to eliminate every possible bypass, it is to ensure that emergency access doesn’t become an easy way around normal security controls.
Fail Secure and human safety
Security should never be considered more important than human life and safety.
This is particularly important in:
- Industrial control systems
- Manufacturing
- Transport
- Healthcare
- Building access systems
- Power systems
- Safety-critical environments
For example, a physical security system may need to allow people to escape during a fire even if doing so technically reduces security. So fire doors should fail in an open state, not a locked one for example.
In such situations, the system should be designed around the appropriate safety requirements.
This is why the phrase “Fail secure at all costs.” would be a poor security principle.
The correct approach is “Design failure behaviour deliberately, considering security, safety, availability and business requirements.”
Testing Fail Secure behaviour
An organisation shouldn’t simply assume that its systems fail securely – It should test them.
For example:
- What happens if the authentication service goes offline?
- What happens if the firewall fails?
- What happens if the access-control database becomes unavailable?
- What happens if a security certificate expires?
- What happens if a logging system stops accepting events?
- What happens if a network connection to a security service fails?
These scenarios can be tested during:
- Disaster recovery exercises
- Penetration testing
- Security testing
- Resilience testing
- Configuration reviews
- Incident response exercises
Testing may reveal that a system fails in an unexpected way.
It’s far better to realise that the system doesn’t work as expected under test situations, then in a real emergency.
In summary
Fail Secure is the principle that when a security control or system fails, it should default to a state that maintains security rather than automatically allowing unauthorised access.
It can be implemented through:
- Default-deny access controls
- Firewall rules
- Authentication and authorization controls
- Secure application design
- Access-control systems
- Network segmentation
- Privileged access controls
- Secure error handling
- Emergency access procedures
- Deliberate failure-state design
Fail Secure is closely related to:
Least Privilege – If a component fails, it shouldn’t suddenly gain additional privileges.
Zero Trust – If access cannot be verified, it shouldn’t automatically be allowed.
Defence in Depth – The failure of one control shouldn’t expose everything behind it.
The CIA Triad – Fail-secure behaviour often protects confidentiality and integrity, but can potentially reduce availability.
Remember, at some point security controls will fail.
- Networks fail.
- Servers fail.
- Software fails.
- Power fails.
- People make mistakes.
The important question isn’t “Can we prevent every failure?” because we can’t.
The important question is “What happens when the failure occurs?”
If failure creates an opportunity for unauthorised access, the system may have a serious weakness.
If failure causes the system to move into a controlled and appropriately secure state, the failure is much less likely to become a security incident.
Don’t just design systems for when everything works. Design them for what happens when it doesn’t.