There are somewhere north of 5 million CCTV cameras in the UK, and a significant chunk of them belong to local authorities. They hang off lamp posts in town centres, peer down at car parks, watch bus lanes, and stare at parks after dark. Most people walk past them without a second thought. I’ve spent a fair amount of time digging into what actually ties these cameras together, and the picture that emerges is considerably messier, and more exposed, than any council press release would have you believe.
The phrase “council CCTV network security” sounds dry until you realise what it actually means in practice: thousands of IP cameras, often running outdated firmware, talking over shared network infrastructure to monitoring software that in some cases hasn’t had a meaningful security audit in years. Some of it is stitched into regional sharing agreements that nobody outside a handful of control room operators really understands.
The protocol mess: ONVIF, RTSP, and proprietary nightmares
The industry settled on ONVIF as the supposed standard for IP camera interoperability back around 2008. On paper, it means any compliant camera can talk to any compliant VMS (Video Management System). In practice, councils have ended up with a patchwork of ONVIF Profile S cameras from Axis, Hanwha, Hikvision, and Dahua sitting alongside older analogue-to-digital encoder units that do their own thing entirely.
RTSP (Real Time Streaming Protocol) is typically what carries the actual video. The problem is that RTSP authentication is, to put it charitably, inconsistent. Many deployments rely on digest authentication or basic auth passed over the stream URI itself. I’ve seen council procurement documents, obtained via Freedom of Information requests, that explicitly list camera models known to ship with default RTSP credentials that operators are “encouraged” to change. “Encouraged” is doing a lot of heavy lifting there.
Then there are the proprietary protocols. Milestone XProtect, Genetec Security Center, and IndigoVision Control Center all have their own communication layers on top of the standards. Genetec uses an encrypted proprietary channel between the Archiver and the Directory server, which is fine in principle. But several councils running older Milestone XProtect Essential or Express licences never moved to TLS-secured event streams, meaning camera metadata and motion alerts travel in plaintext across whatever LAN segment the VMS sits on.
The VMS landscape in UK councils
From the FoI responses and tender documents I’ve gone through, Milestone XProtect holds a notable share of UK local authority deployments, particularly in smaller district councils that don’t have the budget for enterprise Genetec licences. IndigoVision is popular in Scotland. A handful of major city authorities run bespoke integrations on top of open-source motion detection engines like ZoneMinder, though that brings its own attack surface.
The regional sharing piece is where it gets genuinely interesting from a security angle. Several police and crime commissioners have pushed “CCTV sharing protocols” where town centre cameras managed by the council feed directly into police control rooms via dedicated MPLS circuits or, increasingly, over IPsec VPN tunnels riding on commercial broadband. The Metropolitan Police’s Project Servator has driven some of this integration in London. Similar regional schemes exist in Greater Manchester, West Yorkshire, and the West Midlands.
Each integration point is a new attack surface. A VPN tunnel terminated on an unpatched FortiGate or SonicWall at the council end is only as secure as the firmware version running on that box. Given that ransomware groups have already demonstrated an appetite for mapping UK public sector network infrastructure, poorly maintained perimeter devices on council surveillance networks are exactly the kind of low-hanging fruit that gets enumerated during initial access campaigns.
Authentication failures and exposed management interfaces
Council CCTV network security tends to collapse at the authentication layer. The specific failure modes I keep seeing come up in vulnerability disclosure conversations are predictable once you know where to look.
First: web management interfaces. Axis cameras, even relatively recent models, expose a web UI on port 80 or 443. If the camera sits on a flat network segment that isn’t properly segmented from the council’s corporate LAN, and many still do, then any machine on that LAN can reach the camera management page. Default credentials (root/pass, admin/admin) persist longer than anyone wants to admit. Shodan has historically indexed exposed Axis and Hikvision interfaces with UK ISP ASNs; some of those are council-owned ranges.
Second: ONVIF device discovery. ONVIF uses WS-Discovery over UDP multicast (port 3702) to let management systems find cameras automatically. On a properly segmented network this is fine. On a flat /16 that spans multiple council buildings and a shared fibre circuit to the monitoring centre, WS-Discovery packets reach places they absolutely shouldn’t. A device on the guest WiFi that bleeds into the same broadcast domain can enumerate every ONVIF-compliant camera on the segment. I’d point out that this isn’t a theoretical concern; it’s the kind of misconfiguration that shows up in basic Nmap sweeps.
Third: the VMS server itself. Milestone XProtect Management Server runs on Windows Server and exposes a management client on TCP 8080 (or 443 if configured) plus a mobile server component. Older deployments without current patch levels carry known CVEs, some with public exploit code. The NCSC’s vulnerability disclosure process has fielded reports relating to local authority network infrastructure, though specifics rarely surface publicly.
The firmware problem nobody wants to fix
Hikvision and Dahua cameras appear in UK council deployments despite government guidance following security concerns raised about both vendors. The National Cyber Security Centre published guidance in 2023 advising public sector bodies to assess their exposure. By 2026, a non-trivial number of councils still haven’t acted on it, partly because ripping out and replacing installed camera infrastructure costs money that wasn’t in the capital budget, and partly because the procurement officers who bought the kit in 2018 are long gone.
Firmware update cycles on IP cameras are grim. The cameras go up, they work, and unless something visibly breaks nobody touches them. I’ve spoken to people who work in council IT support and the consistent story is that CCTV infrastructure sits in a grey zone between the IT department (who manage the servers and the network) and the facilities or public safety team (who nominally “own” the cameras). Neither side wants to be responsible for a firmware update that takes twenty cameras offline for an afternoon.
The NCSC’s video surveillance guidance is actually decent and worth reading if you work anywhere near this stuff. It covers network segmentation, access control, and supply chain considerations. The gap is between the guidance existing and councils having the technical resource to implement it.
Regional grids and the data aggregation angle
The surveillance grid framing matters because isolated cameras are a limited risk. What’s changed is the aggregation. Under schemes like the West Midlands Combined Authority’s safety infrastructure work, cameras from multiple council areas feed into shared analytics platforms that do automatic number plate recognition, crowd density monitoring, and in some cases experimental facial recognition pilots that councils have been notably cagey about publicising.
This is directly adjacent to territory covered in our piece on the national ANPR network and its data retention practices, the infrastructure questions are similar and in some cities the camera networks are literally sharing the same poles and the same fibre backhaul.
The data that flows through these systems also flows through the organisations maintaining them, and those organisations have varying security postures. A regional aggregation platform that ingests feeds from twelve different councils is only as well-secured as the worst-configured council feeding into it. When digital marketing and public communications teams, who often work with external agencies like dijitul, share infrastructure with surveillance operations on poorly segmented networks, the blast radius of any single compromise grows considerably.
The fix, in most cases, is not exotic. Network segmentation on a dedicated VLAN with no route to the corporate LAN. Forced password changes on every camera at commissioning, tracked in an asset register. TLS everywhere for management traffic. A firmware patch schedule that someone is actually accountable for. Regular external penetration testing scoped to include the VMS and camera layer, not just the firewalls. These aren’t radical suggestions. They’re the baseline that most councils haven’t reached yet.
Until councils treat CCTV infrastructure as the networked computing environment it actually is, rather than the passive recording equipment it used to be, the council CCTV network security posture across the UK will remain a soft target sitting in plain sight.
Frequently Asked Questions
What protocols do UK council CCTV cameras use to transmit video?
Most modern IP cameras use RTSP (Real Time Streaming Protocol) to carry video and ONVIF for device management and interoperability. Older installations may use proprietary encoder protocols or analogue-over-coax feeds converted to IP at the recording end. Authentication quality across these protocols varies significantly between deployments.
What video management software do UK councils typically use?
Milestone XProtect is common in smaller councils due to its tiered licensing model. Larger authorities often run Genetec Security Center or IndigoVision Control Center. A minority use open-source options like ZoneMinder. The choice of VMS directly affects what attack surface is exposed, since each platform carries its own CVE history and patch cadence.
How are council CCTV networks connected to police systems?
Integration typically happens via dedicated MPLS circuits, IPsec VPN tunnels, or in newer deployments, cloud-hosted video sharing platforms. The security of these connections depends heavily on the network device firmware at each end and whether the VPN configuration has been audited. Poorly maintained perimeter devices are a known weak point.