follow up to NFPA, passwords for fire alarms and release
NFPA 72, 2013, Section 220.127.116.11 requires that all fire alarm systems be protected from unauthorized changes to the program. While the Code doesn’t state you have to put a passcode in the program, it is basically the only way to protect it from Joe Maintenance (or Joe’s TV Repair & Fire Alarm Service Co) from dumping the program or otherwise making changes that effectively leaves the building unprotected.
We never leave the default passcode in the program – always a unique code. This way we know that only my company could have made a change. If a third party makes a change to the program using the default Code that causes a loss how would you prove the third party liable and not the installer?
We run into a passcode release request frequently and I’ve asked you to draft a form in the past. Examples of instances when we need a release form are as follows;
we sell a system to a customer that contracts with a National Account Vendor to monitor and maintain the system;
- a contract ends and a new vendor is selected;
- building is sold or changes management; etc.
If you do draft a standard form I would definitely be interested.
Let me know. Thanks!
You reference a NFPA section that requires the fire alarm system to be password protected. I think there is another provision that requires that the subscriber be furnished with the password [I could be wrong]. Such provision would however be directly contradicted by the contract provision that states that all passwords and programming is the property of the alarm company, only the password to be disclosed and only when the contract is over. That presumes that the alarm company will no longer be involved with the alarm system, in any way - and that means monitoring, repair service and inspection.
I see a few controversial issues here
- regarding the password, which governs, the contract terms or NFPA
- if your subscriber has the password is your exposure for liability increased
- why would a subscriber need passwords or other programming codes
- would it matter if the system is leased or sold
I am going to get some flak for this, but here it is: I view NFPA provisions as suggestions, not the law, unless of course your AHJ has adopted the NFPA version with the specific guideline. While one could argue that NFPA states ]or creates] the industry standard, I am not so sure that is true when it comes to certain provisions, such as the password disclosure. NFPA is often adopted as law for building code purposes. I don't see how passwords affect building codes as long as the end user can arm or disarm a system [which may not even apply in a fire alarm situation since it's always armed]. But if NFPA decides to address contractual provisions I'd have to consider the particular provision. It's important to keep in mind that NFPA does not have the imprimatur of law unless it's adopted by statute. Even then, a statute or building code adopted by NFPA may be worded to adopt the standards for equipment or response time, but would not necessarily adopt extraneous provisions that address contract items. So I am going to go out on a limb and say the contract terms will govern the password issue.
DIsclosing the password to the subscriber will permit access to the programming. Obviously if there is system failure you could be blamed if you are still involved with the system. Requiring the subscriber to give a general release would be the best option.
A subscriber asking for the password or access to programming is more than likely getting ready to change alarm service providers, something you're not going to like. If the contract is over then I think the subscriber should have the password, and that's what the contract calls for. That does not mean you need to turn over other programming data, that's your intellectual property. But a subscriber should be able to arm or disarm the system.
Revealing codes would be different for a leased system because that system is never owned by the subscriber and you never have to reveal the passcodes, unless you end up selling the system to the end user.