ONVIF security

Where ONVIF sets a requirement, where it sets only a recommendation, and where that difference shows up on a real network.

ONVIF's own FAQ draws the boundary more sharply than any outside critique manages. The specification "does not make any claims about the quality of the products," and its scope is "the interface standardization of the network layer of IP security devices." A camera carrying a Profile T logo has shown that its SOAP endpoints answer the way the document says they should, and nothing else. Procurement reads the logo as a security signal anyway.

The conformance regime#

ONVIF was founded in 2008 by Axis, Bosch Security Systems and Sony. Core, Security Configuration and Security Baseline come from its Technical Committee, which "drives the development of ONVIF core specifications as well as the technical direction and roadmap"; the profiles and the test tools that gate the logo come from the Technical Services Committee.

Conformance is self-declared. ONVIF's October 2025 membership matrix lists "Ability to self-declare conformant products" as a benefit of the Full ($20,000/yr), Contributing ($10,000/yr), Registered Affiliate ($5,000/yr) and User ($4,000/yr) tiers; the $500/yr Observer tier gets the conformance tools and the member logo but may not self-declare or use profile logos. The vendor runs the tool and posts the result, and that deck describes no third-party lab step anywhere in the process it sets out. Conformance is also tied to "a particular product and firmware/software version", so a listing tells you about the build that was tested, not about the firmware shipping on the unit you are being quoted three years later.

Whether the test tool checks any security property at all — whether a device rejects a replayed token, or enforces the default access policy — we could not establish. Test specifications for Advanced Security (v17.06) and Security Configuration (v20.06, v20.12) sit on onvif.org as PDFs; we did not read them.

A smaller tell sits in the same materials. The mission page claims "more than 35,000 profile conformant products"; the October 2025 overview deck says "33,000+" on one slide and its own timeline marks 30,000 at 2024. We are not publishing a figure, because none of those is dated or reconciled. A body that cannot make its conformance count agree across two of its own documents is the body whose logo procurement is reading as assurance.

The profile set#

Three add-ons sit alongside: TLS Configuration, Media Signing (Release Candidate) and the Profile V Security Add-on (Release Candidate). ONVIF is retiring S explicitly on authentication grounds — the 9 October 2025 announcement says it "specifies authentication mechanisms that are no longer consistent with current cybersecurity recommendations" — while stating that the deprecation "has no effect on the operation of deployed Profile S-based systems."

Profile S v1.3 (November 2019) shows why. Its device table lists "WS-Usernametoken Authentication — Core — M" and "HTTP Digest — Core — O", making the weaker mechanism the mandatory one, while §7.1.4 makes both mandatory for clients. A Profile S client must speak Digest; a Profile S camera need only accept UsernameToken. A full-text search of that specification returns zero hits for "TLS". Profile T v1.0 inverts the device requirement, mandating Digest and dropping UsernameToken, but leaves transport conditional: "Streaming over RTP/RTSP/HTTPS/TCP" is marked C, "If supported, device shall be able to...". Moving a fleet from S to T upgrades the credential mechanism and encrypts nothing by itself.

The authentication mechanisms#

That "legacy devices" wording is older than the deprecation it appears to anticipate: it is present verbatim in ONVIF Core v21.06, June 2021, four years before the Profile S announcement. Core was calling the mechanism legacy while the profile carrying ONVIF's largest installed base went on making it the one thing a camera had to support.

Core v26.06 §5.9.1 concedes the position in its own normative text: "Both digest authentication and WS-Security provide only a rudimentary level of security. In a system where security is important, it is recommended to always configure the device for TLS-based access." Section 5.9.2 does it again for SCTP, where authentication uses a WS-Security BinarySecurityToken that the spec itself says "does not provide security" and "should never be used without TLS." Digest's default hash is MD5 under Core Table 6, and what a captured challenge and response are then worth is worked through on RTSP security.

WS-UsernameToken carries a problem no implementation fixes. OASIS states that wsse:PasswordDigest "can only be used if the plain text password (or password equivalent) is available to both the requestor and the recipient," and that absent a secured channel "the digest offers no real additional security over use of wsse:PasswordText." A camera that mandates it cannot store a salted hash, so a firmware dump yields working credentials rather than hashes to crack. Core §5.9.5 makes the replay defence a requirement — "The server shall reject any Username Token not using both nonce and creation timestamps" — but nonce-cache enforcement is the implementer's problem, and CVE-2022-30563 (CVSS 3.1 7.4, Dahua, 28 June 2022) is that gap realised; the replay thirty hours later from a different address is on NVR security.

Core §5.9.4 then defines an access class, PRE_AUTH, for which "The service shall not require user authentication." Table 7 gives it the only mark in the Anonymous column, across operations including GetServices, GetCapabilities, GetWsdlUrl, GetHostname, GetSystemDateAndTime, GetEndpointReference and the device and Event services' GetServiceCapabilities. Reach /onvif/device_service and you enumerate the service list, capabilities, hostname and system clock without credentials. GetSystemDateAndTime is the canonical liveness probe in ONVIF scanning tools for that reason, and its sibling SetSystemDateAndTime is the operation behind CVE-2023-51625, RCE on the D-Link DCS-8300LHV2 at CVSS 8.0.

What a camera says before you ask#

The discovery protocol ONVIF references normatively is an April 2005 document co-developed by Microsoft, Intel, Canon, BEA and webMethods, cited at the frozen xmlsoap.org URL. Not an RFC, and not the later OASIS revision. It binds UDP 3702 and multicasts to 239.255.255.250 and FF02::C, link-local by design.

Core §7.1 requires the Target Service role unless a device signals DiscoveryNotSupported, and "The devices default behaviour shall be the discoverable mode" — a requirement at least one major vendor has since broken with deliberately, as covered on camera cybersecurity. The spec frames turning discovery off as a DoS control: "In order to thwart denial-of-service attacks, it shall be possible to set a device into non-discoverable mode." That framing was earned. Akamai reported in September 2019 a WSD reflection flood peaking at 35 Gbps, amplification up to 15,300%, from 802,115 responding devices largely made up of "CCTV cameras and DVR systems"; Core §7.3.6 tells devices to discard malformed multicast silently but still specifies a verbose unicast SOAP fault, which is the response a spoofed unicast probe collects.

What the messages disclose is the second problem. The <d:Scopes> list standardises Location ("the physical location of the device"), Name, Hardware, MacAddress and SerialNumber, and ONVIF's own worked example reads as a demo of the risk: /hardware/D1-566, /location/building/headquarter, /location/floor/R5, /name/ARV-453. Add <d:XAddrs> and one unauthenticated probe returns model, name, floor and management endpoint.

XAddrs is also where the port comes from. Core fixes the path, /onvif/device_service, and not the port; its only port guidance is a recommendation, that "The device should provide a port 80 device service entry in order to allow firewall traversal." At runtime the numbers are read and written through GetNetworkProtocols, covering "three protocols defined, HTTP, HTTPS and RTSP. For each protocol the parameters Port and Enable/Disable can be retrieved." 8000, 8899, 2020 and 5000 circulate as ONVIF ports; they are not ONVIF assignments, and we did not verify them against any vendor's documentation. The wider map is camera ports and protocols; exposure counts and their staleness are on how cameras become internet-exposed.

TLS, the add-on and the Baseline#

The keystore, TLS server and 802.1X interfaces arrived as Advanced Security Service v1.3 in February 2016. The document is now "ONVIF Security Service Specification Version 26.06", running-headed Security Configuration, but the namespace never moved with the name: prefix tas, URI http://www.onvif.org/ver10/advancedsecurity/wsdl. Grep your WSDL and your detection signatures for advancedsecurity.

TLS is mandatory in neither video profile. Profile S v1.3 contains no TLS or HTTPS requirement at all; Profile T v1.0 marks HTTPS streaming Conditional. We did not read the A, C, D, G or M specifications, so we cannot rule out a mandate in the access-control profiles. What TLS has instead is a separate TLS Configuration Add-on, version 1.0, dated December 2023 on both its cover page and its revision history even though ONVIF posted the PDF in January 2024. ONVIF defines an add-on as "Not enough to qualify as a profile by itself". Its device requirements are concrete — RSA key-pair generation, GetKeyStatus, at least 16 keys and 16 certificates, CreatePKCS10CSR — and they bind only on products that elect to claim it. A Profile S or Profile T logo carries no TLS guarantee at all.

Where TLS is present, obsolete versions may persist. SetEnabledTLSVersions is illustrated by disabling TLS 1.0 "on a device signaling support for TLS versions 1.0, 1.1, and 1.2", and the operation is itself conditional on the EnabledVersionsSupported capability, so a device not advertising that capability offers no standardised way to turn old TLS off. RFC 8996 deprecated TLS 1.0 and 1.1 in March 2021.

The Security Baseline Specification is the correction, and it is new: first release 25.12, December 2025, "based on state-of-the-art technology as published by NIST or BSI", citing FIPS 180-4, FIPS 186-5 and BSI TR-02102-1. It sets floors of RSA 3072 or secp256r1/secp384r1, AES-GCM-128, SHA-256/384/512, and RS256/ES256 for JWTs, though RSA PKCS#1 v1_5 survives in its Table 6 marked "not recommended". At nine months old it is an emerging requirement rather than a property of anything already hanging on a wall.

The shared SOAP toolkit#

ONVIF publishes WSDL; embedded vendors generate C or C++ from it. Genivia's gSOAP lists ONVIF among its target standards and NVD names Axis cameras as gSOAP users, but no primary source we could find quantifies what share of shipping ONVIF stacks it accounts for, and the widely repeated model counts trace only to secondary reporting. The shape of the risk is not in doubt: a bug in a shared toolkit propagates across vendors sharing no code except a compiler's output from the same spec. CVE-2017-9765, "Devil's Ivy" (20 July 2017, CVSS 3.0 8.1, CWE-190), is the worked case: an "Integer overflow in the soap_get function in Genivia gSOAP 2.7.x and 2.8.x before 2.8.48, as used on Axis cameras and other devices," triggered by a large XML document. NVD's caveat deserves repeating honestly — "the large document would be blocked by many common web-server configurations on general-purpose computers" — so the exposure was specific to embedded stacks.

The rest of the CVE picture is implementation, not protocol: an NVD keyword search for "ONVIF" on 5 September 2026 returned 35 records, spanning memory safety, command injection, format strings in AddScopes and Subscribe, and outright authentication bypass, as in CVE-2020-24051 on the Moog EXO series at 9.8, where "the authentication check for those ONVIF operations can be bypassed... to create a new Administrator user." Thirty-five is a floor rather than a census, since the search matches only CVEs whose prose happens to say "ONVIF". Exploitation status is tracked at VideoSOC; the process side sits on camera vulnerability management.

Where it is going: outbound#

The Uplink Specification (v26.06) defines "the connection protocol for connecting a web service behind a firewall to a client reachable in the internet". The device becomes the TLS client, "The uplink shall be secured via TLS," certificates verified per RFC 6125, over WebSocket on HTTP/2, with an mTLS mode. Profile V builds on it and mandates the Profile V Security Add-on, which "uses the OAuth 2.0 framework so that only authorized devices, clients and cloud services can connect and exchange data" — the first ONVIF profile in which the security mechanism is a prerequisite rather than something a vendor may claim separately.

It relocates risk rather than removing it. The cloud endpoint the camera dials out to is now inside your CCTV VLAN on a connection the firewall permitted, which is the trade covered on cloud video security. And as of 5 September 2026 both Profile V and its Security Add-on were still Release Candidate, with no conformant products under either. Re-check before writing either into a tender.