A building’s Emergency Responder Communication Enhancement System (ERCES) is designed to keep first responders connected when concrete, steel, low-E glass, and below-grade construction interfere with radio signals. But as these systems become network-connected, another risk requires attention: cybersecurity.

A BDA, fire alarm control unit (FACU), or ERCES monitoring gateway may now connect to a corporate LAN, internet service, cloud platform, or remote service interface. That connectivity can improve visibility and maintenance: but it can also create an attack path into life-safety equipment if it is not properly secured.

The 2025 edition of NFPA 72, National Fire Alarm and Signaling Code, significantly expands cybersecurity provisions in Chapter 11. Previous editions introduced cybersecurity expectations and related guidance. The 2025 edition moves much of that guidance into mandatory code requirements for applicable network-connected fire alarm and signaling systems.

The result: cybersecurity is no longer only an IT concern. For building owners, facility managers, fire alarm contractors, ERCES providers, and Authorities Having Jurisdiction (AHJs), it is now part of responsible life-safety system design, commissioning, maintenance, and documentation.

Important: NFPA 72-2025 is not automatically enforceable in every jurisdiction. Requirements depend on the edition adopted by the local AHJ, applicable laws, project specifications, equipment listing, and the system’s actual connectivity. Confirm the governing requirements with the AHJ and the equipment manufacturer before making compliance decisions.

When NFPA 72-2025 Chapter 11 Applies

Chapter 11 is most relevant when a fire alarm or signaling system includes network-connectable equipment or uploadable software configurations.

That may include:

• IP-connected FACUs and annunciators
• Cloud-connected fire alarm monitoring platforms
• Remote service or programming interfaces
• Network-connected ERCES or BDA monitoring equipment
• Gateways that transmit supervisory signals to another system
• Building automation or enterprise network connections
• Service laptops or software tools used to change system configuration

A conventional, isolated system with no network-connectable equipment and no uploadable software configuration may not require the same cybersecurity level. However, that determination should not be made by assumption. A system that appears isolated today may become network-connected during a future service visit, monitoring upgrade, tenant improvement, or IT infrastructure change.

For that reason, cybersecurity scope should be established during design: not after installation.

The ERCES Cybersecurity Blind Spot

Many facility teams understand the RF side of an ERCES project:

• Donor antenna performance
• BDA gain and isolation
• Distributed antenna placement
• Signal strength and Delivered Audio Quality (DAQ)
• Battery backup
• Fire-rated pathways
• FACP supervisory inputs

The network side is easier to overlook.

A network-connected ERCES may provide remote status, alarm notification, configuration access, or maintenance diagnostics. If the interface uses weak credentials, an exposed port, shared network access, or outdated firmware, the equipment may be vulnerable to unauthorized access or disruption.

This does not mean every ERCES must be connected to the internet. In many cases, the safest design may be to limit or eliminate unnecessary connectivity. When connectivity is required, it should be engineered as part of the life-safety system: not added informally by connecting a device to the nearest available switch port.

NFPA 72-2025 cybersecurity considerations should be coordinated with NFPA 1225, the International Fire Code (IFC) Section 510, manufacturer requirements, and local amendments. NFPA 72 addresses fire alarm and signaling system interfaces, supervision, and cybersecurity controls; NFPA 1225 addresses emergency services communications and ERCES performance. The AHJ determines how those requirements are applied to a specific project.

1. Control Remote Access Before It Controls You

Remote access can help qualified technicians identify faults, review system status, and reduce service delays. Uncontrolled remote access can undermine the integrity of a life-safety system.

A secure remote-access design should address:

• Encrypted connections: Use approved secure channels such as a properly configured VPN or encrypted manufacturer platform.
• Firewall protection: External connections should pass through a gateway or firewall that restricts traffic to trusted, necessary services.
• Authentication: Require unique, authorized accounts rather than shared technician logins.
• Role-based permissions: A user who needs to view status may not need permission to reset, silence, upload programming, or change system parameters.
• Session controls: Apply appropriate timeout and disconnection policies.
• Audit logging: Record login attempts, configuration changes, resets, updates, and other security-relevant events.
• On-site coordination: Define when a qualified person must be physically present during remote service or configuration activity.
• Emergency access termination: Establish a method for facility personnel to disable or suspend remote connectivity when necessary.

Remote access should be treated as a controlled exception: not a permanent open door.

2. Replace Default Credentials and Manage Accounts

Default usernames and passwords are among the most preventable cybersecurity weaknesses in connected equipment. Manufacturer credentials should not remain active after commissioning.

Your account-control process should include:

1. Change default passwords before the system is placed into service.
2. Assign unique credentials to each authorized user.
3. Separate administrator, service, operator, and read-only roles.
4. Disable unused accounts and unused services.
5. Remove or revoke access promptly when employees, vendors, or contractors leave or change responsibilities.
6. Review authorized users periodically.
7. Store credentials according to the facility’s security policy.
8. Document who is permitted to access the FACU, ERCES controller, BDA monitoring platform, and related gateways.

This is both a cybersecurity issue and an accountability issue. If an unauthorized configuration change affects system availability, the facility should be able to identify who had access, what changed, and when the change occurred.

0% Unknown Accounts. 0% Uncontrolled Access.

3. Segment Life-Safety Traffic From Corporate IT

A public safety DAS or ERCES monitoring device should not automatically share unrestricted access with employee workstations, guest Wi-Fi, tenant networks, or general building automation systems.

The appropriate architecture depends on the assigned security level, equipment capabilities, project design, and AHJ direction. Potential controls may include:

• Dedicated network segments
• Virtual LANs (VLANs)
• Access control lists (ACLs)
• Restricted switch ports
• Firewall rules
• Dedicated pathways
• Physical separation of life-safety equipment
• Controlled gateways between systems
• Prohibition of unnecessary inbound connections

NFPA 72-2025 introduces security levels that generally increase the separation and protection expected for life-safety data and pathways. At lower levels, life-safety traffic may be prioritized. At higher levels, it may require logical segregation or dedicated equipment and pathways.

The important point is not to select a security level casually. The design team should document:

• The selected security level
• The reason for its selection
• The network architecture
• The equipment and pathways involved
• The firewall or gateway controls
• Any shared infrastructure
• The party responsible for maintaining the controls

4. Plan Firmware, Software, and Security Updates

Cybersecurity is not a one-time commissioning activity. Firmware vulnerabilities, operating-system changes, vendor advisories, and network modifications can affect a system long after the Certificate of Occupancy is issued.

A facility’s maintenance plan should define:

• Who receives manufacturer security advisories
• How firmware and software updates are evaluated
• Who approves updates
• Whether updates require AHJ notification or approval
• How backups are created before a configuration change
• How compatibility is confirmed
• How the system is returned to service
• What testing is completed after the update
• How the change is recorded

Updates must not reduce the system’s required cybersecurity posture or interfere with life-safety functionality. A patch should never be installed without considering alarm reporting, ERCES supervisory signals, remote monitoring, backup power, and FACP integration.

Annual maintenance should also verify whether network connectivity, security controls, equipment certification, or system ownership has changed since the previous inspection.

5. Document the Cybersecurity Acceptance Package

If the information is not documented, it may be difficult to demonstrate compliance during an inspection, renovation, audit, or incident investigation.

A practical cybersecurity acceptance package may include:

• Network topology diagrams
• ERCES and FACU equipment inventories
• Manufacturer data sheets and listings
• Security-level assignment and rationale
• Firewall and gateway details
• Remote-access procedures
• Account and credential-management procedures
• Firmware and software update procedures
• Backup and recovery procedures
• Incident-response contacts
• Access and configuration-change logs
• Commissioning and acceptance-test results
• Annual verification records
• AHJ and manufacturer correspondence

The package should be controlled and updated when the system changes. Tenant network modifications, managed-service-provider changes, equipment replacement, and remote-monitoring upgrades can all affect the original cybersecurity design.

Adopted Code, Guidance, and Professional Confirmation

NFPA publications are consensus standards, but their enforceability depends on adoption and local application. A provision may be:

• Enforceable because the jurisdiction adopted NFPA 72-2025
• Required by a project specification or contract
• Required by the manufacturer’s listing or instructions
• Enforced through a local amendment
• Recommended guidance when the 2025 edition has not been adopted

Building owners should not rely on a generic checklist as a substitute for project-specific review. Confirm the applicable NFPA edition, IFC edition, NFPA 1225 requirements, local amendments, equipment listing, and AHJ expectations.

The safest approach is coordinated review among:

• The building owner or facility manager
• The AHJ or fire marshal
• The fire alarm contractor
• The ERCES/PDA DAS designer and installer
• The manufacturer
• The facility’s IT or cybersecurity team
• The monitoring provider

Protect the Signal: and the System Behind It

Reliable indoor radio coverage is essential, but signal availability is only one part of public safety communications. A network-connected ERCES must also be designed, accessed, updated, and documented responsibly.

Global Network LLC specializes in Public Safety DAS, ERCES, BDA technology, compliance testing, and system integration. As Atlanta’s local DAS/ERCES specialist, we help building owners and facility managers coordinate technical requirements across IFC 510, NFPA 72, NFPA 1225, FirstNet compatibility, and local AHJ expectations.

From design and iBwave engineering through commissioning, acceptance testing, annual certification, and ongoing service, the objective is straightforward:

0% Defects. 0% Missed Deadlines. Reliable communication when it matters most.

Request a review of your network-connected fire alarm or ERCES monitoring equipment before the next inspection, renovation, or system upgrade.

• Office: 770.520.7633
• Toll Free: 877.231.1084
• Website: globalnetworkco.com
• Services: Public Safety DAS and ERCES Services
• Compliance Resource: IFC 510 and NFPA 72 Compliance
• Contact: Request a Compliance Consultation

Secure the network. Supervise the system. Protect the people who protect your building.