Bosch camera firmware update: mapping models to platforms

A Bosch camera firmware update is decided per platform rather than per model. Every Bosch network camera belongs to a Common Product Platform generation, CPP4 through CPP16 across the population still in the field, and each platform has exactly one current firmware version in the download area. There are no parallel active and long-term tracks to pick between. That makes Bosch the most straightforward of the three major vendors to reason about, and the hardest to inventory, because a Bosch part number does not encode which platform the camera rides. This post covers how the platforms work, the exceptions that break the one-version rule, and what to check before you run a campaign.

Firmware ships per platform

Bosch groups every network camera into a CPP generation, and the download area is organized the same way. One platform, one current version. A camera is eligible for whatever its platform is on, and there is no second track to evaluate.

Set against the other two vendors we support deeply, the difference is structural rather than cosmetic:

Vendor	Eligibility decided by	Parallel tracks
Axis	Per product	Active, plus LTS 2024 and LTS 2022
Bosch	Per platform (CPP generation)	None, one current version per platform
Hanwha	Per series or family	None, latest available per family

With Axis the question is what a specific product is eligible for, which is answered on that model’s own support page and nowhere else. The detail is in AXIS OS upgrade paths explained. With Hanwha the question is which series a camera belongs to, covered in Hanwha Wisenet firmware updates at scale. With Bosch the question is which platform, asked once per platform instead of once per camera.

For a large fleet that is a genuine advantage. Twelve platforms is a much smaller problem than five hundred cameras, provided you can answer the platform question at all.

The part number does not encode the platform

This is where Bosch fleets go wrong, and it is worth being concrete. Three cameras that all begin with NDE, all outdoor domes, all in the same FLEXIDOME naming family:

• NDE-8704-R is CPP14
• NDE-5702-AL is CPP14.2
• NDE-3703-AL is CPP14.3

Nothing in those part numbers tells you that. The mapping from model to platform lives in the vendor knowledge base, and reading it off is a manual lookup per distinct model in your inventory. Skip it and you get an inventory organized by the wrong key, which produces a firmware plan that looks complete and is not.

One version per platform, more than one file

The sub-platform numbering is not decoration. CPP14, CPP14.2, and CPP14.3 are all currently on 9.82.0022, and they are three distinct binaries with three different SHA-256 values. The version string is shared. The image is not.

The same pattern holds on the older platforms: CPP6 and CPP7.3 both sit on 7.93.0024, from different files.

Two things follow. First, a fleet report that keys on version string alone will tell you a set of cameras are identical when they are running different code. Second, if your process verifies a checksum before flashing, you need the right checksum for the right sub-platform, and grabbing the one next to the version number you recognize is how a campaign stalls at the verification step.

The exception that breaks the one-version rule

The FLEXIDOME multi 7000i IR (NDM-7703-AL) is a CPP14.1 device, and it is frozen on its own 9.11.x line. Its current firmware is 9.11.0017 from January 2026. It does not receive the 9.8x releases the rest of the CPP14 family gets.

A camera in that position is fully current and simultaneously behind every one of its platform siblings, and both statements are true at the same time. If your standard reads “all CPP14 devices on the current CPP14 release,” this camera fails a check it should pass. If your standard reads “every camera on the newest release available to it,” it passes, correctly.

Write the standard the second way. It is the only phrasing that survives contact with per-platform versioning, and it is also the phrasing an auditor can verify without knowing anything about Bosch.

Platform lifecycle runs in published stages

Bosch retires platforms in named stages with month-level dates: feature development ends, then maintenance ends, then the platform receives security fixes only, then end of service. As of the August 2026 check:

Platform	Stage	What happened and when
CPP16	Current	Feature development active
CPP14 and its sub-platforms	Current	Feature development active
CPP13, including CPP13 moving	Maintenance	Feature development ended June 2025, bug and security fixes only
CPP7.3, CPP7, CPP6	Security only	Features ended May 2022, maintenance ended December 2025, shared 7.9x releases
CPP4	End of service	Reached EOS May 2024, final firmware marked EOS

The “moving” suffix on CPP13 is the designation for moving devices, which is where the PTZ and ruggedized positioning cameras land. It is a separate platform line from the fixed cameras of the same generation, and it has its own current version.

Read the CPP4 row carefully, because that is the one that shows up in real buildings. A DINION IP 5000 HD is a working camera producing usable images today, and its final firmware shipped in 2021 and is marked end of service. No further fixes are coming. That is a replacement decision, not a firmware decision, and it needs to be on a budget line rather than in a maintenance backlog.

What the download area does and does not give you

Bosch publishes checksums for firmware downloads, SHA-256 on the current platforms and SHA-1 or nothing on the oldest ones. That puts Bosch ahead of Hanwha, which publishes none, and roughly level with Axis. If your change process requires integrity verification before a flash, Bosch supports it on anything modern.

What the download table does not carry is release dates. To learn when a version shipped you open that platform’s release letter, which is also where the change list lives. For a single upgrade that is a minor inconvenience. For a fleet report that answers “how old is the firmware on this estate,” it means a PDF per platform per release, read by hand, and it is the reason those reports are usually stale.

Before you start a Bosch campaign

1. Inventory by platform, not by model. Resolve every distinct model to its CPP generation and sub-platform first. Everything downstream keys on that.
2. Look the mapping up, do not infer it. NDE-8704-R, NDE-5702-AL, and NDE-3703-AL sit on three different platforms.
3. Check for held-back models. At least one CPP14 device is frozen on a separate line. Assume there are others and verify per model rather than per family.
4. Match the checksum to the sub-platform. Same version string, different image, different hash.
5. Open the release letter for the date and the changes. The download table will not tell you either.
6. Confirm the platform’s lifecycle stage before you commit to a support horizon. A platform in security-only maintenance is a different promise from a current one, and CPP4 is not a promise at all.
7. Canary one camera per platform, not per model. The platform is the unit that shares an image, so it is the unit that shares a bad image.

Doing this across 500 cameras

Per-platform versioning is a gift at fleet scale and only if the mapping is right. The work is front-loaded into an inventory step that has no shortcut: every distinct model resolved to a platform, every platform to a current version and a checksum, every version to a release letter for its date. Do that once and a five hundred camera estate collapses into a dozen decisions. Skip it and you get a spreadsheet that ages badly from the day it is written, because nothing in the field announces when a platform enters maintenance or when a model gets held back from a release.

MentatNOC keeps the model to platform mapping and each camera’s running version current continuously, flags devices that are behind the newest release available to them rather than behind an unrelated version number, pushes firmware in staged waves with canaries and automatic rollback, and verifies every image’s integrity before it reaches a camera. The write-side detail is on the firmware, password, and certificate actions page, and a staged rollout runs end to end in a live platform demo. The current versions, platforms, checksums, and lifecycle status for common Bosch models, alongside Axis and Hanwha, are published in the camera firmware tracks reference.

Map the models to platforms, verify per model rather than per family, match the checksum to the sub-platform, and check the lifecycle stage before you promise anyone a support horizon. Bosch fleets are the cleanest of the three to run once that mapping exists, and the easiest to misreport while it does not.