The network change that can lock a building
A tenant arrives on a cold Monday morning and taps a badge at the lobby reader. The door does not unlock. The reader is not broken, and the building has not lost power. During the weekend, a routine firewall update severed communication between the access control panels and their central server. The panels are still powered, but they cannot talk to the system that grants entry.
That scenario captures a hard-to-see risk in modern buildings: a security change can unintentionally interrupt the network connections that keep building operations running. A tool may be doing exactly what it was designed to do—protecting the network—while also blocking a connection a door controller or building system depends on.
Building operations depend on the network
Commercial buildings contain more connected systems than many people realize. HVAC, access control, elevator phones and lighting can all rely on network communications. A firewall rule may look to IT like an address and port, but to facilities it may represent the access panel for an area of the building or the link to a thermostat.
This is why the consequences of network decisions extend beyond email and file servers. When a connection is blocked, the physical system on the other side may remain present and powered, yet lose contact with its central platform. Tenants experience the result directly: a locked door, an uncomfortable temperature or another system that no longer works as expected.
Not every outage begins with a firewall rule
Firewall updates are one source of disruption, but they are not the only one discussed in the episode. Building systems may use encrypted connections that depend on digital certificates. If a certificate expires without being renewed, the connection can drop, sometimes without a clear alarm.
Intrusion prevention systems can create another failure path. Building controllers may produce communication patterns that differ from typical office workstations. A security rule that is too aggressive—or that treats unfamiliar but legitimate traffic as suspicious—can block the controller. The building system may not have a way to notify anyone that its connection has been stopped.
These failures can remain quiet until someone notices an operational effect. Facilities may see temperatures drifting or people unable to enter, while IT may not immediately realize that a security control is the cause. The time between a network change and an obvious symptom makes coordination especially important.
Different responsibilities, shared outcomes
IT and facilities often work in separate lanes because their mandates differ. IT is responsible for security and data integrity. Facilities is responsible for uptime and occupant comfort. Both responsibilities matter, but a change made without operational review can pit them against each other after a failure.
Facilities staff may understand the building and its equipment without knowing the network details. IT staff may understand the rule or policy without knowing which physical systems depend on it. The episode describes the need for a translator: a reliable way to connect the technical change with the building impact.
Create a practical change checkpoint
A formal change advisory board can provide that checkpoint, even if it includes only two or three people. The important part is that someone from facilities reviews network changes that could affect building systems. Facilities does not need to approve every technical detail; it needs to know which systems may be affected and when the change is planned.
The process should also make it possible to raise timing concerns. If a critical building event is scheduled, operations may need to ask whether a change can wait. Not every organization has the capacity for another standing meeting, and the discussion recognizes that. A designated liaison or documented email chain can work as an alternative, provided the process is recorded and someone is accountable.
The aim is not bureaucracy. It is a brief, repeatable question before implementation: what building systems rely on the connection being changed, and is this a suitable time to make the change?
Document what is connected to what
Facilities teams can make that review faster by documenting their systems and dependencies. A full network diagram may not be necessary. Start with enough information to know which controllers are on which network segments and which servers they depend on.
That shared map helps turn a broad IT change into a specific operational assessment. If a team can identify that a rule affects an access control panel or a building controller, it can discuss timing and impact before the connection is interrupted. Documentation is not just reference material; it is an early warning system for change review.
Make alerts reach the people who can respond
Even disciplined planning cannot prevent every problem. Building automation systems should be able to report when a controller goes offline, and those alerts should reach both facilities and IT. A notification that goes to a monitoring station nobody watches—or to a pager left on a desk—does not provide a useful response path.
Teams should agree who receives alerts and how escalation works. That gives facilities a chance to respond to building symptoms while IT investigates network causes, instead of leaving either group to work from incomplete information.
Testing is just as important. Schedule a network resilience drill that simulates a failure and observe whether systems respond as expected. Check whether alerts arrive, whether the right people receive them, and whether the teams know what to do. Fire and security drills test other forms of readiness; a network resilience drill can expose similar gaps before a real outage does.
Handle necessary exceptions with ownership
Some building systems may need communication that conflicts with a security policy. Simply opening the firewall and leaving the rule in place is not a safe long-term answer. Document the reason for the exception, assign a risk owner and review it periodically—perhaps every quarter—to confirm it is still needed.
Where feasible, update the system so it can operate within the security policy. If an exception remains necessary, make it visible and temporary. Network segmentation or a different authentication method may help reduce exposure while preserving the communication the building system requires. Facilities also needs to understand that an exception is not a free pass; the system still needs appropriate protection.
Three steps to take now
The episode closes with three practical recommendations. First, start the conversation between facilities and IT. Facilities can ask how upcoming network changes will be checked against building systems, and IT can invite operations into planning.
Second, document connected systems and their dependencies. A concise inventory can help teams recognize what may be affected before a change goes live.
Third, establish a formal change-management process. It can be a simple checklist and a regular review rather than a complex committee. The essential requirement is that someone asks what could break if a connection goes down.
Security and uptime are not opposing goals. When IT and facilities share information, review changes together, monitor the right systems and test resilience, they can protect the network without losing sight of the building it supports. For more practical discussion of connected buildings and infrastructure, listen to the episode.