How this site sources what it publishes

What we will and will not assert, and what happens when we get something wrong.

Published 5 September 2026

Most of what is written about video-security cybersecurity is either vendor marketing or a restatement of the same handful of incidents. Both are easy to produce and neither is much use to someone who has to make a decision about an estate. These are the rules this site works to.

What counts as a source#

In descending order of weight:

Primary technical specifications. RFCs, the ONVIF specifications, published protocol documentation. Where a page describes how a protocol behaves, the specification is the authority, not a summary of it.

Vendor documentation and advisories. For anything vendor-specific — default ports, firmware delivery, lifecycle policy, security architecture — the vendor's own current documentation, cited by URL. Vendor claims about their own products' security posture are reported as claims.

Government and coordinating bodies. CISA, NIST, national CERTs, the CVE Program's own records, regulatory and legislative text. For legal and procurement questions, the instrument itself rather than a commentary on it.

Vulnerability databases. NVD for CVE records, the CISA KEV catalogue for confirmed exploitation, FIRST EPSS for modelled exploitation probability. Each is dated where used.

Peer-reviewed and conference research, and scanning data from organisations that publish their method.

Security-vendor blog posts are used where they contain original research, and identified as belonging to a company with something to sell.

What we do not publish#

Numbers we cannot trace. "Over 80% of camera deployments use default credentials" is the kind of statistic that circulates for a decade without anyone locating its origin. If we cannot get to the study, the sample and the date, the number does not appear.

Rounded or re-stated figures. A published count is quoted as published, with what was counted and who counted it. Where the only available figure is old, the page says how old.

Invented specifics. No fabricated CVE identifiers, port numbers, firmware versions, product names, dates or quotes. This is stated explicitly because the failure mode is now common: text that is fluent, plausible, correctly formatted and wrong.

Fabricated social proof. No invented testimonials, customer logos, case studies, adoption figures, or claims about who uses this site.

Personal bylines we cannot stand behind. Pages here carry a publication date, a last-checked date and a source count rather than an author's name. An invented byline would be the same category of error as an invented statistic.

How uncertainty is recorded#

The subject has real gaps, and the gaps are frequently the most useful thing on a page.

Where something could not be established, the page says so and says what was tried. During the research for this site, several vendors' published lifecycle policies could not be read at all — one is an image-only scan with no extractable text, another is served behind bot mitigation that returns an empty body to automated clients. In both cases the honest statement is "we could not read this", which is different from "this does not exist", and the pages say the former.

Where a claim rests on inference rather than evidence, it is marked as inference. Where a commonly-repeated fact could not be confirmed against a primary source, it is either omitted or labelled unconfirmed.

How claims are checked#

Every factual claim in the foundational material on this site was drafted against a named source and then independently checked by a second reader whose instruction was to refute it: fetch the cited source, confirm it exists, and confirm it specifically supports the claim as worded rather than merely being on the same topic.

That process removed or corrected roughly one claim in five. The failures were mostly not inventions — they were claims that were nearly right: a figure rounded, a date shifted by a year, a capability attributed to the wrong vendor in a family, a source that discussed the topic but did not state the specific thing being cited to it. Those are the errors that survive casual review, which is why the check is adversarial rather than confirmatory.

Dates and decay#

Every page carries a publication date and a last-checked date. They are different fields on purpose.

Much of this subject decays quickly. Vendor advisory URLs move. Lifecycle policies are revised. A vulnerability that was theoretical acquires an exploit. Regulatory instruments come into force in stages. A page last checked eighteen months ago should be read as an eighteen-month-old observation, and the date is there so you can.

Where a page states something as true "as of" a date, that phrasing is deliberate and the date is the date it was verified, not the date it was written.

Corrections#

If something here is wrong we would rather know.

Corrections that change a factual claim are made in the page and the last-checked date is updated. Where a correction materially changes what the page said — not a typo, but a claim that was wrong — the change is noted on the page rather than made silently.

The most useful thing you can send is a source. The second most useful is a specific quotation of what is wrong, rather than a general assertion that a section is misleading.

Corrections and source disputes: editor@videocybersecurity.com

Three sister sites cover adjacent ground, and are linked from pages here only where the link is genuinely the next thing a reader would want:

CameraRisk holds the published vulnerability history of individual products, generated from NVD, CISA KEV and EPSS. VideoSOC publishes advisories and tracks what is currently being exploited. VideoASM is a framework for managing a video estate's attack surface as a programme.

They share sourcing standards with this site. They are not mirrors of it, and none of them republishes this site's material.