Camera firmware update at scale

Camera firmware update at scale is inventory, eligibility, staged waves, soak, and rollback, with current defined as the newest release each camera is actually eligible for. A commissioning spreadsheet is not a posture, and a single bulk push is not a campaign. The work is deciding, per device, what it runs, what it is allowed to take, how many can move in one window, how long you wait before the next window, and what you do when one of them does not come back.

Firmware management is that sequence given a name: know what each device runs, what it is eligible to take, move it in waves, soak, and keep a way back. The same sequence is what iot firmware looks like when the devices are cameras. They stay on the network for a decade, they sit in every coverage plan, and a bad wave is a recording gap. Vendor UIs and per-model detail belong in the Axis, Hanwha, and Bosch notes linked below. This page is the fleet procedure those notes assume you already have.

What current actually means

Current means the newest release that this camera, on this product or platform or family, is eligible to run. The newest number a vendor published this quarter is a different fact. Mixing the two is how a fleet reports current while leaving cameras unpatched.

Three vendors, three eligibility shapes:

Vendor	Eligibility	Current means
Axis	Per product and per track	Latest release on the track that product rides
Hanwha	Latest per family	Latest image for that series, including any required intermediate
Bosch	Per CPP platform	Latest for that platform, including sub-platform and held-back models

A camera on the latest release of its own Axis LTS track is current. A sibling on 12.x does not make the LTS camera behind. A Bosch camera whose part number looks like its neighbors can sit on a different platform, or on a frozen line inside a current family, and still be current. A Hanwha camera is current when it is on the latest image for its family, not when the file name happens to match the model on the ceiling.

Write the standard as “every camera on the newest release available to it.” That phrasing survives all three vendors, and it is the phrasing an auditor can verify without becoming a firmware librarian. iot device firmware follows the same rule: a recent version string is the wrong answer if you cannot say whether that string is the ceiling for that device.

Confirm the target against the vendor’s own page before you flash anything. Vendor-specific next steps: AXIS OS upgrade paths explained, Hanwha Wisenet firmware updates at scale, and Bosch camera firmware update: mapping models to platforms.

Inventory from the devices

Build the list off the cameras, not off the as-built, which is a hypothesis.

For each camera you need vendor, model, serial, the version it is running, and the eligibility key: Axis product and track, Hanwha family, Bosch CPP including sub-platform. Add whether the model is still inside a support window, and whether credentials will let a campaign authenticate. A firmware status check that surfaces password prompts is a credential problem. It will stall the campaign before the first image moves. Fix credentials first, as a separate exercise.

The camera missing from the list is the camera that still runs last year’s image. Inventory that starts from a spreadsheet and never walks the devices will patch the list and leave the floor alone.

Verify image integrity when the vendor publishes a hash. Axis publishes a SHA-256 on every download page. Bosch publishes checksums on current platforms. Hanwha publishes none, so the vendor link is the whole chain. Wrong image and truncated download are quiet at ten cameras and expensive at five hundred.

Waves, soak, and coverage

An iot firmware update at ten devices is an afternoon. At five hundred cameras it is a calendar. The calendar is set by four numbers, and none of them is how fast the image copies.

Canary. One camera per eligibility group: per Axis model, per Hanwha series, per Bosch platform. Validate it in the recorder and in health monitoring before anything else moves. The canary is cheap because rollback is still available and coverage is still intact.

Wave size. Bounded by how much of any one site you will have offline at once, by how many cameras one engineer can actually watch come back, and by the vendor tool’s own concurrency. Hanwha’s bulk queue has a default that sets the calendar. Axis and Bosch campaigns are limited by supervision and coverage in the same way, even when a tool would let you go faster. Sites with a coverage obligation may allow none during operating hours, which means the window is the constraint, not the flash.

Soak. Time after a wave when you are looking for the failure that did not show up in the reboot. Authentication that fails on the next shift. A stream that records with a wrong clock. A camera that answers its management page and is missing from the recorder. Soak is quantized to your maintenance calendar: a three-day soak at one window a week still costs a week, because the next window is the first chance to resume. Skip the soak and the next wave inherits a problem you have not seen yet.

Commit, then the next wave. Confirm the new version on the device, confirm recording, then commit. Do not leave an uncommitted wave sitting over a weekend that includes a power event. On Axis, an uncommitted upgrade rolls back on a power cycle. That is a safety net during validation and a silent undo if you walk away.

Most of a 500-camera campaign’s elapsed time is soak gates, not flashing. Adding cameras in flight compresses the window inside a wave. Adding a second weekly window, or shortening soak, is what moves the date. The firmware campaign planner runs that arithmetic against fleet size, window length, and soak before anyone promises a completion week.

Rollback before the next wave

Treat rollback as a campaign rule. Confirm the camera’s real state before any retry. A camera still writing looks identical to a camera that failed. Starting a second upgrade, on vendors that snapshot the previous bank when an upgrade starts, destroys the path back, including when the first flash was seconds from succeeding.

Stop the wave if the canary or a cluster of members is wrong. Do not enlarge a bad image. A bulk retry across the same wave is how a recoverable set becomes a site visit.

Know which families cannot roll back. Some Hanwha lines are one-way, or they require an intermediate build before the target. Some Bosch downgrades are a different procedure with a different image, not a restore. Axis dual-bank handling is strong, and the restore point still dies when the next upgrade starts. When an Axis upgrade does not come back, recover without a blind retry: Axis camera firmware update failed. The first recovery step on any of the three is almost always wait, then a power cycle, not a factory default and not a second flash.

Factory default is the expensive rung. It wipes configuration, certificates, addressing, and time. On an 802.1X port the camera may never rejoin, which reads as bricked when the firmware is fine. Reach for it last, and plan to reprovision.

Patch latency after the CVE

A published vulnerability with a patch that is not on the camera is a firmware campaign that has not started. Patch latency, the months between the fix existing and the fix landing on the device, is the usual reason a known camera CVE is still a live problem. Eligibility, waves, and soak still have to be right.

A Friday dump of every image a vendor published this year is how fleets interrupt recording and then stop patching for a year. Axis, Bosch, and Hanwha publish their own advisories. Unsupported brands appear on CISA’s Known Exploited Vulnerabilities list for a different reason: as a prompt to replace, not as a support matrix. Neither fact changes the procedure on the cameras you intend to keep. Current still means eligible, and eligible still has to be true per device.

Doing this across 500 cameras

The procedure is the same at five hundred as at five. What changes is that the inventory is stale a week after you build it, the three vendors disagree about what current means, soak dominates the calendar, and nobody is watching each camera closely enough to tell still-writing from failed. That last gap is what produces the blind retry.

MentatNOC keeps model, running version, and eligibility current on every camera, flags the day a new release lands that a camera can take, verifies every image’s integrity before it reaches a device, and pushes firmware in staged waves with canaries and automatic rollback. Every check and every change lands in an audit log built so entries cannot be rewritten after the fact. It monitors device health, not video. The write-side actions are on firmware, password, and certificate actions, and a staged rollout runs end to end in a live platform demo.