Camera firmware and the patching problem

What a camera firmware image is made of, which release track an estate can actually be standardised on, and why the signing story has a start date.

"A Common Product Platform is defined mainly by the used system-on-chip (SoC)." That line comes from the IP Video Firmware Info Brief published by Bosch's video business, now IQSIGHT B.V. following the rebrand announced on 19 February 2026, and it states what most vendors leave implicit. The unit of patching is the silicon generation. The model number on the purchase order sits downstream of it.

Hanwha describes its own range the same way. Firmware is built "based on the common platform" shared "across all camera product development", and the version string says so out loud: <PlatformMajor>.<PlatformMinor><ProductMajor>.<ProductMinor>. Two vendors, arriving at the scheme independently, both telling you that an inventory keyed to model names is keyed to the wrong field.

The delivery mechanics follow from the platform. Bosch ships firmware in two container types, and the split is a hard cutover at firmware 6.51: the older CPP_ container is a "Mix of unencrypted and encrypted files", "Not release-signed", and is "Not usable with FW 6.51 and higher", while the CPPS_ container carries encrypted files only, with "Container and single files are all release-signed", and is "Usable only with FW 6.51 and higher". Crossing that line is not one flash. Intermediate versions "introduce architectural changes and take care for compatibility when crossing over, thus are mandatory steps for upgrades and downgrades", softened by combined files that the camera can apply repeatedly, "automatically choos[ing] the next appropriate firmware version".¹

What is actually in the image#

Bootloader, kernel, root filesystem, vendor applications, and beneath them the SoC vendor's SDK, which the brand on the label did not write.

HiSilicon set that structure out itself when the telnet backdoor on TCP 9530 surfaced in 2020. Its PSIRT concluded the issue was "not introduced by the chips and SDKs provided by HiSilicon", placing the fault in code "delivered by equipment vendors" built on HiSilicon reference code, and noted that its own "Cyber Security Precautions for Secondary Development" had instructed vendors to delete telnet from mass-production builds. Read it as the silicon vendor's account of where blame lies. The division of labour it describes is still the one that matters: a chip vendor ships an SDK, an ODM ships firmware, a brand ships a box, and none of the three holds the deployed device's patch lifecycle.

Censys sized the affected population on 7 February 2020. It found 9,362 hosts that actually spoke the HiSilicon protocol on 9530/tcp, out of 188,989 with the port open. Any exposure figure built from open ports rather than protocol confirmation is carrying that 20x error.

Further down the market the silicon documents almost nothing. OpenIPC's processor catalogue listed 126 SoC models across 14 vendors on 5 September 2026, with SigmaStar (30), Ingenic (27) and HiSilicon (23) accounting for 80 of them. Ambarella publishes what its parts do: CV52S lists "Enhanced secure boot with TrustZone® and secure memory", a TRNG, OTP and Arm TBSA compliance, where CV2S, CV22S, CV25S and CV28M list a narrower set without the "Enhanced" qualifier and with no stated TBSA compliance. For Novatek, SigmaStar, Ingenic, Goke and Fullhan we could locate no public SoC security documentation at all. Absence of documents is not absence of features. It does leave you unable to establish a root of trust for those platforms from public material.

Which build do you standardise on#

Axis publishes the only release model in this set precise enough to plan a refresh cycle against, and it is the fact most likely to change what an estate actually runs.

The two tracks buy different things. On the active track only the newest build is supported, so a site that skips a release is unsupported until it catches up, at a cadence that puts four to six flashes a year into the maintenance plan. An LTS track gives roughly five years with a knowable end, at the price of new features. Because a track starts every two years and each runs about five, three are alive at once. An operator standardised on LTS 2022 in September 2026 is four years into that window, which is where the replacement build belongs in the plan rather than the backlog.

Axis's product-specific support track for 9.80, 8.40 and 6.50 has no published duration. For anything still on those versions, the support question cannot be answered from the lifecycle guide.

How updates arrive#

Getting hold of the file is a separate gate. Measured on 5 September 2026 with a desktop user agent, the download entry points for Axis, Uniview and Bosch's download store returned 200 with no authentication redirect, while Genetec GTAP and Milestone's software downloads both redirected to an identity provider.² A 200 on an index does not establish that the binary behind it is anonymously fetchable, which would need a credential-free retrieval we did not perform.

Bosch runs in the other direction from all of them. Firmware marked "revoked" is withdrawn from public download and obtaining it "requires a concession signed by the customer to acknowledge his awareness of potential security flaws"; "terminated" firmware is "no more provided at all". For an older platform, the image you need in order to reproduce or remediate a finding may not be obtainable, and the party you now ask for the concession is IQSIGHT rather than Bosch.

Signing, and the floor beneath it#

Hanwha's answer to the debug port is worth reading beside that table. Rather than disabling JTAG, Wisenet7 implements "a secret key-based authentication mechanism ... that enables the use of JTAG securely", with the manufacturer holding the key and access restricted to local rather than remote.

Tarlogic showed what the same class of port is worth when nobody did that work. On 1 December 2025 the team reported that on a Dahua DHI-NVR2104-4KS2 and a DH-XVR4104HS-I "the bootloader is not signed", despite partition encryption and software signature verification higher in the stack. The route in was physical: the UART debug interface, an asterisk sent to interrupt boot, a desoldered NAND flash dumped on a commercial programmer, then a reverse-engineered MD5-based bootloader password check and a keygen built against it. They also report that "encryption can be bypassed using built-in features meant for maintenance". No CVE assignment or vendor response is stated in the post.

Why the fix waits for a truck#

Verkada documents a dual-partition firmware bank, so a failed update reverts to the previous version and retries later. Verkada documents it; the other vendors' documentation in this piece does not mention firmware banks either way, and we did not go looking.

That matters because of where the devices are. A server that fails to boot after patching is a console session. A camera that fails to boot on a car-park mast is a truck roll, and the cost of that roll is why the flash waits for the next scheduled visit. Bosch's mandatory intermediate versions add to the same bill: crossing the 6.51 container boundary means several sequential flashes on a device somebody has to be standing next to.

When the defect is upstream#

Avigilon's Alta Video advisory index held 216 entries grouped by year from 2020 to 2026, and the 2026 entries were overwhelmingly third-party dependency issues: Go's crypto/x509 and crypto/tls, a gosaml2 forged LogoutRequest, a BusyBox ash stack overflow, redis/go-redis, a golang.org/x/crypto SSH agent panic. Those advisories cover the cloud product only, and they show the upstream-dependency problem in its easy form. Avigilon controls the whole stack and can redeploy it. Nobody flashes anything.

On a camera the same class of defect has to cross the boundaries HiSilicon described in 2020 before it reaches a device: the SDK vendor, the ODM that built firmware on top of it, and the brand that sells the box.

An SBOM is the only thing that lets a defender start the clock without the vendor. Axis states that "The SBOM is supplied with every device software release published on axis.com", and Hanwha publishes an SBOM document of its own, "Hanwha SBOM for Supply Chain Security" V1.0. With one, "is this model affected by that BusyBox advisory" is a lookup.

What nobody has measured#

CVE-2021-36260 went from report to disclosure in roughly 90 days, but the researcher noted vulnerable Hikvision firmware reaching back "as far back as at least 2016". The same defect rode forward across five years of shipping builds, which is the firmware-lifecycle point rather than the exposure one: until the specific fix landed, "run the latest" bought nothing.

How long the average deployed camera runs behind, nobody has published. We looked for a peer-reviewed or vendor-neutral longitudinal study of firmware age across deployed fleets — median months since release, distribution by vendor, anything of that shape — and found none. Patch-adoption snapshots for a single CVE exist and are widely quoted, and the best-known one is set out with its caveats on how cameras become internet-exposed. An adoption snapshot is not an age distribution, and there is no defensible proxy to put in its place.

When the vendor stops shipping fixes altogether, see end-of-life cameras and cyber risk. For triage once you know which builds you are running, camera vulnerability management.