Cloud video security

What a cloud video deployment commits you to, from a vendor support account with fleet-wide reach down to a relay that treats a serial number as identity.

A camera holding an outbound session to its manufacturer's infrastructure is doing something your inbound firewall rules cannot describe and your port-forward audit will never find. The packaging varies enormously: at one end a platform where storage and the user directory belong to the vendor, at the other an on-premise recorder whose only cloud element is a relay an installer switched on at commissioning. Two questions run through both. What has the estate agreed to trust, and who inside that vendor can act on the agreement?

From tenancy to relay#

At the VSaaS end, video is written to vendor storage, users authenticate against a vendor directory, and vendor staff have a path into the tenancy by design; that path is the support model. At the relay end, the recorder keeps every byte locally and reaches out only so a phone app can find it through NAT. That is a far smaller commitment, though still a standing outbound association between your camera VLAN and a vendor service, configured on the device rather than on the network, which is why it survives firewall reviews.

Neither end shows up in the router: a port-forward review and an external scan of the site's public IP both come back clean on an estate fully reachable through the vendor's cloud. The mechanics, including Hikvision's platform-access port list, are in how cameras become internet exposed; the one place a relay is visible and blockable is egress policy on the camera VLAN.

What a tenancy adds on top of the relay is a copy of the video and a directory holding your users, with a vendor-side administrative plane over both: the software that would otherwise be your VMS now runs under a support process you do not see.

Who at the vendor can see your video#

According to the FTC's complaint against Verkada, filed 30 August 2024, an intruder obtained "Super Admin" privileges on a Verkada support account through a security vulnerability in the company's customer support server, then used the Command platform to reach "over 150,000 live customer cameras". The complaint dates this to 8 March 2021; Verkada's own security-update page logs the incident as 9–10 March 2021. The complaint specifies what was viewed: patients in psychiatric hospitals and women's health clinics, young children playing inside a room, incarcerated persons in their cells. Exposed data is listed as including usernames and password hashes, site floorplans, audio recordings, video archives and Wi-Fi credentials, and the complaint alleges the compromise "allowed the intruder to have unfettered access to Defendant's entire network". On attribution it says only "another threat actor"; no primary source establishes who was responsible.

Nothing in that sequence is a camera defect. It is a support account, cheap to run precisely because one of them reaches many customers at once.

An earlier detail in the same complaint matters as much. In December 2020 a threat actor exploited a legacy firmware build server "after an employee failed to restore the original security settings" and installed Mirai on it; Verkada did not know until AWS security flagged the activity "more than two weeks later", and because of "Defendant's logging failures" the forensics firm "was unable to determine affirmatively if the threat actor had accessed or exfiltrated any data residing on the server."

The $2.95 million civil penalty announced on 30 August 2024 was for the CAN-SPAM allegations; the data-security allegations were resolved by injunctive relief. It is widely and wrongly reported as a fine for the camera breach.

Device identity and account binding#

Dahua's manual is candid about what enabling P2P transmits: "The information of the IP address, MAC address, device name, and device SN will be collected." A user can decline that collection, which in practice means declining the feature. Those four fields are the identity a cloud account binds to, and the serial number is the one addressable from outside your network. The same manual's cybersecurity appendix tells owners to "disable the port mapping function of the router to avoid direct access to the intranet devices from external network", advice the P2P feature makes moot by removing the need for port mapping at all.

Hunt.io's "Operation CameraSwarm", disclosed 18 August 2026, ran 35 days from 17 June to 22 July 2026 and compromised more than 14,530 Dahua cameras. Most of it was unremarkable. Credential brute-force accounted for 12,324 unique IPs on TCP 37777, and the CVE-2021-33044/33045 authentication-bypass chain for another 1,923. The remaining 283 arrived through the Easy4IP P2P relay at easy4ipcloud.com:8800, a path needing a device serial number and no routable address at all. Hunt.io reports that 89.4% of live serials required no authentication through that relay.

So the question of what stops a serial number being claimed by the wrong party has a measured answer for one vendor's relay on a dated sample: nothing, 89.4% of the time. The brute-force half of that campaign is a password problem, and every credential control you already run bears on it. The relay half sits on the vendor's side of the boundary, where the only lever you hold is whether the feature is enabled at all, making it an ordinary device hardening decision taken by whoever commissioned the site. Two things the vendor material still does not say: how an existing binding is revoked, and what happens to it when a device changes hands.

When the vendor has nothing to tell you#

You cannot patch what you do not operate, so buying cloud video means depending on the vendor's disclosure practice. As of 5 September 2026 it varies sharply. Verkada, the largest cloud-native vendor in the set, is not a CVE Numbering Authority; the CVE Program's partner list returns no match, and there is no discoverable advisory page. Its only security-notice surface is an incident and compliance log: the March 2021 entry, a December 2021 Log4j statement, a September 2025 ISO/IEC 27701 certification.

Motorola Solutions is likewise not a CNA, and Avigilon's advisories live inside product documentation: 216 entries back to 2020, keyed to internal ticket numbers, with zero CVE identifiers on the index. They cover the Alta Video hosted line. We found no public advisory listing for Avigilon Unity or Avigilon Control Center, the on-premise line, and whether any sit behind partner authentication is unknown.

Genetec separates registration from readability. It is a CNA under both the Vendor and Hosted Service types, and its per-advisory pages exist: CVE-2026-55727, CVE-2026-40619 and CVE-2025-43027 each have one, scored CVSS 7.5, 7.8 and 9.8. The index it registered with the CVE Program does not. That URL 301-redirects twice into a generative-AI-backed resource-hub search for the word "vulnerabilities", returning "Showing 1-10 of 26 results" of mixed content under a banner warning that "Results may be incomplete." No ID, severity or date columns, so an advisory is reachable only if you already know the CVE ID you want. Which video vendors publish security advisories has the full comparison.

Questions worth asking a cloud video vendor#

On-premise recording fails visibly: a disk fills, or a recorder drops off the network and someone notices. A cloud dependency can fail as a billing event, with the same evidential consequence. Ask these in writing, before signature.