The Support Date Behind the Serial Number: Keeping Legacy Security Systems Defensible in 2026

Security systems rarely fail in a dramatic way. A camera keeps recording, an access-controlled door keeps opening, and an alarm panel keeps arming. The trouble is that a device can remain operational long after it has become unsupportable. In 2026, that gap between working and supportable is exactly where audit findings, insurance queries and cyber risk tend to gather.

The immediate temptation is to say that the kit still works. It may well do. But an auditor is less interested in whether a camera produces a picture than in whether the organisation knew the device was out of support, understood the exposure and had a plan. A failed penetration test, a firmware advisory or a shortage of spare parts turns a quiet technical fact into a governance problem.

Operational is not the same as supportable

End-of-life and end-of-support are often used interchangeably. They are not the same. A product may still be sold, still receive security patches, or be supported only through a third-party maintenance arrangement. The relevant question is what the manufacturer and integrator will commit to in writing. When did security updates stop? When do spares run out? Is the firmware still receiving fixes, or is the installed version several releases behind? Does the vendor have a published support statement, or is the position known only through an account manager?

An auditor does not need to be a technologist to ask those questions. They need to see that someone in the organisation can answer them. The absence of a support date is not a neutral gap; it is an unmanaged risk.

The register: fields that earn their place

An obsolescence register does not need to be complex, but it does need to be controlled. A spreadsheet is acceptable if it has an owner, a review date and version history. One row per device, or per group of identical devices, should capture:

• Asset reference, location and system served.
• Manufacturer, model and serial number.
• Installed firmware or software version and the date it was last updated.
• Vendor end-of-sale, end-of-support and end-of-life dates, with the source of that information.
• Known vulnerabilities or advisories relevant to the installed version, and how they are monitored.
• Availability of spares, including lead times for critical components.
• The maintaining integrator, contract reference and escalation route.
• Network dependencies, remote access arrangements and any internet exposure.
• Compensating controls already in place, such as network segregation or enhanced monitoring.
• A named owner and the next review date.

The register should also record what is not known. A blank support date is a finding in its own right. It tells the organisation where to direct questions before an auditor or insurer does.

Scoring risk without over-engineering

A register becomes useful when it supports a decision. A simple likelihood-and-impact score is usually enough. Likelihood rises where firmware is unsupported, remote access is poorly controlled, spares are unavailable or the device is exposed to a network. Impact rises where the system protects a high-risk area, supports statutory obligations or would cause significant disruption if it failed.

The score should not be used to justify doing nothing. Compensating controls can reduce risk while replacement is planned, but they do not turn unsupported kit into supported kit. The register should show the control, the residual risk and the date by which the replacement decision will be taken. That is the difference between a temporary mitigation and an indefinite exception.

From register to replacement case

Finance teams are often presented with a technology refresh case that speaks in model numbers and feature sets. A stronger case speaks in operational continuity, risk reduction and cost of inaction. The evidence is already in the register: support dates that have passed, spares that are no longer available, advisory notices that cannot be patched, and systems that are increasingly expensive to maintain.

A rolling replacement programme is easier to fund than a panic purchase. It spreads capital and operational disruption, allows procurement to align with support dates and gives operations time to plan downtime. The case should set out options: like-for-like replacement, a phased upgrade, or a managed service where that genuinely transfers maintenance risk. It should also identify the cost of failure, including unplanned outage, insurance conditions, audit findings and the staff time spent maintaining ageing kit.

Governance and evidence

The register should be reviewed quarterly and whenever a significant change occurs: a new vulnerability, a failed test, a contract renewal or a change of integrator. Procurement should require support dates and end-of-life statements in new contracts, not just at handover. When a system is replaced, the register should be updated with the decommissioning date and evidence that data has been handled appropriately.

The auditor is not asking whether the organisation has old equipment. Most estates do. They are asking whether the organisation knew, whether it assessed the risk and whether it acted. A maintained obsolescence register, with a funded plan behind it, is a defensible answer.