What video cybersecurity means

The field, its boundaries, and why an estate of ordinary embedded computers ends up outside ordinary security programmes.

A surveillance system is a computer network. That sentence is the whole field, and the reason it needs stating is that surveillance systems are almost never bought, installed, owned or budgeted as though it were true.

Video cybersecurity is the security of the machines that make up a video-security estate — the cameras, the recorders, the management servers, the operator workstations, the encoders keeping older cabling in service, and the network and cloud services all of it depends on. It is not the security provided by cameras. It is the security of them.

Why the distinction is not pedantic#

Ask a physical-security manager about camera security and you will get an answer about coverage, lighting, tamper detection and evidential retention. Ask a network engineer the same question and you will get an answer about VLANs and firmware. Both are correct, and the gap between the two answers is where this subject lives.

The gap is structural rather than anyone's fault. Video systems are typically:

• Bought on a capital budget by a physical-security or facilities function, often as part of a building project rather than an IT purchase
• Installed by an integrator under a construction or maintenance contract
• Commissioned once and then expected to run untouched for a decade
• Supported by the installer, not the manufacturer, with credentials frequently held by the installer
• Connected to the network by whoever ran the cable

None of those steps involves the security team, and the resulting estate — often the largest population of networked devices an organisation owns — appears in no asset inventory that a security programme actually consults.

What is in the field#

The subject covers the whole estate, not just the cameras:

Cameras, which are embedded Linux computers with a lens attached, running vendor firmware over a chip vendor's SDK, exposing a web interface, one or more streaming services and a discovery protocol.

Recorders — NVRs, DVRs and hybrids — which are the highest-value asset in most estates because they hold working credentials for every camera they record and months of footage.

Video management platforms, which are ordinary server software running on ordinary servers with ordinary databases, and which are frequently excluded from the ordinary controls applied to everything else in the rack.

Protocols — principally ONVIF for device management and RTSP for streaming — whose security properties are not the same as the web interface's and are often configured separately or not at all.

Cloud and remote access, including the outbound relay connections many devices maintain to a vendor service, which make an inbound-only view of exposure misleading.

The adjacent physical-security systems — access control, intercoms, alarm panels — that share the network segment, the installer and often the management platform.

What is not in the field#

Two exclusions, because a subject that claims everything explains nothing.

Operational video quality — whether a camera is aimed correctly, in focus, recording at the right frame rate, or has a failing disk — is a real discipline with mature tooling and a different owner. It answers "is it working". This subject answers "what can be done to it". The two are routinely confused, and an organisation with excellent health monitoring frequently believes its video estate is monitored in a security sense when it is not.

The privacy and lawful-basis questions attached to surveillance are consequential and adjacent, and this site does not treat them. Nothing here should be read as guidance on whether a camera should exist, only on how to secure one that does.

What makes it genuinely different from general IT security#

The methods are not special. Inventory, assess, prioritise, remediate, monitor — the same process that works elsewhere works here. Four things make applying it harder:

Identification resists automation. A credentialed scan gives you an accurate picture of a server. Cameras generally offer no equivalent, firmware version is inconsistently exposed and inconsistently formatted, and unauthenticated scanning of embedded devices carries a real risk of disrupting them.

The vulnerability record is structurally incomplete. CVE coverage depends on vendors choosing to participate. Some publish consistently; some publish advisories with no identifier; some fix issues silently in a firmware release. At least one major vendor's CVE-assignment scope explicitly excludes discontinued products, which means the public record thins out precisely where the risk concentrates. A product with few published vulnerabilities is often a product nobody has examined.

Remediation is frequently contractual rather than technical. Applying a firmware update may require a third party under an agreement written before any of this mattered, a technician on site, and acceptance of the risk that the device does not come back.

Lifetimes are long. Devices installed a decade ago are still recording, still on the network, and in many cases still supported by nobody.

Where to start#

If you are picking this up cold, the useful order is: understand what the devices are (camera cybersecurity and NVR security), find out what you actually have and what is exposed (how cameras end up on the internet), then work through what to change (hardening).

For running this as an ongoing programme rather than a one-off exercise, VideoASM sets out a framework with a maturity model. For the published vulnerability history of a specific model, CameraRisk is a searchable database.

Everything on this site carries its sources and its dates. How we source sets out the rules, including what we will not publish and what happens when we get something wrong.