Lockdown Buttons In A IP Access Control System

We generally design lockdown systems so that they are completely independent of the access control system controller and software. This requires hardwiring between the lockdown buttons and each of the doors. When the lockdown button is pressed, the doors are locked and the card readers are disabled regardless of the status of the controller or software.

You are right in that nothing can be done at the software level to override the lockdown button system. This is normally considered to be a benefit rather than a problem, but if you did want a software override, you could accomplish it by using an SPDT auxiliary output relay on the controller wired in conjunction with a SPDT lockdown switch. This would be connected just like a three-way switch used to control lights. With this arrangement, you could issue a software command to operate the auxiliary relay that would override the lockdown switch. Conversely, if the lockdown switch was bypassed by software, it could be flipped in the other direction in order to relock the doors.

Hey Andrew: Great question! Unlike you or Mr. Silva, I commonly used a software-based lockdown command. This might take some explanation to the customer, but once it was broken down, most accepted the solution vs. the manual (absolute) lockdown method you describe:

1. Typically, Access Control systems 'unlock' doors, not lock them. Unless configured in a non-standard manner, the default configuration of a door is 'locked' until a user presents a credential to 'unlock' the door. This is important to visualize, because a locked door is the default status - "locked" is the standard state.

2. A 'lockdown" command typically disables or prevents the readers from accepting normal credential inputs. "Lockdown" commands default the door to a "non-unlocked" state. It sounds like a double negative, but lockdown commands override schedules keeping the door unlocked. (Instead of electrically dogging open the door, lockdown defaults the door to standard state.) In my experience, lockdown just keeps people from reading into a door - life safety (egress) must always be observed. (Although special cases or exemptions like non-egress doors, jails, mantraps, or sally ports are out there.)

3. Is your experience with 'host-bound' systems? The reason I'm curious - most systems do not require constant communication between the door controller and the main control panel. Most commercial grade systems push updates to door controllers as needed, but the door controller itself is responsible for controlling the door. Your experience may be through an alarm panel based system?

Unless the connectivity between a door and panel is broken when the 'lockdown' command is issued, it will continue in lockdown state even if the network is unreliable. If the network is so flaky to prevent that, it probably is an issue already.

A question for you, Mr. Silva, or others: is there a lockdown requirement somewhere that requires the manual power interruption (absolute) method you describe?

Brian, I know of no code or regulatory requirement to provide the hardwired (absolute) type lockdown that I described, but over the years, I have found it to be the most reliable.

As the designer, you have no control over what state the door may be in during the rare occasion when a emergency lockdown may be required. The door may already be in a locked state, or may be in an unlocked state because of a preprogrammed schedule or a manual unlock command entered by the system operator. Regardless of what state the door is in, I want it to lock to prevent people from entering the building, even if they have a valid access card. As you correctly indicate, nothing is being done to prevent people from exiting. (This creates another problem: the potential for a bad guy to enter as people exit, which I try to solve using other methods.)

If the lockdown button is wired to the same controller as the all of the doors that you wish to lock, it is usually not necessary for the controller to communicate with the host (server). However, if the button input is on one controller, and the lock outputs are on others, communications up to the host and back must occur under most system architectures. (There are a few system architectures that allow communications to occur "peer-to-peer" between controllers, but these were rare the last time I looked.) So if network communications is lost, the signal to lock the doors may not get transmitted to all controllers, and all doors may not lock.

Using the software based method also usually requires an association be made in software between the input (lockdown button) and the outputs (doors that you wish to lock). This is something that is usually done by the installing technician at the time of installation but which may not be understood at a later date by the end-user or other techs servicing the system. In more cases than I care to mention, I have seen a well-intentioned end-user or tech "clean-up" the programming by removing programming sequences that they didn't understand. The only time that a problem becomes obvious is when the user presses the button and the expected actions do not occur.

So, while the software based method can work well under the right circumstances, I prefer to use the hardwired method for maximum reliability.

Michael, thanks for the insightful analysis. One question, you note, "This requires hardwiring between the lockdown buttons and each of the doors." That strikes me as being fairly expensive / involved if you have lots of doors across a campus? Is that the case or am I overestimating it?

John,

I was speaking figuratively and should have said "hardwiring between the lockdown buttons and each of the controllers". Most installers still tend to cluster controllers and power supplies together in electrical or telephone closets rather than put them out at the doors. so cabling for the lockdown buttons is run between controller locations.

In a corporate or healthcare setting, we typically configure lockdown buttons on a building by building basis rather than a campus wide basis. A typical configuration would be a panic/lockdown button at the receptionist's desk in the lobby that would lock down all the perimeter doors of that specific building. Other buildings on campus would be notified of the event and make their own decision as to whether or not they needed to lock their own doors.

That being said, I have designed systems where every building on campus locked-down when the lockdown button at any building was pressed. This did require running cabling between buildings, and yes this can be expensive and involved in some cases. But keep in mind that, up until fairly recently, running hardwired cabling for security/surveillance campus wide was the norm rather than the exception, and adding another cable to the bundle for lockdown was no big deal.

You kids and your IP...:)

Ha, thanks, spoiled :)

Hi Michael and Brian,

I want to thank you for your response.

Brian:

Regarding free egress - yes, that is made available on all the doors that we worked on.
Regarding the access control system - we are using a non-mercury board system. The connections between the panels (or the controllers) are achieved through the network. There is no analog connectivity between the different controllers. The only 'analog' connections exist between the panel and the edge hardware (e.g., input device, output device, reader). Here is a simple diagram that I hope will translate well when I submit this post:

Server ---(network cable)--- controller 1 ---(a bundle of 18/4 wires and 22/6 wire)--- reader, DPS, REX, lock, other input/output |
--------(network cable)--- controller 2 ---(a bundle of 18/4 wires and 22/6 wire)--- reader, DPS, REX, lock, other input/output

I guess this would equate to a host bound system as you mentioned. The issue here is that all the processing is done at the server level. The controller has some intelligence, but not enough to execute a software system lockdown from a physical button without the connection to the server. This is true even if the button and the lock are connected to the same controller.

What I found is that my end users' networks are generally reliable. However, I am preparing for the worst in case a downtime occurs suddenly and a lockdown must be achieved. Not that doing it software wise is a lesser of a solution, but I find that setup to be ineffective at times like this. I don't know if I am overcomplicating my design or not with this setup, but I want the assurance that the building can be locked down whenever that button is pressed.

I guess you can say that I believe in IP solutions but I still think hold an appreciation of analog setups :)

Michael:

Thanks for your analysis and comments, they are very helpful.

Regarding the system programming - I guess I am also an IP kid that is spoiled ;)
I am saying this because there is a nice GUI that allows me to tie doors to locations (which I can make into buildings or zones within a building) and that allows me to selectively tie a button to that zone or location. Programming the software is fairly easy although there are many steps to follow.

You mentioned "the potential for a bad guy to enter as people exit, which I try to solve using other methods." Would you mind providing some insights on the methods that you use to prevent this from happening?

A notification system needs to be provided in conjunction with the lockdown system. Typically, we provide some type of indicator light located near the inside of each exit door. This light activates/flashes when the building is in lockdown mode and building occupants are instructed not to exit the building. I also sometimes use digital voice messaging systems to broadcast a message over the overhead paging system when the building goes into lockdown.

The key to success is having good procedures and training for building occupants and frequent drills to practice what should be done in an emergency. Without these elements in place, a lockdown system is practically worthless.

Michael, I appreciate your comments on the topic. It will be helpful for our next lockdown system setup.

Andrew,

Keep in mind that the most basic access control system is comprised of keys and mechanical locks. I never recommend that the mechanical means of locking a door be disabled when installing electronic access control. This is the first building block of a security plan.

If your EAC system design is such that the door controllers are not host bound, then I would not hesitate to use a software driven lockdown. This will be much less expensive and far easier to troubleshoot in case of a failure. In the case of a catastrophic network failure prior to the lock down command remind your client that someone somewhere has a key. Hopefully the doors were locked mechanically due to the network failure, prior to the lockdown being required.

It is necessary that you stress to your clients installing EAC that part of their preparedness plan is to manually lock the doors in case of catastrophic network failure or extended power outage. This would apply regardless of how you choose to implement a lockdown system.

Hi Mike,

Thanks for you comments. I find some challenges in applying your recommendations to our past designs for the following reasons:

• The electronic locks are fail-secure, so in the event of power loss, all doors will lock. But if there is an unlock that is based on a time schedule and network connectivity is lost (and no hardwired button to the power supply is present), there is no way to lock the doors other than killing the power to the electronic locks.
• If doors have electrified strikes and/or exit device with ELR on them, no matter what you do, you cannot secure them.

Keys can still bypass the lock on the doors, but it is not possible to use those keys to lock the door. The only I see this as possible is by having a redundant mechanical lock such as a deadbolt.

What is the way you would go about installing EAC but still enabling the mechanical means to lock a door?

OK...a couple of comments...

• The electronic locks are fail-secure, so in the event of power loss, all doors will lock. But if there is an unlock that is based on a time schedule and network connectivity is lost (and no hardwired button to the power supply is present), there is no way to lock the doors other than killing the power to the electronic locks.

First, I thought you were in the design stage. Not all locks are fail-secure. If you use magnetic locks they are not fail secure. In the case of ELR and electric strikes, the way to insure they remain locked (and what EAC does to insure it) is to remove power. The eac system will do this on command, such as the lock down command or "all secure" in most systems. As for the time schedule being dependent on the network, if it is then it is host bound. Host bound systems are the least dependable available. If you are host bound, then woefully the hardwired option is the best and hopefully you only have one building with a few devices.

• If doors have electrified strikes and/or exit device with ELR on them, no matter what you do, you cannot secure them.

If doors have electrified strikes and/or exit device with ELR they are secure no matter what the system failure. The only exception would be a strike that was wired to be fail safe........very rare. In 34 years of locking doors and designing ways to lock doors I have only seen one instance where a fail safe strike was required and that was in a rather obscure government facility.

Keys can still bypass the lock on the doors, but it is not possible to use those keys to lock the door. The only I see this as possible is by having a redundant mechanical lock such as a deadbolt.

Why can't you use the keys to lock the doors? You are saying you have locking devices that the keys will unlock but cannot be locked by keys? Sorry if I seem dumbfounded but that's what I am.

What is the way you would go about installing EAC but still enabling the mechanical means to lock a door?

Why would you disable the mechanical means? In the case of electric strikes you can leave the locks in a secure state always. Exit devices with ELR are also un-dogged and thus in a secure state always. Only in the case of mag locks would you leave the mechanical lock unlocked in a normal state and be required to go to the door with a key if the power to the locks was lost.

Hi Mike, Here are my answers to your questions:

"First, I thought you were in the design stage. Not all locks are fail-secure. If you use magnetic locks they are not fail secure. In the case of ELR and electric strikes, the way to insure they remain locked (and what EAC does to insure it) is to remove power. The eac system will do this on command, such as the lock down command or "all secure" in most systems. As for the time schedule being dependent on the network, if it is then it is host bound. Host bound systems are the least dependable available. If you are host bound, then woefully the hardwired option is the best and hopefully you only have one building with a few devices."

There were EAC systems that were designed by our company or those designed by others that have already been put into place that have the above mentioned design. And yes, the most common system we sell is the host bound. That is why I was thinking of going the hardwired way for future designs. And you are correct about the mag locks. We do not use those often in our deployment. But in the case that we do, I believe we leave the existing vertical rod devices in. This is the exception where the mechanical locking mechanism is not affected.

"If doors have electrified strikes and/or exit device with ELR they are secure no matter what the system failure. The only exception would be a strike that was wired to be fail safe........very rare. In 34 years of locking doors and designing ways to lock doors I have only seen one instance where a fail safe strike was required and that was in a rather obscure government facility."

Yes, they are all fail-secure. However, with the host-bound system, the doors will only secure if they lose power, the EAC panel goes down, or they are told to lock down. If the EAC panel is up and running and network connectivity is lost, there is no way to lock them other than killing power or a hardwired button. For example, if the strike is energized and stays energized, no matter what I do to the door lock (mortise, cylindrical, or rim exit device), I cannot secure the door because the strike still allow the door to be opened. So only when power is lost to the strike and/or the panel, will the door lock again.

"Why can't you use the keys to lock the doors? You are saying you have locking devices that the keys will unlock but cannot be locked by keys? Sorry if I seem dumbfounded but that's what I am.

Why would you disable the mechanical means? In the case of electric strikes you can leave the locks in a secure state always. Exit devices with ELR are also un-dogged and thus in a secure state always. Only in the case of mag locks would you leave the mechanical lock unlocked in a normal state and be required to go to the door with a key if the power to the locks was lost."

I will use the strike as an example. The locks are always secured, but the strike is controlled by the EAC. Therefore, the door opening is now controlled by EAC. So when the strike is energized, the only way to secure the opening is by killing power to the strike. Using a key will not secure the opening because it only locks and unlocks the door lock, but not the strike. Does this make sense?

I am not disbaling the mechanical means, I am leaving it in-tact. However, due to the nature of the electrification, mechanical means to lock a door is substituted by the electrification. Hope this helps.

Andrew, I think you need to get your head around the actual means by which an EAC system works. The EAC system actually only unlocks the doors it doesn't lock them.

You are concerned about what happens when the system fails and in most cases that is the least of your concerns...especially in a host bound system. If your locks are fail secure and the network fails for any reason, your building is secured.

So we worry about the bad guys disrupting our infrastructure and making our EAC system inoperable prior to an attack of some other kind but in your case with a host bound system, the bad guy has locked himself out of every door with a fail secure locking mechanism.

Hi Mike, thanks for the clarification. It helps my understanding of the whole purpose of an EAC. I will do more research on the EAC that we sell and see what it does.

Thanks.

Hi team,

I know this is a legacy post but, how do you handle fire alarm integration and lockdowns?

If bad guy pulls fire alarm, doors fail safe?

Or, doors only will fail safe if on an egress path? Otherwise doors will fail secure but allow exit?

And, per fire code, can you lockdown an egress path when not in a fire condition? e.g. horizontal evacuation for severe weather etc.

Thank you!

Nick

Hey Jason:

If there is a physical panic switch that will initiate a campus-wide lockdown, the constraint to a mag-lock controlled door should be only that the reader will no longer grant an access, but the mag-lock should still be engaged?

I believe keeping the maglock locked is allowed by code (specifically, not against code), but it might not be workable for the AHJs.

Example: Texas Shooting: "Secure Doors Kept Police Out" Says Washington Post might be an emerging trend against keeping maglocks energized unless there is some outward-facing form of override/Knoxbox switch that allows agencies to override lock downs on specific doors.