End-of-life cameras and cyber risk

Lifecycle position decides whether a finding has a fix at all, and the five published policies we could read disagree on almost every term they use.

CISA's Known Exploited Vulnerabilities catalog carries a required-action field, and for most of the 1,695 entries in version 2026.09.04 it tells you to apply the vendor's fix. Eighty-three entries carry end-of-life or end-of-service language in that field instead. Five of the 83 are video devices: NUUO's NVRmini and NVRmini2 (CVE-2018-14933, CVE-2022-23227), both Reolink entries (CVE-2019-11001, CVE-2021-40407) — all four added on 18 December 2024 — and D-Link's DCS-930L camera. For several of them the action CISA states is to stop using the product because it has reached end of life. The remediation is a purchase order.

That is the same defect class you would triage in an afternoon on a supported model, turned into a capital problem by nothing but the date the vendor stopped shipping the thing. Which is why lifecycle position, and not CVSS, is usually the first field worth filling in on a camera asset register. The field has no agreed units.

Three clocks, and no shared vocabulary#

Bosch's IP Video Firmware Info Brief separates three transitions where the other policies we fetched publish one, and each of the three means something different to a security team. No other vendor policy we fetched uses that scheme.

A spreadsheet column headed "end of support", populated from the five vendors above, is holding five different quantities. One of them is not a date at all.

What the published policies commit to#

Read the qualifier, not the headline number. Two of the qualifiers below are the policy.

The two that swallow their own headline are Dahua's and Hanwha's. Dahua's clock starts at first shipment for sale, so a model bought late in its sales life can arrive with almost none of the two years left, and nothing on the datasheet tells a buyer where in that run they are standing. Hanwha's five years are real but conditioned: in the Continuous Firmware Improvement Phase the company provides improved firmware "if a serious security vulnerability is reported", and the seriousness judgement is the vendor's. Both are procurement questions, not renewal questions. Which event starts the clock, and is the tail conditional? "Five years from first shipment for sale" and "five years from discontinuation" are not comparable offers, and only one vendor here puts the condition on the tail in writing, which is more than most.

Hanwha's document is unusual in a second way: its own revision history records the commitment being redefined twice. V2.0, dated 23 October 2019, replaced "Support for 5 to 10 years" with "Support for 5 years after product discontinuation". V2.1, on 22 March 2021, restated it as "Support up to 5 years after product discontinuation". Moving the anchor from release to discontinuation favours buyers of a long-shipping model. It also means the end date cannot be known at the point of purchase, because the discontinuation has not happened yet. You are signing for a window whose closing date the vendor will set later.

Hanwha publishes a newer version, V3.2, filename-dated 10 January 2025. It is an image-only scan with no extractable text, so what V3.2 changed is not established here.

The policies we could not find#

Hikvision's published lifecycle and firmware-support duration could not be established. Its cybersecurity pages sit behind a JavaScript bot-protection interstitial that returns HTTP 200 with a challenge page rather than the document, so a successful status code on those URLs proves nothing about retrievability. For VIVOTEK, i-PRO, Verkada and Uniview, no public end-of-life or product-lifecycle policy appeared on any page we fetched on 5 September 2026. We did not exhaustively crawl those sites, so that is not proof no policy exists. It is still the fact a buyer has to work with: a support window a buyer cannot locate during procurement cannot be priced into the purchase.

The Hikvision gap is the expensive one. The manufacturer whose support window we could not retrieve is the same one CISA added to its exploited-vulnerabilities catalog in March 2026 over CVE-2017-7921, a nine-year-old improper-authentication flaw still working against firmware builds from 2014. An operator holding cameras of that vintage has nothing retrievable from the vendor telling them whether those cameras sit inside a support window at all, which is precisely the question a KEV listing forces.

UK law bears on this directly. Since 29 April 2024 the PSTI regime (S.I. 2023/1007) has required a published minimum security-update period for internet-connectable products, network cameras, NVRs and DVRs are not among the categories excepted by Schedule 3, and what Schedule 1 obliges is publication of the period rather than any particular length. We found no enforcement action against a camera or recorder manufacturer under it.

Whether the defect gets a number at all#

A discontinued product's CVE eligibility is set by a scope statement its vendor filed with the CVE Program, and those statements disagree — Axis and Hanwha include end-of-life products, Dahua and Milestone exclude them. The scopes are set out side by side in which video vendors publish security advisories. What follows for an asset register is that anyone measuring a model's risk by counting CVEs against it is measuring the assignment policy, not the software.

When the platform outlives the policy#

Bosch publishes per-platform dates, which makes the gap between service life and supported life measurable rather than anecdotal — and the numbers do not behave like a policy. In the edition published 20 February 2026, CPP-ENC shows end of feature development in 10/2014 and end of service in 03/2026: eleven years and five months of firmware support after the last feature landed, finishing on version 5.97. CPP4 stopped features in 05/2019 and ended service in 05/2024. Five years, on a platform whose feature development stopped four years and seven months later than CPP-ENC's. CPP3 cameras and encoders spent roughly two months between end of feature development (10/2018) and end of maintenance (12/2018) before dropping to security fixes only, then ran on to 12/2023 at firmware 5.75.

Nothing in the published language predicts an eleven-year platform or a five-year one, and nothing about a platform's age predicts which of the two you have bought. Bosch defines a platform by its system-on-chip, so a camera bought recently can inherit an old clock; the delivery mechanics behind that are in camera firmware and the patching problem. The Info Brief is a living document versioned by publishing date alone, so re-fetch before quoting a row. CPP-ENC's 03/2026 end of service has already passed.

When replacement is not funded#

The FCC's July 2026 import and marketing prohibition does not reach equipment already installed; what forces removal is contract and grant eligibility under FAR 52.204-25(b)(2) and 2 CFR 200.216. Those are set out in procurement rules that now govern surveillance equipment.

Where the budget is not there this year, the work is to change what the device can reach and what reaches it. Put the unsupported estate on its own segment with an explicit egress policy rather than a shared VLAN — see segmenting a camera network — and treat every one of those cameras as an untrusted endpoint that happens to be inside the building. Re-rank the backlog by remediability rather than severity: a CVSS 7.5 with no patch path outranks a 9.8 with a released fix, because only one of them can be closed. That inversion is the practical core of camera vulnerability management on a mixed-age estate.

Then put a date in the capital plan. Not the warranty expiry: the earlier of the platform's published end of service and the point at which the vendor's own CVE scope stops covering the product. After that second date, the absence of bad news about your cameras means nothing at all.