Camera cybersecurity

Three companies build an IP camera and none of them holds its patch lifecycle, so the practical test of whether an organisation has closed that gap is who can authorise a factory reset.

Bosch changed its IP camera factory defaults to close five listening ports: RCP+ 1756, HTTP 80, RTSP 554, iSCSI server 3260 and NTP server 123. The sentence that decides what that is worth sits further down the TechNote. "New defaults will not automatically become effective during a firmware upgrade but require a factory default to be applied." On CPP14 and on the CPP6/7/7.3 family, a camera upgraded in place keeps whatever it had open before. Only on CPP13, from firmware 8.90, do the new defaults take effect on upgrade.

So for most of that installed base the hardened configuration is not a download. It is a factory reset and a full reconfiguration of each affected camera, at height, with the recording gap that implies. That is a work order rather than a patch, and it lands on the seam between physical security and cybersecurity: someone has to raise it, and it comes out of a budget.

The reset does not stay inside the camera either. Hanwha's hardening guide tells installers to move HTTP, HTTPS, RTSP and the 4520 device port off their defaults, then warns in the same section that doing so "may cause communication problem if there is a connected recording device or VMS". Change the camera and you have changed what the recorder expects, so the job crosses at least two systems and the people who administer them need not answer to the same manager. VMS security covers the recorder side.

We put the ownership question as a question rather than a finding, because we could locate no public source describing who holds the right and the duty to reconfigure a camera under a typical maintenance agreement. Those are unpublished commercial terms. What is documented is the manufacturing side, and that does not produce an owner either.

Three companies build it and you buy from one#

In February 2020 a telnet backdoor reachable on TCP 9530 surfaced in HiSilicon-based cameras and recorders. Huawei's PSIRT concluded the flaw was "not introduced by the chips and SDKs provided by HiSilicon", locating it in code "delivered by equipment vendors". Its notice adds that HiSilicon's own "Cyber Security Precautions for Secondary Development" material had told those vendors to delete telnet from mass-production builds.

Read that as the silicon vendor's account of its own liability, which is what it is. The structure it describes is still the one you buy into. The company that wrote the reference code published guidance, had no way to enforce it, and has no contract with you. The company that assembled the firmware is an ODM whose name may appear nowhere in your procurement file. The company you did contract with supplied the enclosure and the label. Guidance travelled down that chain and obligation never travelled back up it.

Working out which three companies you are dealing with is its own exercise. The silicon under the long-tail brands is catalogued mostly by hobbyists, and the SoC-vendor breakdown sits on camera firmware and the patching problem; for the white-label ODM segment we could find no vendor security documentation at all, on firmware signing, secure boot or anything else. No documents is not the same as no feature. It does mean you cannot establish a root of trust for those devices from public material.

The named brands at least announce themselves on the network. Hikvision's Server Port is 8000, Dahua's private SDK service is TCP 37777 with UDP 37778 beside it, Hanwha's device port is 4520, Bosch's RCP+ is 1756. Axis has no proprietary control port at all, because VAPIX and ONVIF both ride 80 and 443. Four of those five hand a scanner a number to key on and one does not. Neither 37777 nor 37778 carries an IANA registration, so the fingerprint has to be taken from the payload, and Dahua's manual separately lists 37776 and 37780–37880 as "occupied for specific uses" and advises against assigning them without stating that the device enforces it, which means a sweep of 37777 alone undercounts. The rest of the port detail is on common camera ports and protocols.

What the support policies commit to, and what they leave out#

Axis commits to AXIS OS support "at least five years after its discontinuation date". Hanwha commits to five years after discontinuation, but in that tail phase only where the reported flaw is judged serious. Dahua commits to security updates "for at least 2 (TWO) years after the first shipment for sale". Three different events start those clocks, and the qualifiers under each are laid out on end-of-life cameras. What none of the three documents says is who applies the resulting update.

No vendor could reasonably fix that. The vendor is not party to the arrangement between the building owner, the integrator who installed the system and whoever holds the maintenance contract now.

Two vendors have made the gap visible from opposite ends. Bosch withdraws superseded firmware rather than deprecating it, and obtaining an image marked "revoked" "requires a concession signed by the customer" acknowledging awareness of potential flaws, so a countersignature stands between an operator and a file; camera vulnerability management covers what that does to triage. Verkada removes the decision from the operator instead. Updates are "pushed automatically", the customer may schedule a window of at least two hours, and whether a customer can decline updates entirely is not stated in the documentation we retrieved, which is discussed under cloud video security. Every on-premise estate sits between those two, where the update is a pull that somebody has to initiate.

Where the chain runs out#

For a small set of devices the question has already been settled, by a regulator, against the device.

This site counts 22 video entries in CISA's Known Exploited Vulnerabilities catalog at version 2026.09.04 (1,695 entries, released 2026-09-04). That figure is used everywhere on this site and is computed, not typed: a CVE counts when it is in KEV and at least one CPE product NVD records against it survives our video-product filter. The filter is in the repository and the count moves when the data does.

KEV carries no device-class field, so any count of this kind is a classification someone made. Two of ours are worth arguing about. CVE-2021-3156 is catalogued against sudo and reaches this set only through the CPE record of a Synology VS960HD recorder that ships it. CVE-2023-38950 is ZKTeco BioTime, which is access control rather than video, and is here because it shares the estate and the installer. Read the catalog strictly as cameras, recorders and video-management software and you get 20. We publish the looser number because the rule behind it is mechanical, and name the two entries so you can subtract them.

For five of them, the required action is not to patch.

Three of those are unconditional. The two Reolink rows are hedged, CISA writing "could be" rather than asserting the lifecycle status of the product itself, which is a fair reflection of how hard that status is to establish from outside. The D-Link entry has sat in the catalog since 25 March 2022 with a remediation due date three weeks later, and in the four and a half years since, the instruction has never been anything other than to disconnect the device. A camera in that condition is not unpatched. There is no party left who could patch it.