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.
Of the neighbouring disciplines, this is the one with the most genuine overlap, and the one where the honest answer is most often "you may not need a separate programme".
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. If you have one deployed and it covers the sites where your cameras are, a large part of the discover and identify stages is done.
Where the overlap stops#
Three gaps, in increasing order of how much they matter.
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.
Firmware version is the weak field. Passive fingerprinting identifies manufacturer reliably and model usually. Firmware version, which is what actually 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 where the version field is mostly empty cannot drive vulnerability assessment.
Ownership and remediation are out of scope by design. These platforms are detection and monitoring products. They will tell you a camera is running vulnerable firmware. They will not tell you 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 has credentials for it. That is the part of the problem that determines whether anything actually changes, and it is organisational.
The distinction that actually 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 not a scattering of IoT devices. It 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 is not one more IoT device; it is the thing that holds the credentials for four hundred of them and months of footage.
Treating that estate as a system changes what you do: you go to the VMS first for inventory rather than to a network sensor, you treat the recorder as a high-value asset rather than as a peer of the cameras, and you address remediation through the maintenance contract rather than through a change ticket.
Physical-security convergence#
There is a second overlap worth naming. 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 in scope for that reason: the boundary that matters operationally is "systems the physical-security function owns and IT does not", 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#
If an IoT or OT security platform is deployed at every site that has cameras, resolves firmware version for most of the estate, and its findings reach someone who can act on them through a contractual route that exists — the scope is covered. Use 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.
| IoT / OT security platform | Video ASM | |
|---|---|---|
| Discovery method | Passive network monitoring | VMS, switch, DHCP, documentation, then active |
| Coverage limit | Where sensors are deployed | Where an authoritative source exists |
| Firmware version | Often unknown | Treated as the field that must be chased |
| Unit of concern | The device | The estate as a system, with the recorder as its centre |
| Remediation | Out of scope | In scope, and mostly contractual |
| Access control and intercoms | Sometimes | Explicitly in scope |