Introduction: The Hidden Dependencies Behind Connected Building Systems
Consider an illustrative case. An IT team upgrades firmware on an enterprise distribution switch outside business hours. Every switch returns to service, and the monitoring dashboard shows green. The next morning, security staff find gaps in recordings from one building wing, and the Building Management System (BMS) shows a 40-minute hole in its trend logs. Access-control events from the same wing arrived late.
The network was operational at the device level. Several critical services were still degraded. That distinction sits at the centre of the shared IT vs dedicated ELV networks decision. Extra Low Voltage (ELV) systems such as CCTV, access control, BMS and intercoms often look independent at the application layer, yet they may depend on the same switches, uplinks, routing, power, time sources, authentication services and management platforms.
Four arrangements are easy to confuse:
- Sharing physical infrastructure: Enterprise and ELV traffic use the same switches and routers.
- Separating traffic logically: VLANs, access-control rules and QoS divide traffic on shared hardware.
- Separating infrastructure physically: ELV systems use their own switches, uplinks or cabling.
- Sharing central services: DNS, DHCP, time, directory and management platforms serve both sides.
Each creates different dependencies. Ownership alone does not decide reliability. Architecture, configuration, monitoring, redundancy and recovery procedures do.
What Is a Shared IT Network in an ELV Environment?
A shared IT network is a converged architecture in which enterprise traffic and ELV applications use common physical switching or routing infrastructure, usually separated logically. Typical ELV workloads include enterprise CCTV cameras, Network Video Recorders (NVRs), Video Management Software (VMS), access control, intercoms, BMS controllers and other IP-based building systems.
The potential advantages are real: shared infrastructure, centralised monitoring, less duplicated equipment, common network administration and easier integration with enterprise services.
The obligations are equally real. A converged network needs disciplined capacity planning, change management, segmentation, cybersecurity and service prioritisation. Shared infrastructure does not always cost less. Lifecycle cost depends on design, support arrangements, redundancy, licensing and operational requirements.
What Is a Dedicated ELV Network?
A dedicated ELV network uses separate physical infrastructure, switches, uplinks or management for some or all ELV applications. The term covers several levels of separation. A site might dedicate only access switches, or add dedicated uplinks, or run a separately managed network end to end. Not every ELV subsystem needs its own independent network.
Potential benefits include tighter control over network changes, clearer operational boundaries, reduced exposure to unrelated enterprise traffic, more predictable capacity planning and clearer troubleshooting responsibility.
The trade-offs include extra infrastructure, more equipment to monitor and patch, separate maintenance routines, possibly duplicated uplinks or management systems, and added lifecycle cost.
Physical separation also leaves common risks untouched when systems still share power, equipment rooms, cable routes, upstream services or administrative access.
The Real Question: Which Systems Depend on Each Other?
Being connected to a network is not the same as depending on it for essential operation. Engineers should list, for each application, which functions need the network and which do not. Key dependencies include:
- Live CCTV viewing, recording and playback.
- Access-control decisions and centralised authentication.
- BMS monitoring and supervisory functions.
- Alarm event transmission and remote administration.
- Time synchronisation (consistent timestamps make event logs usable).
- DNS, DHCP and routing, where applicable.
- Central management servers and storage.
Local and centralised functions behave differently. An access-control door controller may continue making certain decisions locally during a network outage, provided it holds the necessary configuration and has power, while central monitoring and remote administration become unavailable. A camera with edge recording may keep recording locally while centralised recording and live viewing are interrupted.
Can ELV devices continue operating during a network outage? Some can, for some functions. The behaviour depends on the equipment, its configuration and the system architecture, so engineers should confirm it for each product rather than assume it.
For recording dependencies, the architecture of the NVR and VMS layer deserves review alongside the network design.
Shared IT vs Dedicated ELV: Operational Trade-Offs
The table describes typical possibilities, not universal outcomes. A well-engineered shared network can outperform a poorly designed dedicated one, and the reverse is also true.
| Evaluation Factor | Shared IT Network | Dedicated ELV Network | What Engineers Should Verify |
|---|---|---|---|
| Initial infrastructure | Reuses existing switching; may need upgrades | Needs additional switches, cabling, cabinets | Capacity of existing equipment; true incremental cost |
| Bandwidth and contention | Uplinks may be shared with enterprise traffic | Contention limited to ELV traffic | Measured peak utilisation on shared links |
| Fault isolation | Common core or uplink may be a shared failure domain | Enterprise faults may not reach ELV, if truly independent | Which components are actually shared |
| Cybersecurity and segmentation | Relies on VLANs, ACLs, firewalls and policy | Separation can reduce exposure, not remove it | Inter-network connections and admin access paths |
| Maintenance windows | Enterprise changes may affect ELV | ELV controls its own schedule | Change approval and notification process |
| Monitoring and troubleshooting | Common tools; more traffic to filter | Separate tools; clearer scope | Visibility into utilisation, errors and events |
| Redundancy | Can inherit enterprise resilience | Must be designed and funded separately | Independent paths, power and failover behaviour |
| Administrative ownership | Shared between IT and ELV teams | Often clearer, but may be fragmented | Written responsibilities and escalation |
| Scalability | Scales with enterprise core; may compete for capacity | Scales independently; adds equipment | Growth in cameras, doors and points |
| Recovery after outage | Depends on enterprise restoration priorities | Depends on ELV team readiness | Recovery objectives and tested procedures |
How CCTV Traffic Can Affect Other ELV Applications
Yes, CCTV traffic can affect other ELV systems when links and switches are not sized for it, but proper capacity planning, QoS and segmentation can manage the risk. Video does not inherently disrupt other traffic.
Start with realistic estimates. Camera bitrate depends on resolution, codec, frame rate, scene activity and configuration. Engineers should use measured or vendor-calculated stream rates, not the sum of advertised port speeds. A 48-camera switch with gigabit ports does not generate 48 Gbps, but its aggregate stream load still converges on the uplink. Illustratively, 48 cameras at 6 Mbps each produce roughly 288 Mbps before playback, retransmissions or other traffic.
A practical scenario: camera switches feed a single gigabit uplink toward the VMS servers. Operators open several playback streams while a scheduled backup runs over the same link. Utilisation approaches saturation, switch buffers overflow and packets drop. Operators see stuttering video, and recording gaps may follow, depending on protocol and recorder behaviour. This is oversubscription, a ratio of potential demand to available capacity, and it is a design question rather than a defect.
Other factors matter. Unicast streams multiply with each viewer, while multicast can reduce repeated streams where devices and the network support it. Packet loss damages video quality and recordings. Latency and jitter matter most for live viewing and control, less for buffered recording. Edge analytics versus server-based analytics also changes how much video crosses the network.
CCTV bandwidth and storage planning, NVR capacity and PoE (Power over Ethernet) budget planning belong in the same exercise, because switch power capacity and uplink capacity fail independently.
VLANs, QoS and Segmentation: Are They Enough?
Logical separation divides traffic on shared hardware, while physical separation uses different hardware or media. A VLAN (Virtual Local Area Network), defined in the IEEE 802.1Q bridging standard, separates Layer 2 broadcast domains. A VLAN for CCTV is a reasonable starting point, not a complete design.
Four distinctions matter:
- A VLAN does not automatically provide complete cybersecurity isolation. Traffic between VLANs passes through routing, where ACLs (Access Control Lists) and firewall policies decide what is allowed. Misconfiguration can undo the separation.
- QoS prioritises traffic but cannot create missing bandwidth. Quality of Service marking, such as the DiffServ field defined in RFC 2474, only influences queuing when links are congested.
- A dedicated physical network reduces certain dependencies but does not guarantee end-to-end resilience.
- Segmentation needs supporting controls: routing design, filtering, secure administrative access, network access control where appropriate, and monitoring of link utilisation and errors.
Logical segmentation may be sufficient where capacity is verified, change control is mature, ELV functions have local fallback, and the consequence of interruption is tolerable. Stronger physical separation deserves consideration where independence from enterprise change is required, traffic is large and predictable, or regulators, insurers or operators demand clear boundaries. Detailed VLAN segmentation for enterprise CCTV is worth documenting separately.
Single Points of Failure and Recovery Requirements
Fault-domain analysis asks which components can take down several systems at once. Candidates include core and distribution switches, uplinks, power supplies, network cabinets, routing infrastructure, authentication services, central management servers, shared cable pathways and common cooling or power.
Scenario: one distribution switch fails. CCTV viewing and BMS monitoring both depend on it, so both disappear together. The outcome could differ if critical traffic had independent paths, resilient switching, local operating capability or appropriately designed redundancy. Cameras with edge recording might keep recording. Controllers might keep operating locally. Operators would lose visibility, but not necessarily function.
Redundancy is not independence. Two uplinks sharing one cable route, one power source or one upstream switch can fail together. Resilience, the ability to keep operating or recover, should be assessed per service, because network availability and application availability are different measures.
Cybersecurity and Ownership Boundaries
When enterprise IT and ELV coexist, responsibility for changes and security policy must be explicit. The main controls are least-privilege access, segmentation, secure remote access, firmware management, device inventory, logging and monitoring, configuration backups, change control, controlled vendor access and defined incident-response roles.
NIST SP 800-82 Rev. 3, the guide to operational technology security, covers building automation among other systems and addresses segmentation, remote access and logging, making it a useful reference for ELV governance.
A dedicated ELV network still needs patching, access control, monitoring and secure configuration. Cybersecurity separation and operational separation are different goals: a network can be operationally independent yet poorly secured, or tightly secured yet operationally dependent.
How to Choose the Right Architecture for a Facility
Let the answers to these questions determine the architecture, not a blanket rule that ELV traffic must always share or always avoid the IT network:
- Which systems must remain operational during a network outage?
- Which functions can operate locally?
- What interruption period is acceptable for each service?
- What happens if CCTV viewing or recording is unavailable?
- What happens if access-control monitoring is interrupted?
- Does the BMS need continuous connectivity for specific supervisory functions?
- How much traffic will each application generate?
- Which services or components are shared?
- Who approves network changes?
- What redundancy and recovery are required?
- Which cybersecurity controls are necessary?
- What are the total lifecycle costs?
A Practical Operational Dependency Checklist
How should engineers evaluate network dependencies? Map every ELV function to the components it needs, then test the assumptions. Use this list in design reviews:
- Map each ELV application and its network connections.
- Identify shared switches, uplinks, servers and network services.
- Document which functions require centralised connectivity.
- Record local operating and failover capabilities.
- Estimate peak network traffic.
- Review VLANs, ACLs, firewall policies and QoS.
- Identify single points of failure.
- Check power and physical-path dependencies.
- Define maintenance windows and change approvals.
- Document recovery objectives and restoration procedures.
- Establish monitoring and escalation responsibilities.
- Test important failure scenarios where appropriate.
Failure testing must be planned, authorised, and performed without creating unacceptable risk to building operations or life-safety functions.
What About Fire Alarm and Other Life-Safety Systems?
Regulated life-safety systems differ from ordinary ELV applications. Fire alarm systems carry specific design, supervision, reliability, listing and code requirements, and enterprise IT or CCTV design principles do not transfer to them automatically.
Whether a fire alarm system may use shared IP infrastructure depends on its architecture, the equipment’s approvals, manufacturer requirements, applicable standards and the authority having jurisdiction. Any integration, including monitoring interfaces to BMS or security platforms, should be checked against those requirements. Standards such as NFPA 72 have addressed cybersecurity in recent editions, but local adoption varies.
Conclusion
The correct architecture depends on operational criticality + network dependencies + traffic characteristics + security boundaries + failure isolation + recovery requirements. Shared infrastructure suits facilities that engineer and govern it properly. Dedicated infrastructure is justified when independence, predictable control or specific operational requirements call for it. Document the dependencies first, then choose the network model.
Read Also: Why Identical Addressable Loops Fail Differently, and How to Find the Cause
Read Also: Why Two Identical Fire Alarm Loops Can Behave Differently After Installation
