Security camera end of life: selling the refresh

A security camera reaches end of life when its manufacturer stops releasing firmware for it, so any vulnerability found in that model from then on stays unfixed. For an integrator, end-of-life cameras are the most defensible replacement project there is: the reason to replace them is published by the manufacturer, not invented by the salesperson.

Most CCTV refresh conversations go badly because they start with “these cameras are old.” Old is not a reason. A seven-year-old camera on supported firmware that has never dropped offline is doing its job. A three-year-old model the manufacturer stopped supporting last spring is not. The refresh quote that holds up is built camera by camera, from support status, vulnerability exposure, and failure history.

End of sale, end of support, end of life

Manufacturers use these terms differently, and customers mix them up. Define them in the proposal.

Term	What it means	What the customer should do
End of sale (discontinued)	The model can no longer be bought new	Nothing urgent. Plan spares and the next model for expansions
Support ending	Firmware still ships, with a published end date	Put the model in the next budget cycle
End of support or end of life	No more firmware, including security fixes	Replace on a schedule, starting with exposed or failing units

Each vendor runs its own lifecycle. Axis commits to software support for at least five years after a product is discontinued and publishes the end date on each product page. Bosch moves platforms through published stages, from feature development to maintenance to security fixes only, with dates per platform. Hanwha states a policy of security firmware for up to five years after end of life but does not publish per-model dates. Current tracks and dates for the three are on the camera firmware tracks page.

Why end of support matters to the customer

A customer will ask why a working camera needs replacing. These are the answers that hold up.

Unfixed vulnerabilities. Once firmware stops, any new vulnerability found in that model stays open for as long as the camera is on the network. Published camera vulnerabilities, and which ones are known to be exploited, are on the camera CVE tracker.

Audit and insurance questions. Auditors and cyber insurers ask whether network devices run supported software. A camera fleet with unsupported models is a finding the customer has to explain, or a control they cannot claim.

Compatibility drift. VMS updates, certificate requirements, and network security changes move forward. A camera frozen on old firmware falls further behind each year, until a routine change elsewhere breaks it.

Failure history. End-of-life cameras are often also the ones at the bottom of the uptime list every month. When support status and failure history point at the same camera, that camera goes at the top of the quote.

Build the refresh quote camera by camera

A refresh quote that names every camera, with its reason, gets approved. One that says “replace 140 cameras” gets cut in half or deferred.

1. List every camera’s model and firmware. From the devices, not the as-built.
2. Mark support status per model. Supported, support ending with a date, or support ended.
3. Add exposure. Cameras on models with published vulnerabilities, and especially those in CISA’s Known Exploited Vulnerabilities catalog, go first.
4. Add failure history. Cameras with repeated offline events or storage failures over the last few months move up.
5. Weight by location. Entrances, cash handling, and anything a regulation names outrank a storage-room camera.
6. Phase it. Group by site and by budget cycle. A refresh spread over two or three cycles gets approved more often than one large ask.

Each phase should show the cameras, their reason for replacement, and the replacement model. Reuse mounts and cabling where the new model allows, and say so. It lowers the cost and shows the customer the integrator is not replacing anything that does not need it.

What not to do

Do not replace supported, healthy cameras to make the project bigger. The customer will find out the first time someone checks a model number against the manufacturer’s site, and every future refresh quote will be read with suspicion.

Do not leave end-of-life cameras off the report because the customer has no budget this year. Report them every month with their status. When budget opens, the list is already agreed.

Doing this across 500 cameras

For a few dozen cameras, an integrator can check each model on the manufacturer’s site once a year. Across hundreds of cameras and several brands, support dates move, new models get discontinued, and the list is out of date before the budget meeting.

MentatNOC is a white-label managed services toolkit for security integrators. It tracks firmware eligibility and lifecycle for every Axis, Bosch, and Hanwha camera under management, alongside its uptime history, so support status and failure history sit in one record. Firmware for supported models goes out in staged waves with automatic rollback, which keeps supported cameras supported. It monitors device health, not video.

Added to the service contract and bundled with the monitoring the integrator already sells, it also covers the aging cameras while the replacement budget waits. When one dies, a classified ticket lands in the integrator’s own ticketing system under their own SLA, the tech arrives with the replacement model, and the integrator has usually called the customer before anyone on site noticed. Uptime history is covered in camera uptime reporting, the layers are on the platform overview, and the live demo shows firmware status across a 500-camera fleet.