Hardening a video estate

What to change, in the order worth changing it, and an honest note on what each step actually buys you.

Most hardening checklists for this equipment are ordered by how easy each item is to write down. This one is ordered by how much risk each item removes, which produces a different sequence and puts the two most effective controls — segmentation and credential hygiene — above the firmware work that usually leads.

Nothing here is a substitute for the manufacturer's own guide. Where a vendor publishes one, it is more specific than anything a third party can write, and the ones we could verify are listed at the end.

The order that matters#

If you do these in order and stop halfway, you will still have removed most of the risk. That is the point of the ordering.

1. Segmentation#

The single most effective control, and the one most often deferred because it is the most disruptive.

The camera VLAN should permit: cameras to the recorder on the recording and control ports, operator clients to the recorder, management access from a defined administrative source, and time synchronisation. It should not permit cameras to reach each other, cameras to reach the corporate network, or anything on the camera VLAN to reach the internet unless a specific vendor service requires it — in which case that path is named, documented and restricted to the destinations it needs.

The rule that gets missed is outbound. An estate with no inbound exposure and unrestricted outbound is reachable through any vendor cloud relay the devices maintain, and that path survives every inbound firewall rule you write.

Verify the segment rather than trusting the diagram. Put a laptop on the camera VLAN and try to reach the things the design says you cannot.

2. Credentials#

Remove default credentials. Modern products from major vendors force a password at first boot. Devices restored to factory defaults after a fault frequently do not stay that way, so this is a recurring check rather than a one-off task.

Stop sharing one password across the estate. This is the more common and more damaging problem, and it exists because a shared credential is what makes the system maintainable for the people who maintain it. Fixing it properly means a credential management approach the physical-security team can actually operate — not a policy they will work around.

Account for the recorder's credentials. A recorder holds a working login for every camera it records. Those credentials are the ones worth protecting most and the ones least often rotated.

Remove the integrator's standing access when the commissioning phase ends, or convert it to something time-bound and auditable. Integrator credentials frequently persist for years and are frequently reused across that integrator's customers.

Separate roles. An operator who needs to view live video does not need an administrative account on the recorder.

3. Exposure#

Enumerate every path from outside, in both directions:

• Port forwards created during commissioning, which are often undocumented
• UPnP port mapping, which lets a device open a path without anyone deciding it should — disable UPnP on the router, not only on the device
• DMZ placement, occasionally used to "make the app work"
• Vendor peer-to-peer and cloud relay services, which are outbound and therefore invisible to an inbound audit
• VPN accounts issued to the integrator
• Remote-support tooling installed on the VMS server

For each: establish whether it is needed, by whom, and what breaks if it is removed. "The phone app stops working" is a real answer that leads to a different design, not a reason to leave a port forward in place.

4. Inventory#

You cannot harden what you have not found, and the video estate is characteristically absent from the asset systems a security team already uses.

The best starting source is the VMS or recorder's own device list, which is maintained accurately because the operation depends on it. Compare it against PoE port status on the access switches. The difference between those two lists is the set of devices that are powered and connected but not recording — decommissioned-but-live equipment, devices on a standalone recorder, and cameras commissioned and never added.

For each device you want manufacturer, model, firmware version and an accountable owner. Firmware version is the field that resists collection and the one that determines vulnerability exposure. Record what you could not establish rather than leaving it blank.

VideoASM sets out this stage as a programme with a completion test; camera vulnerability management covers turning the inventory into findings.

5. Services#

Turn off what is not used. On a typical camera that means: Telnet if present, SSH unless you use it, UPnP, SNMP if nothing polls it, multicast and discovery protocols if the estate is statically addressed, and any secondary streaming endpoint the VMS does not consume.

Two cautions. Disabling discovery makes future commissioning harder, which is a real cost worth accepting deliberately rather than discovering later. And a factory reset restores every one of these, so the check belongs in the post-fault procedure.

6. Encryption#

Enable HTTPS for management on every device that supports it, and disable the plaintext interface rather than merely adding the encrypted one alongside.

Certificates on these devices are usually self-signed and unverified in practice, which limits what TLS buys you against an active attacker on the path — but it still removes passive credential capture, which is the realistic threat on a shared segment.

Where the device supports authenticated and encrypted streaming, use it. Where it does not — and many do not, particularly for RTSP — treat the camera segment as a network on which credentials are visible, and design the segmentation accordingly. That is the honest position, and it is why segmentation is first on this list rather than encryption.

7. Firmware and lifecycle#

Patching is last among the technical controls not because it does not matter, but because it is the slowest, the most operationally risky, and the one with a hard floor: a product past end of support has no route to remediation at all.

Establish, per product family: whether the vendor still publishes firmware for it, how updates are delivered, whether you or a contractor is able to apply them, and what the rollback position is if one fails. A failed update on a camera at height is a truck roll; a failed update on a recorder can cost retention.

Where a device is past support and cannot be replaced this budget cycle, the response is compensating — tighter segmentation, removal of any remote path, monitoring — recorded as an accepted risk with an owner and a review date, not as a closed finding.

See end-of-life cameras and cyber risk and camera firmware and the patching problem.

8. Logging#

Send device and VMS logs somewhere the device cannot overwrite. Most cameras keep a small local log that rolls quickly and is lost on reboot, which means that by the time anyone asks what happened, the evidence is gone.

At minimum, capture authentication events and configuration changes from the recorder and the VMS server, which is where the consequential activity happens.

Vendor hardening guides#

These are the manufacturer guides we were able to fetch and confirm as of 5 September 2026. They are more specific than this page and should be preferred for the products they cover.

Several other major vendors either publish hardening material we could not locate from their public support pages, or publish it behind a partner login. The absence of a link above is not a statement that no guide exists — only that we did not find one we could read and cite.