Video ASM and IoT security

IoT and OT security platforms already discover cameras, often well. The gap is not detection: it is that video estates arrive with an owner, a contract and an operational constraint that generic IoT programmes are not built around.

Version

1.0

Status

Draft for comment

First published

5 September 2026

Revised

5 September 2026

Of the neighbouring disciplines this is the one with the most genuine overlap, and the one where the answer is most often "you may not need a separate programme". This document states what those platforms already cover, the three limits of that coverage, and the conditions under which a separate programme is unnecessary.

Requirement keywords (SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY) are used throughout with the meanings fixed in the framework, clause "Normative language".

What IoT and OT security programmes already do#

Vendors in this market, variously labelled IoT security, OT security, XIoT, or cyber-physical systems protection, built their products around a real problem: industrial and embedded devices that cannot run an agent, cannot tolerate active scanning, and were never in the CMDB.

Their standard approach is passive network monitoring. A sensor watches traffic, fingerprints devices from their protocol behaviour, and builds an inventory without touching anything. For cameras this works well. Video devices are chatty, they speak identifiable protocols, and their traffic patterns are distinctive. A competent IoT security platform will find the camera estate, and will usually classify it correctly at manufacturer level.

Several of these platforms explicitly market camera and physical-security discovery. Where one is deployed and covers the sites where the cameras are, a large part of the discover and identify stages is done.

The limits of that coverage#

Three limits, in increasing order of how much they matter.

1. Coverage follows the sensor. Passive monitoring sees the segments it is deployed on. Video estates are distributed to exactly the places that do not have a monitoring sensor: branch sites, remote buildings, car parks, standalone recorders in a cupboard. The inventory is excellent where there is a sensor and empty where there is not, and the tool cannot report the difference, which is the same failure mode as CAASM arriving by a different route.
2. Firmware version is the weak field. Passive fingerprinting identifies manufacturer reliably and model usually. Firmware version, which is what determines vulnerability exposure, is frequently not derivable from traffic. Some platforms obtain it through active queries or integrations; many report it as unknown, and an inventory whose version field is mostly empty cannot drive vulnerability assessment.
3. Ownership and remediation are out of scope by design. These platforms are detection and monitoring products. They will report that a camera is running vulnerable firmware. They will not report that the device is covered by a maintenance contract with an integrator who has to perform the update, that the update requires a lift, or that nobody in the organisation holds credentials for it. That is the part of the problem that determines whether anything changes, and it is organisational.

The distinction that matters#

Generic IoT security treats a camera as one instance of "embedded device on the network". That framing is correct technically and wrong operationally.

A video estate is a system: procured as a system, maintained under one contract, managed through a central platform, with a coherent set of credentials and a single point, the VMS or recorder, that holds access to all of it. The recorder holds the credentials for four hundred of the cameras and months of footage, which places it in a different class from the devices it records.

Treating the estate as a system has three consequences for method: inventory is taken from the VMS before a network sensor, the recorder is treated as a high-value asset rather than as a peer of the cameras, and remediation is addressed through the maintenance contract rather than through a change ticket.

Physical-security convergence#

A second overlap is in scope here. Access control, intercoms and alarm systems are typically installed by the same integrator, on the same network segment, under the same contract, and sometimes through the same management platform. Several access-control vendors are also video vendors.

The framework includes these systems for that reason. The boundary that matters operationally is "systems the physical-security function owns and IT does not", and not "devices that carry video". An organisation solving this for cameras and not for the door controllers on the same VLAN has solved half of one problem.

When a separate programme is unnecessary#

A separate programme is unnecessary where all of the following hold:

1. an IoT or OT security platform is deployed at every site that has cameras;
2. it resolves firmware version for most of the estate;
3. its findings reach someone who can act on them through a contractual route that exists.

Where all three hold, the scope is covered and a separate programme SHALL NOT be required by this specification. The test to apply is the maturity model's evidence tests rather than the label.

In practice the first condition is the one that fails. Sensor coverage tracks where the security budget went, and video estates are concentrated where it did not.