Security controls are designed to fail in one of two ways: fail open, which maintains availability by removing restrictions, or fail closed, which preserves confidentiality and integrity by blocking all access. Choosing the right failure mode depends on weighing the sensitivity of the asset against the criticality of keeping it available.
Fail Open vs Fail Closed
One thing we need to understand is that whatever we implement will have an opportunity to fail, and probably will at some point in time, so we need to plan for that failure. But one of the things that we need to plan for is, is that failure going to fail open or fail closed?
We're going to use definition number one for what a security control is: that is, any safeguard or measure that we put into place to help cyber security. So it's those actions, those devices, those procedures that we put into place.
Let's use this asset as an example. We've got data that needs to be protected, we have a wall around it, and we have a gate. But a vulnerability has happened: something's happened where our security is broken here, and so we have a failure.
Now, a fail open state means that this gate no longer is going to exist. If there is a break or a weakness, then we do away with the gate, exposing this asset right here, so everyone can get to that asset.
Then we have the fail closed, or fail secure — it's going to fail to a secure state. What that means is that this gate right here, if there's an issue on it, now turns into a wall. It just makes this data here completely unavailable.
At first glance it may seem like we would always want to fail closed, that is, we would never want to expose our data to the outside world. Maybe that's the case — in fact, a lot of times we do want it to fail closed. But there are times that we do want to have it fail open. So what are those scenarios?
One example where I'd probably say we would want a fail open would be an access door. Let's say we had a door that you had to badge in and out of to get through; maybe it's an access into a building. So that's a control that we probably want to fail open. The reason being, let's say there was a fire and that badge system was damaged, and so now you can badge in and out like you typically could. If it were to fail closed, that means that door would be locked, it would be secure, and you couldn't get in or out of that door. In that case right there, we could trap people inside of a building. So in this scenario we would probably want it to be a fail open, that that door would become unlocked so people could exit the building in the event of a fire.
When determining whether we want to fail open or fail closed, I like to think of it from the CIA triad. What are we trying to implement when it comes to security? We're trying to have confidentiality, integrity and availability, and we're weighing out that confidentiality and integrity, and the importance of it, over availability. Essentially, if it's failing open, then it maintains that availability; when it fails closed, we're losing that availability.
So I think of it as a scale. On one side we've got confidentiality and integrity, with the top part being very risky here — from a confidentiality and integrity standpoint, we wouldn't want this information to get out — and the bottom side here means it doesn't really matter if that information got out or not. I use information just as an example; there are other scenarios here as well. Then we also have availability risk here, and on one side it's very critical that it remains up and running, versus the other side, where it's not as critical.
One is a firewall. A firewall, if it were to fail, it would really put our network at risk if it failed open. So it is a high: we definitely want it up and running, it's really important that this is up and running, but it's more important that we have confidentiality and integrity and we don't compromise our network. So this would be a case where we would want to fail closed.
However, what we may also have is some sort of web filtering that makes sure that our employees aren't getting to sites that they really shouldn't be getting on. Maybe it's some sort of productivity loss, or maybe there's some sort of issue with the site, and so we have some sort of web filtering here. But it's not nearly as important. There's really not confidentiality and integrity risk here, and the availability of our services, of our internet to employees, is more important. And so what we've weighed this out to is that this probably should fail open: if this were to go offline, we wouldn't want them to not be able to get out to the internet.
Let's look at another example. Here we have access control into a folder, and let's say access control goes away and this folder has sensitive information. It's not as important, really, that it's up and available, so we've got it on this side of the availability; the risk is pretty low from that perspective. But it is important that we keep things secure, so in this case right here we would want this to fail closed.
Now we have that same type of access control, but for a printer. Well, now this access control, it's important that it's available, not super important — that's why it's on this side of the line — but it's also really not important from a confidentiality and integrity risk either. So maybe on this we fail open.
And then here we have maybe some monitoring that's happening, and it's just monitoring our logs and doing some log aggregations. If we don't have access to that log at any given time, it's not really sensitive much from a confidentiality standpoint. Maybe we don't really want that information out, maybe it's a little sensitive, but not that sensitive. But availability is really not important at all. So then this might be something that we choose to either fail open or closed. In this case right here, maybe we just fail closed, just to be on the safe side.
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →