Fire alarm networks, cybersecurity and remote access

Eastview's information technology department has asked for a meeting. Tomasz Wilk, the hospital's network security analyst, wants to know every device on the fire alarm system that has a network address, who can reach it, and how. 'We had an audit,' he says. 'The auditor found a fire alarm workstation on the general hospital network with the maker's default password. Nobody in IT knew it was there.' Ravi and Sasha spend the morning building the list. This lesson covers how fire alarm systems connect to networks, the risks that brings, and the defensive practices that keep a fire alarm system working and under the owner's control.

Why this has become a fire alarm issue

Older fire alarm systems were closed: proprietary wiring, no outside connections except a telephone dialer, and programming only with a laptop plugged into the panel. Modern systems use IP communicators, graphic workstations on office networks, remote diagnostic connections for the service company, gateways to building automation, and programming software that can sometimes reach a panel over a network. Each connection is useful. Each is also a way for an unauthorized person, or a careless one, to change or disable the system, and a way for a problem on another network, such as malware or a misconfigured switch, to reach it.

The aim of cybersecurity for a fire alarm system is simple: the system must keep doing its job, its program must be changed only by authorized people through controlled means, and its signals must reach the people who need them. The technician's part is mostly good practice applied consistently, not specialist knowledge.

What the codes now say

Canadian standards are beginning to address network-connected fire alarm equipment, and CAN/ULC-S561 includes requirements for remote access to the signal receiving centre's automation system. In practice, owners like Eastview set their own requirements through their IT policies, and Bramwell follows the manufacturer's guidance and the approach in NFPA 72's cybersecurity chapter, which many designers in Canada now use as a reference even where it isn't adopted.

Whatever the code says, the practices below are what Bramwell applies on every networked system.

Know what is connected

The first step is an inventory: every node, workstation, gateway, communicator, network card and programming connection, with its address, its network, what it talks to and why. Eastview's list, when Ravi and Sasha finish it, has 31 entries, including two they didn't expect: a second graphic workstation in the facilities office, installed years ago by another contractor, and a remote diagnostic modem in the central plant node that nobody had used since a warranty period ended.

# A connected-device inventory: flag the entries that need action
devices = [
    ("node main", "fire network", "none", "n/a", True),
    ("graphic workstation security", "fire network", "local accounts", "named", True),
    ("graphic workstation facilities", "hospital office LAN", "local accounts", "default", False),
    ("IP communicator", "isolated VLAN", "outbound only", "n/a", True),
    ("BAS gateway", "fire network + BAS", "one-way", "named", True),
    ("diagnostic modem plant", "telephone line", "dial-in", "default", False),
]
for name, net, access, creds, documented in devices:
    issues = []
    if creds == "default": issues.append("change default password")
    if "office" in net: issues.append("move off general network")
    if access == "dial-in": issues.append("remove or disable unused remote access")
    if not documented: issues.append("add to records")
    print(f"{name:31s} {'; '.join(issues) if issues else 'ok'}")

node main                       ok
graphic workstation security    ok
graphic workstation facilities  change default password; move off general network; add to records
IP communicator                 ok
BAS gateway                     ok
diagnostic modem plant          change default password; remove or disable unused remote access; add to records

Separate the networks

Fire alarm equipment that must use a network should be on a network of its own, or on a segment of the owner's network that is separated from general traffic, such as a dedicated virtual network with a firewall controlling what can enter and leave it. A graphic workstation used by security officers belongs on that protected segment, not on the hospital's office network where anyone's laptop can reach it. Where the fire alarm must share information with another system, the connection goes through a listed gateway, ideally one that sends information out and accepts nothing in, or accepts only specific, documented commands.

Communicators that use the internet make outbound connections to the monitoring centre's receiver. The firewall allows that outbound connection to the receiver's address and port, and nothing inbound. If the owner's IT department wants to change firewall rules, network addresses or switches, the change must go through a process that includes the fire alarm company and the monitoring centre, because a broken rule silently stops the fire alarm's signals.

Control who can change the system

• Change every default password, and use named accounts so that changes can be traced to a person.
• Give each person only the access they need: security officers may acknowledge and silence, but not change programs.
• Remove or disable remote access that isn't needed, and for remote access that is needed, use the manufacturer's secure method, require the owner's approval for each session, and log it.
• Keep programming laptops and software under control: up to date, scanned for malware, and used only by trained technicians.
• Install only manufacturer firmware and programs obtained from the manufacturer's official source, and record the versions.

Physical security matters too. A locked panel and a locked network cabinet stop casual tampering, and network cable for fire alarm equipment in public areas is better protected in conduit or armoured cable.

# Review a workstation's accounts against least privilege
accounts = {"security1": {"acknowledge", "silence"}, "security2": {"acknowledge", "silence", "program"},
            "facilities": {"acknowledge"}, "admin": {"acknowledge", "silence", "reset", "program"}}
allowed = {"security1": {"acknowledge", "silence", "reset"}, "security2": {"acknowledge", "silence", "reset"},
           "facilities": {"acknowledge"}, "admin": {"acknowledge", "silence", "reset", "program"}}
for user, rights in accounts.items():
    extra = rights - allowed[user]
    print(f"{user:10s} {'remove ' + ', '.join(sorted(extra)) if extra else 'ok'}")

security1  ok
security2  remove program
facilities ok
admin      ok

Keep the system working when the network misbehaves

A fire alarm system must keep detecting and warning even if every network connection fails. That is why nodes work on their own, why the annunciator at the entrance is connected over the fire alarm's own network rather than the building's, and why the loss of a communicator's internet path is reported as a trouble rather than ignored. During testing, Bramwell confirms that disconnecting the gateway, the workstation and the internet path causes troubles where it should and stops nothing else.

Records are part of the defence. The system documents list every network connection, address, gateway and remote access method, and who approved it. When something changes, the records change.

What the technician should not do

Cybersecurity work on fire alarms is defensive and done with the owner's authority. A technician who finds a weakness, such as an exposed workstation or a default password, reports it to the owner and fixes it as agreed. Testing the owner's network, scanning other systems or trying to get into equipment is not the fire alarm technician's job and is not done without explicit written authorization from the owner, normally by specialists the owner engages.

Change control for fire alarm programs and networks

Most problems with networked fire alarm systems don't come from attackers. They come from changes made without the people who need to know being told: an IT technician who replaces a switch, a controls contractor who reprograms a gateway, a service technician from another company who loads an old program. A simple change control process prevents most of them. Before a change to anything the fire alarm depends on, the person making it describes what will change, the fire alarm company confirms whether the fire alarm is affected, the monitoring centre is told if signals may be interrupted, and afterwards the affected functions are tested and the records updated.

# A change request checked against what the fire alarm depends on (illustrative)
change = {"what": "replace core switch, comms room B", "systems touched": {"switch B1", "firewall policy 7"}}
depends = {"IP communicator": {"switch B1", "firewall policy 7"}, "security workstation": {"switch B2"},
           "BAS gateway": {"switch C4"}}
affected = [d for d, needs in depends.items() if needs & change["systems touched"]]
print("change:", change["what"])
print("fire alarm items affected:", affected or "none")
if affected:
    print("required: notify fire alarm company and monitoring centre, test IP path after change")

change: replace core switch, comms room B
fire alarm items affected: ['IP communicator']
required: notify fire alarm company and monitoring centre, test IP path after change

At Eastview, Tomasz agrees to add the fire alarm's network items to the hospital's configuration records, so that IT's own change tool flags any change that touches them.

Software, laptops and updates

Programming software and laptops are part of the risk. A technician's laptop that has been on many networks can carry malware into a panel's programming port, and an unauthorized copy of programming software, or a program file from an unknown source, can load an incorrect program. Bramwell keeps its programming laptops for service work only, updates and scans them, and stores each building's program in a controlled location with its version and date. Firmware updates from the manufacturer are installed when the manufacturer recommends them, after reading the release notes, and every function the update could affect is tested afterwards.

Updates are a balance. An update may fix a security weakness, but it also changes the software that runs a life safety system. The owner, the designer and the service company decide together when to install it, and the update is treated as a change to the system: planned, recorded, tested and, where the authority requires it, reported.

Responding to a problem

If the technician finds signs that a fire alarm system has been changed by someone unauthorized, such as a program that differs from the recorded version with no record of why, an unknown device on the fire alarm network, or remote access sessions nobody approved, the first priorities are the same as for any fault: make sure the system still works, tell the owner, and record what was found. The owner's IT and security staff then decide how to investigate. The technician helps by restoring the recorded program, testing the system fully, and keeping the evidence the owner's investigators may need, such as the panel's event log, before anything is cleared.

# Compare the running program with the recorded version before clearing anything
recorded = {"version": "2026.04b", "date": "2026-04-14", "checksum": "C41E"}
running = {"version": "2026.04b", "date": "2026-06-02", "checksum": "77A0"}
changed = [k for k in recorded if recorded[k] != running[k]]
print("program differs in:", changed if changed else "nothing")
if changed:
    print("save the event log, tell the owner, then restore the recorded program and test every function")

program differs in: ['date', 'checksum']
save the event log, tell the owner, then restore the recorded program and test every function

None of this requires the technician to be a network security specialist. It requires knowing what is connected, keeping it separate and controlled, recording it, and testing it, which are habits every fire alarm technician already has for the rest of the system.

Bramwell's own office is part of the picture too. Its records of passwords, program files and network details for client buildings are protected, shared only with the technicians who need them, and never sent by ordinary email.