When a building's cameras and access controllers live on the corporate network — and today they almost always do — the IT and network team should own them. Not co-own, not "advise on": own the IP addressing, the segmentation, the firmware lifecycle, and the credentials. Physical security teams should keep defining policy, monitoring footage, and responding to incidents, but the plumbing underneath a modern video system is a network problem, and treating camera network management as anything else is how organizations end up with hundreds of unpatched, internet-reachable devices nobody is accountable for. Here is the argument, including where the trade-offs are real.
A Surveillance Camera Is a Network Endpoint First
It helps to be honest about what an IP camera actually is. It is a small Linux computer with a lens attached. It has an operating system, an IP stack, open ports, a web server for its admin interface, user accounts, and firmware that ships with vulnerabilities like any other software. A 300-camera deployment is, from the network's point of view, 300 always-on embedded servers — plus the NVRs, encoders, access controllers, and intercoms riding the same wire.
Those endpoints behave differently from laptops. They are rarely rebooted, almost never patched on a schedule, frequently configured once and forgotten, and often reachable with default or shared credentials. That combination is exactly the profile attackers look for. Internet-exposed cameras have been swept into botnets, used as pivot points into flat corporate networks, and turned into quiet data-exfiltration channels. The risk isn't hypothetical or exotic — it's the predictable result of unmanaged endpoints, and unmanaged endpoints are squarely a network team's domain.
Physical Security Teams Own the Wrong Layer for This
This is not a knock on physical security professionals. Their expertise — sightlines, coverage, retention policy, investigations, response procedures, regulatory chain-of-custody — is genuinely hard and genuinely theirs. But ask whether that team is staffed and tooled to do the following at scale:
- Maintain VLAN segmentation and enforce least-privilege traffic between the camera network and everything else.
- Track firmware versions across every device and run a patch cadence tied to published advisories.
- Rotate credentials, kill default accounts, and integrate device authentication with the directory.
- Monitor for anomalous outbound traffic from a device that should only ever talk to its recorder.
Most physical security departments aren't resourced for that, and they shouldn't have to be — those are the same disciplines the network team already applies to every other endpoint class in the building. Splitting them off into a parallel, security-camera-only world means reinventing patch management, monitoring, and identity poorly. Consolidating camera network management under the team that already owns the network means the surveillance fleet inherits controls that already exist instead of needing bespoke ones.
The Compliance Case: 889, TAA, and Provenance
For federal agencies, contractors, and any enterprise that sells into the public sector, ownership has a hard compliance edge. NDAA Section 889 prohibits the federal government from procuring or using telecommunications and video surveillance equipment from specific covered manufacturers, and it reaches down through the supply chain to contractors. TAA (Trade Agreements Act) requirements add country-of-origin constraints on what can be sold to government buyers.
You cannot prove compliance with gear you cannot inventory. Demonstrating that no covered devices exist on your network — and keeping it that way as cameras get added, swapped, and RMA'd over years — is fundamentally an asset-management and network-visibility exercise. The network team already runs the discovery, inventory, and monitoring tooling that produces that evidence. When a contracting officer or auditor asks for proof, "the network team maintains a live inventory mapped to approved, TAA-compliant models" is a defensible answer. "Facilities bought whatever the lowest bidder installed" is not. Provenance has to be designed in at procurement and enforced continuously, which is exactly where network ownership and a vendor-neutral, compliance-first sourcing posture reinforce each other.
The Honest Trade-Offs
Network ownership isn't free, and pretending otherwise sets up the handoff to fail.
Domain knowledge gaps cut both ways. Network engineers may not know why a particular camera angle matters or what retention the legal team requires. Physical security may not grasp why flat networks are dangerous. The fix is a shared operating model with explicit RACI, not a wholesale transfer that leaves security blind to its own footage.
Multicast, bandwidth, and uptime are real engineering. Video is heavy, often multicast-heavy, and recording gaps can break investigations or violate retention mandates. The network team takes on availability requirements that may be stricter than what general IT is used to. That's a feature — it forces proper QoS and redundancy — but it has to be planned, not assumed.
Turf and tooling friction. Two budgets, two ticketing systems, and two cultures don't merge by org chart alone. Without executive sponsorship and a written boundary, ownership becomes finger-pointing during an outage.
None of these are arguments against network ownership. They are arguments for doing it deliberately, with a designed division of responsibility rather than an accidental one.
A Practical Division of Responsibility
The model that works in practice keeps each team on the layer it's best at:
- Network/IT owns: IP addressing and DHCP reservations, VLAN and firewall segmentation, switch and PoE infrastructure, firmware and patch lifecycle, device credentials and certificate management, and traffic monitoring.
- Physical security owns: camera placement and coverage, the VMS and investigations workflow, retention and chain-of-custody policy, alarm response, and the relationship with guards and facilities.
- Shared, governed jointly: procurement (so only approved, compliant models enter the fleet), incident response that spans cyber and physical, and the change process when cameras are added or moved.
Drawing that boundary on paper — before the next install, not after the next breach — is what converts a vague "IT should help" into accountable, auditable operations.
Where an Integrator Fits
A vendor-neutral integrator's job is to make this division real across the full lifecycle: designing a segmented network architecture, specifying TAA-compliant and 889-clean hardware regardless of brand, standing up the credential and firmware-management practices, and documenting the inventory that satisfies auditors. Because we don't carry a single-vendor agenda, the recommendation is driven by your compliance posture and risk model, not a quota. And because we support the system after cutover — patching, monitoring, and re-validating provenance as the fleet changes — the network team inherits a manageable system instead of a closet full of orphaned endpoints.
If you're deciding who should own the camera system and want that decision to hold up to a federal audit, talk to us about a compliance-first surveillance assessment.