Video ASM and attack surface management

Attack surface management is the parent discipline. The difference is not method; it is which assets end up in scope, and why video assets usually do not.

Version

1.0

Status

Draft for comment

First published

5 September 2026

Revised

5 September 2026

Attack surface management is not a new idea and Video ASM does not claim to improve on it. The method — enumerate what exists, work out what is exposed, reduce it, repeat — is the same method. What differs is which assets a programme actually ends up holding, and the reasons video assets tend not to be among them are specific enough to be worth naming.

The three neighbouring terms#

The market uses three overlapping labels, and they are worth separating before comparing anything to them.

EASM — external attack surface management looks inward from the internet. It starts from domains, IP ranges and certificates, and asks what an unauthenticated outsider can see. It is discovery without prior knowledge, which is its strength: it finds things you did not know you had.

CAASM — cyber asset attack surface management works from the inside out. It aggregates what your existing systems already know — the EDR console, the cloud provider, the CMDB, the identity provider — into one asset view, and finds the gaps between them.

ASM is used both as the umbrella term and, loosely, as a synonym for whichever of the two a given vendor sells.

Where each one lands on video#

EASM will find some of it, and misleadingly. An internet-exposed camera or recorder is exactly the kind of thing external discovery is good at spotting. But most video estates are not internet-exposed in the inbound sense, and the parts that matter most — the recorder holding credentials for four hundred cameras, the VMS server on the corporate network — are invisible to it. Worse, the outbound cloud connectivity that most modern cameras maintain is not an external attack surface in the EASM sense at all, so a clean EASM result says very little about this asset class.

CAASM will find video assets only if something already knows about them. This is the decisive limitation. CAASM's value comes from correlating existing sources, and video devices are characteristically absent from all of them: they run no agent, they are not domain-joined, they are not in the CMDB, they were not procured through IT. A CAASM platform integrating six excellent data sources will produce a confident, complete-looking asset inventory with the camera estate missing, and nothing in the tool will indicate that anything is absent.

That is the real problem, and it is not a tooling defect. It is what happens when a correlation-based approach meets a population that appears in none of the inputs.

So what is different#

Three things, none of them methodological.

The discovery sources are different. For video estates, the richest sources are not the ones an ASM programme normally integrates: the VMS's own device list, PoE port status on the access switches, and the integrator's commissioning documentation. The framework's discover stage treats these as primary rather than supplementary, which is a genuine departure from how ASM discovery is usually configured.

Identification is unusually hard. In general IT, an agent or a credentialed scan gives you manufacturer, model, OS and patch level reliably. Here, firmware version is inconsistently exposed, often requires authentication with credentials nobody holds, and is formatted differently across firmware branches of the same product. An ASM programme that assumes identification is a solved problem will produce an inventory whose most important field is mostly empty.

Remediation is contractual. Patching a server is an internal decision. Patching a camera may require a third party under a maintenance agreement written before anyone thought about this, a technician on site, and acceptance of the risk that the device does not come back. Prioritisation that ignores this produces queues nobody works.

When you do not need Video ASM#

This matters more than the differences, and a category page that omitted it would be advertising.

If your ASM or CAASM programme already ingests the VMS device list, resolves model and firmware for the camera estate, and assigns those devices an owner who can actually change them — you are doing Video ASM. The label is unnecessary. Check the maturity model's evidence tests rather than the label: if you can pass them, the scope question is settled.

The term is only useful where the answer to "does your asset inventory include the cameras" is no, or is unknown.

The honest summary#

Video ASM is a scoping argument, not a new discipline. If your attack surface programme has the cameras in it, you do not need the term. Most do not.