ONVIF services, profiles, conformance, and security

ONVIF defines services and profiles for devices and clients. Check the registered product, firmware, service capabilities and operations required by your integration.

Overview#

ONVIF standardizes interoperable interfaces for IP based physical security products. Its network interface specifications define services and data types; profiles select fixed feature sets for product interoperability; addons are optional, versioned capabilities that can evolve independently. These are different claims and must not be collapsed into “supports ONVIF.” ONVIF SPECS ONVIF PROFILES ADDONS

Profiles and lifecycle#

ONVIF lists 26.06, published in June 2026, as its current network interface release on 13 September 2026. That release includes SRTP configuration/support work, ONVIF Export File Format work, WebRTC clarifications, and security updates. ONVIF HISTORY ONVIF 2606

ONVIF publishes the authoritative profile list and individual profile pages. Profile S's end date and migration guidance are explicit ONVIF lifecycle announcements. ONVIF PROFILES ONVIF S DEP ONVIF V ONVIF TLS ONVIF TLS RC ONVIF MEDIA SIGNING

The Profile S submission deadline is not a device shutdown date. A registered product and firmware version remains conformant until its manufacturer withdraws the declaration. Later firmware changes can still affect interoperability. Profile T does not require every Profile S feature, including MJPEG, MPEG4 and IP address filtering. Confirm the functions your client uses before migrating. ONVIF S DEP

Specifications, profiles, and registered products#

Use this decision sequence:

1. Identify the exact product and firmware.
2. Look it up in ONVIF's conformant products database.
3. Record the claimed profile(s) and any addon version(s).
4. Read the profile's mandatory and conditional requirements.
5. Query runtime capabilities and service versions.
6. Run the applicable ONVIF conformance and interoperability processes where your role permits.

A product is ONVIF conformant only when it is registered by ONVIF for the claimed profile. Implementing a WSDL, responding to WS Discovery, or passing a few client requests isn't an ONVIF conformance claim. Profile features are fixed; a conditional feature becomes mandatory when the product advertises or implements the triggering capability. ONVIF PROFILES ONVIF TEST

IEC 60839 access control mapping#

IEC adopted Web services based access control material derived from ONVIF specifications in three parts of IEC 60839-11. The relationship is useful for procurement and architecture, but the publications and their conformity claims remain distinct. ONVIF IEC

Use the exact IEC clauses and the corresponding ONVIF specification versions to construct a requirement level mapping; the table is an architectural crosswalk, not a clause equivalence assertion. ONVIF's current rolling network interface release can contain changes made after the IEC editions were published.

Keep these claims separate in requirements and product records:

• ONVIF conformance requires the applicable ONVIF profile implementation, testing, and registration in ONVIF's conformant products database.
• IEC conformity concerns the named IEC part and edition under the applicable assessment, certification, procurement, or regulatory scheme.
• An ONVIF registered product isn't automatically certified to an IEC part, and an IEC claim isn't automatically an ONVIF profile registration.
• State the product, firmware, ONVIF profile/addon, ONVIF registration, IEC part/edition, assessment evidence, and any regional adoption independently.

Profile A, C, and D scope can overlap the access control functions described by these IEC parts, but a profile name isn't a substitute for an IEC requirements matrix. Conversely, implementing an IEC Web service interface doesn't establish every mandatory or conditional feature of an ONVIF profile. IEC 1131 IEC 1132 IEC 1133

Protocol stack and discovery#

Typical device side flow:

WS-Discovery Probe/Resolve on the local discovery domain
    -> device service XAddr
GetServices / GetCapabilities
    -> service endpoints and versions
GetSystemDateAndTime / identity and security setup
    -> authenticated service calls
media, events, PTZ, recording, access, door, or I/O operations

ONVIF interfaces are primarily WSDL defined SOAP/XML services over HTTP(S). WS Discovery is useful for initial discovery but shouldn't be treated as identity proof: discovery metadata and endpoint addresses are attacker controlled until authenticated. Route discovered addresses through an allowlist or management plane policy; don't let an untrusted XAddr become an unrestricted server side request target.

Service map#

Actual availability is capability and profile dependent.

Prefer GetServices with capability inclusion when supported, then interrogate each service's options. Never assume that because one firmware exposes an endpoint, another product with the same profile exposes every optional operation.

Media retrieval pattern#

For conventional camera integrations:

1. Enumerate media profiles/configurations.
2. Select by declared token and capabilities, not display name alone.
3. Obtain a stream URI for the intended transport and protocol.
4. Apply separate authorisation and expiry policy to the returned URI.
5. Establish RTSP/RTP or the negotiated transport.
6. Monitor encoder reconfiguration, source loss, keyframe recovery, and URI expiry.

Profile tokens are opaque identifiers. Persisting a token can be useful, but integrations must recover when a factory reset, firmware change, or configuration replacement invalidates it.

Event consumption#

PullPoint is commonly easier to operate through firewalls than callbacks. A consumer should:

• obtains the topic set and validates expected namespaces;
• creates a subscription with a bounded lifetime;
• polls with bounded timeout and message count;
• renews before expiry and recreates on lost subscription;
• parses Topic, source, key, data, UTC time, and property operation semantics;
• deduplicates using application context because transport retries and reconnects can repeat state;
• treats Initialized, Changed, and Deleted property operations distinctly;
• records device clock quality and never assumes clocks are synchronised.

Profile M metadata/events and its conditional MQTT support don't make every Profile M product an MQTT publisher. Query the advertised capability and authenticate broker connections independently. ONVIF M

Safe SOAP shape#

Target: Offline request construction for an ONVIF device service operation.

Inputs: Synthetic endpoint and no credentials.

Side effects: Offline construction only; any transport adapter must enforce authorisation, target allowlisting, and operation specific policy.

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope
    xmlns:s="http://www.w3.org/2003/05/soap-envelope"
    xmlns:tds="http://www.onvif.org/ver10/device/wsdl">
  <s:Header/>
  <s:Body>
    <tds:GetServices>
      <tds:IncludeCapability>true</tds:IncludeCapability>
    </tds:GetServices>
  </s:Body>
</s:Envelope>

The actual HTTP binding, SOAP action, authentication headers, TLS trust, timeouts, and XML limits must follow the device's advertised WSDL and the relevant ONVIF release. See SOAP and XML.

Security architecture#

Transport and device identity#

• Prefer HTTPS with certificate validation and managed trust anchors. Don't silently fall back to HTTP after a TLS failure.
• Provision unique device identities and credentials; reject shared factory credentials.
• Pinning can reduce trust scope but needs an explicit renewal/replacement path.
• Segment device, recorder, client, and cloud planes. Limit discovery multicast to intended segments.
• Normalise and validate service endpoint addresses before following them.

Authentication and authorisation#

• Use the strongest mechanism both parties explicitly support; never place passwords in stream URLs or logs.
• Give discovery, read only monitoring, video retrieval, PTZ, door control, firmware/configuration, and user administration separate roles.
• Treat door unlock, relay activation, configuration reset, user changes, and certificate changes as high impact operations requiring explicit policy and audit.
• Reauthorize long lived subscriptions and media sessions after account, role, or credential changes.

XML and message handling#

• Disable external entities and external DTD resolution.
• Bound envelope, element depth, attribute count, text length, arrays, metadata frames, and decompressed size.
• Match namespace URI plus local name; don't match a security relevant element by local name alone.
• Reject ambiguous duplicates and unexpected signature placement if a security profile uses signed XML.
• Treat schema validation as syntax checking, not authorisation.

Media and events#

RTP isn't encrypted by default. Use SRTP or another explicitly negotiated protected media path when required; release 26.06 adding SRTP related configuration work doesn't imply every device or profile supports SRTP. Protect event data as sensitive operational telemetry: it can reveal occupancy, door state, camera health, location, and alarm posture.

Failure and interoperability checklist#

• Exact firmware and registered profile/addon claims recorded
• Network interface release and each service namespace/version recorded
• Required versus conditional profile features mapped
• TLS trust, hostname/address rules, clock requirements, and credential rotation validated against target versions
• HTTP/SOAP timeout and retry policy is operation specific
• Mutating operations aren't blindly retried
• Event renewal, replay/deduplication, and clock discontinuity handled
• Media tokens, URIs, encoder changes, and restart recovery handled
• XML, metadata, image, and event sizes bounded
• PTZ, relay, door, and configuration operations explicitly authorised and audited
• Profile S and TLS Add on 1.0 migration dates tracked
• Release candidate features never represented as final conformance

Checks for your system#

Treat the cited standards status as a snapshot, not a statement about any product. Record ONVIF Device/Client Test Tool results, product database entries, exact firmware, advertised capabilities, service namespaces, TLS behaviour, event and media recovery, and cross vendor interoperability evidence for the deployed versions.

Sources#

• ONVIF SPECS, Network Interface Specifications, ONVIF, accessed 25 August 2026.
• ONVIF HISTORY, Specification History, ONVIF, accessed 25 August 2026.
• ONVIF 2606, June 2026 (26.06) specification release, ONVIF, June 2026, accessed 25 August 2026.
• ONVIF PROFILES, Profiles, ONVIF, status accessed 25 August 2026.
• ONVIF PROFILES ADDONS, Profiles, Add ons and Specifications, ONVIF, accessed 25 August 2026.
• ONVIF TEST, Device Test Specifications 26.06, ONVIF, June 2026, accessed 25 August 2026.
• ONVIF S DEP, Profile S Deprecation Q&A, ONVIF, accessed 25 August 2026.
• ONVIF V, Profile V, ONVIF, release candidate dated 9 July 2026, accessed 25 August 2026.
• ONVIF V SEC, Profile V Security Add on, ONVIF, release candidate, accessed 25 August 2026.
• ONVIF M, Profile M, ONVIF, accessed 25 August 2026.
• ONVIF TLS, TLS Configuration Add on, ONVIF, lifecycle page checked 13 September 2026.
• ONVIF TLS RC, TLS Configuration Add on 2.0 Release Candidate, ONVIF, 9 September 2026.
• ONVIF MEDIA SIGNING, Media Signing Add on, ONVIF, Release Candidate checked 13 September 2026.
• ONVIF IEC, IEC adopts ONVIF specification for access control standard, ONVIF, accessed 25 August 2026.
• IEC 1131, IEC 60839-11-31:2016, IEC, core interoperability protocol based on Web services.
• IEC 1132, IEC 60839-11-32:2016, IEC, access control monitoring based on Web services.
• IEC 1133, IEC 60839-11-33:2021, IEC, access control configuration based on Web services.

Section overview · Wiki home