What video cybersecurity means
The entry page to this reference — what the equipment actually is, what the subject covers, where it stops, and what to read first.
A surveillance system is a computer network. The reason that plain sentence 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.
The rest of this page is a map of the subject: what the equipment is, why it tends to be handled apart from the rest of IT security, where the subject stops, and what to read first.
The equipment#
The subject covers the estate, not only the cameras.
Cameras are embedded Linux computers with a lens attached. They run vendor firmware built over a chip vendor's SDK, and they expose a web interface, one or more streaming services and a discovery protocol.
Recorders — NVRs, DVRs and hybrids — are the highest-value asset in most estates, because a recorder holds working credentials for every camera it records as well as months of footage.
Video management platforms are ordinary server software running on ordinary servers with ordinary databases, and they are frequently excluded from the ordinary controls applied to everything else in the rack.
Protocols have to be looked at separately from the devices that speak them. ONVIF handles device management and RTSP handles streaming; the security properties of each are not the web interface's, and they are often configured separately or not at all.
Cloud and remote access includes the outbound relay connections many devices maintain to a vendor service, which is what makes an inbound-only view of exposure misleading.
Adjacent physical-security systems — access control, intercoms, alarm panels — share the network segment, the installer and often the management platform, and are part of the subject for that reason.
Two answers to the same question#
Ask a physical-security manager about camera security and you get an answer about coverage, lighting, tamper detection and evidential retention. Ask a network engineer the same question and you get an answer about VLANs and firmware. Both are correct, and this subject lives in the gap between the two answers.
The gap follows from how the equipment arrives: bought on a capital budget as part of a building project, installed by an integrator under a construction or maintenance contract, commissioned once, supported by the installer who frequently still holds the credentials, and connected to the network by whoever ran the cable — so the estate, often the largest population of networked devices an organisation owns, appears in no asset inventory that a security programme actually consults. Closing that as an owned, ongoing programme is a separate body of work, set out at VideoASM; this site is the reference material rather than the programme.
Why the ordinary methods are harder here#
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 the subject stops#
The subjects immediately next to this one are routinely mistaken for it.
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". The question here is "what can be done to it", and the two are routinely confused: 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.
Where to start reading#
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 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.