ONVIF Profile V: Why the Industry’s Next Open Standard Is About More Than Cameras

For seventeen years, ONVIF has answered one question for the physical security industry: how do you make a camera from one company talk to software from another? ONVIF Profile V is the organization’s first serious attempt to answer that same question for the cloud. But treat it as just another streaming profile and you’ll miss the more interesting story underneath it — Profile V doesn’t just open up cameras. It opens up the entire pipe those cameras feed into, and that pipe is exactly where the next fight in video surveillance is going to happen: not over who makes the camera, but over who gets to interpret what the camera sees.

This piece breaks down what ONVIF Profile V actually specifies, why ONVIF built it now, and — more importantly — what an genuinely open framework built on top of it should look like if the industry wants to avoid simply trading one kind of lock-in for another.

What Is ONVIF Profile V?

ONVIF Profile V is a draft ONVIF standard, released as a Release Candidate on July 9, 2026, that defines how cloud-based video surveillance should work across manufacturers. It specifies how a conformant camera or encoder establishes a secure connection to a cloud video management system (VMS), streams live video and audio over WebRTC, pushes encrypted recordings to cloud storage, and sends event notifications — all using a common interface that any Profile V-conformant device or client can implement, regardless of who built it.

In plainer terms: today, if you buy a cloud-connected camera, you are almost always locked into that vendor’s cloud software, because the connection between the two is proprietary. Profile V standardizes that connection. A camera that conforms to it should, in principle, work with any cloud VMS that also conforms to it — the same bargain ONVIF struck for on-premises video with Profile S back in 2011, and refined with Profile T, now extended to the cloud.

ONVIF expects to finalize the Profile V specification by the end of 2026, with certifiable, conformant products following after that.

Why ONVIF Built a Cloud Profile Now

To understand why this matters, it helps to see the problem it’s solving. Most cloud video surveillance today is built the way early smartphone ecosystems were: vertically integrated and closed. A customer buys a camera, and that camera only works with its maker’s own cloud backend. Cancel the subscription, and in many cases the hardware becomes far less useful — an arrangement pointed enough that at least one industry publication has taken to calling the pattern “Hostage as a Service.”

ONVIF Board Chairman Leo Levit framed the motivation plainly, saying the goal is for the shift to the cloud to give customers “more choice, not less” (ONVIF press release, July 2026). That’s a direct response to a market where the two dominant models are: closed VSaaS platforms that bundle proprietary cameras with proprietary cloud software (think Verkada, Rhombus, Cisco Meraki MV), and a smaller set of open VSaaS platforms (Eagle Eye Networks/Brivo, Milestone Arcules, and similar) that already accept ONVIF-compatible cameras from multiple brands.

Profile V also isn’t arriving in a vacuum technically. ONVIF has been building WebRTC support into its specifications gradually since June 2024, when it first published a WebRTC specification for peer-to-peer streaming as a lower-latency, firewall-friendlier alternative to the RTSP protocol that Profile S and Profile T rely on. That groundwork — refined through a December 2024 update and further extended in the June 2026 Core Specification — is what made a full WebRTC-native cloud profile possible. It’s worth noting this is happening alongside a separate, related move: ONVIF announced in October 2025 that it would retire Profile S itself, citing outdated authentication methods, and is steering the market toward Profile T for on-premises deployments. Profile V is the cloud-side continuation of that same modernization push.

How ONVIF Profile V Actually Works

Stripped of the marketing language, the mechanics of ONVIF Profile V are fairly straightforward:

1. A conformant device — a camera, encoder, or video streaming app — opens a secure outbound connection to a conformant cloud client (a VMS or Video-Surveillance-as-a-Service platform) over the WSS (WebSocket Secure) protocol, called the Uplink. Because the connection is outbound, there’s typically no need for the installer to configure port forwarding or a VPN to reach a camera sitting behind a home or business firewall.
2. Authentication happens through mutual TLS (mTLS) and access tokens, not the username/password model that older ONVIF profiles used — a meaningful security upgrade.
3. Live video streams over WebRTC, using H.264 as the mandatory codec. If the device has a microphone and speaker, bidirectional audio streams the same way.
4. Recordings are encrypted and pushed to cloud storage — ONVIF names Amazon S3 and Microsoft Azure Blob Storage as reference targets — using MP4/CMAF container formats.
5. Events are delivered either as pull-point notifications over the Uplink channel or as JSON messages over MQTTS.

Security requirements are deliberately kept in a separate, companion specification called the Profile V Security Add-on rather than baked into the profile itself. Under ONVIF’s rules, a published profile’s contents can never be changed — so security requirements, which need to evolve as threats do, live in an add-on that can be revised independently. Every Profile V-conformant product must implement it. It mandates the OAuth 2.0 framework for authorizing devices, clients, and cloud services to exchange data, along with the encryption and container-format requirements for cloud-bound recordings.

For manufacturers, that means building to two documents, not one: Profile V for the streaming and connectivity behavior, and the Security Add-on for how that connection gets trusted and how footage gets protected in transit and storage.

The Real Opportunity: Openness Has Two Axes, Not One

Here’s where it’s worth stepping back from the spec sheet, because the headline framing — “ONVIF makes cloud cameras interoperable” — undersells what’s actually opening up.

Look at how the current cloud surveillance market is actually built, and a pattern emerges. It splits along two independent dimensions: who makes the camera, and who interprets what the camera sees. Every major platform today picks a position on both:

• Closed camera + closed AI: Verkada, Rhombus, and similar platforms bundle proprietary hardware with their own built-in analytics. You get their camera and their AI, full stop.
• Open camera + still largely closed AI: Eagle Eye Networks/Brivo, Milestone Arcules, and comparable “bring your own camera” platforms solved half the lock-in problem — any ONVIF-compatible camera works — but the analytics layered on top is typically still the platform’s own bundled offering.

Notice what’s missing from that list: open camera + open AI. Nobody has clearly built the platform where you can point any conformant camera at a cloud endpoint and choose, per camera or per customer, which AI model interprets the footage — a license-plate model from one vendor, a weapons-detection model from another, a custom vision-language model for a specialized use case, all running against the same underlying video feed without re-architecting anything.

That’s the gap ONVIF Profile V actually creates room for. Because Profile V standardizes the device-to-cloud handoff — any conformant camera speaks the same WSS/WebRTC uplink language regardless of manufacturer — it removes the need for a cloud platform to build a bespoke integration per camera brand. Once that integration cost disappears, the natural next question for any platform sitting at that uplink is: why should the AI on top be locked in too? If camera choice can be open, interpretation choice can be open as well, and the two openness axes reinforce each other rather than competing.

What an Ideal Openness Framework Should Look Like

If the industry takes this seriously, an openness framework built on Profile V should extend the same design principle ONVIF applied to cameras up through the rest of the stack. Three things define what that should look like in practice:

A neutral, standards-conformant ingestion point. The cloud endpoint receiving the Profile V Uplink shouldn’t privilege any single camera brand — any conformant device should be able to latch onto it exactly the way the spec describes, with no vendor-specific quirks required on either side.

Frame-level extraction decoupled from a single analytics engine. Once video is flowing through that uplink, the platform should treat “getting frames out of the stream” and “interpreting those frames” as two separate, swappable jobs — not one bundled black box. A retailer might want a loss-prevention model; a warehouse might want a safety-compliance model; an enterprise might want to run its own fine-tuned vision model entirely. The infrastructure shouldn’t care which, as long as it can hand off frames in a consistent way.

Composability as the default, not an add-on. The platform in the middle should function less like a surveillance vendor and more like infrastructure — closer to how a payments processor sits neutrally between banks and merchants, or how a message queue sits neutrally between producers and consumers. It succeeds by being useful to both the camera side and the AI side simultaneously, not by capturing value from either.

This is, functionally, the architecture Samvyo’s WebRTC and AI pipeline is already built around — which is the point worth drawing out.

What Changes for Whom

For camera manufacturers, Profile V removes the need to build and run an entire proprietary cloud backend just to offer a cloud-connected product — they can build to the standard and let a conformant cloud client handle the rest, the same way Profile S let them skip building proprietary VMS software for on-premises deployments.

For system integrators, it means a cloud deployment stops being a single-vendor commitment. A camera, a VMS, and a storage provider all become independently replaceable components.

For closed VSaaS incumbents, it raises a real strategic question: their lock-in has historically been a feature of the business model, not a bug, and Profile V gives buyers a standards-based alternative to point to in procurement conversations.

For AI and analytics vendors, an open uplink plus composable interpretation means competing on model quality and accuracy rather than on which hardware ecosystem they managed to get bundled into.

For end customers, the pitch is straightforward: cloud video without the hostage dynamic, and eventually, video intelligence without being stuck with whichever AI model happened to ship with the camera.

Current Status and Realistic Timeline

It’s worth being precise about where things stand, since “open standard” headlines tend to outrun the calendar. ONVIF Profile V is at Release Candidate stage — open for review and testing by ONVIF member companies, not yet finalized. ONVIF expects to finalize the specification by the end of 2026. Only after that can manufacturers build to a frozen spec and pass ONVIF’s conformance testing to claim certified support, which realistically pushes certifiable Profile V products into 2027. The opportunity described here is a build-toward-now proposition, not a ship-today one.

For readers who’d rather see this tap-decode-interpret-reinject pattern in working code than take it on faith, Samvyo’s engineering team published a byte-level walkthrough of it the day before this piece: Building Real-Time Media AI Pipeline with opensam: From RTP Packets to AI and Back, Byte by Byte. It documents opensam, an open-source reference baseline on GitHub (github.com/Samvyo/opensam) that taps a live WebRTC session, parses raw RTP by hand into Opus audio and VP8 video, decodes both into PCM and pixel frames, routes them through STT/LLM/TTS and vision models, and re-encodes the result back into the stream — the same extract-interpret-reinject shape a Profile V-style openness framework needs, demonstrated end to end in about 400 readable lines. It’s deliberately built and documented as a proof-of-concept rather than a hardened production system, precisely so anyone evaluating this pattern can clone it, read every step the bytes take, and decide for themselves whether it does what they need before reaching out for anything more.

Where Samvyo fits into this picture is on the infrastructure side of that gap. Samvyo’s WebRTC SDK is already built for sub-100ms, hardware-accelerated media delivery — using GStreamer for capture, encoding, and rendering across GPU, VPU, and DSP acceleration — and its embedded/IoT WebRTC product already lists industrial surveillance and connected-device video among its supported use cases. Combined with Samvyo’s real-time AI SDK, which already pulls structured insight out of live video and audio streams for other industries, the same event-driven pipeline architecture generalizes naturally into exactly the kind of composable, ingest-once-interpret-with-anything layer that a Profile V-aligned openness framework calls for: any camera latching onto a WSS/WebRTC endpoint, with frames handed off to whichever third-party AI model the deployment actually needs.

Frequently Asked Questions

What is ONVIF Profile V? ONVIF Profile V is a draft ONVIF standard for cloud-based video surveillance, released as a Release Candidate in July 2026. It defines how conformant cameras and encoders connect securely to cloud video management systems, stream live video and audio over WebRTC, and push encrypted recordings to cloud storage.

How is Profile V different from Profile S and Profile T? Profile S and Profile T govern on-premises IP video streaming using RTSP as the transport protocol. Profile V governs cloud video surveillance specifically, using WebRTC over a secure WSS uplink instead, and is designed to work behind local firewalls without port forwarding or a VPN.

Does ONVIF Profile V replace RTSP? No. RTSP remains the streaming protocol for local, on-premises ONVIF profiles. Profile V is WebRTC-native by design specifically for its cloud use case; it doesn’t change how Profile S or Profile T devices stream locally.

When will ONVIF Profile V be finalized? ONVIF has stated it expects to finalize the Profile V specification by the end of 2026. Certified, conformant products are expected to follow the finalized spec, making 2027 the realistic window for commercially available Profile V hardware.

What is the ONVIF Profile V Security Add-on? It’s a companion specification that every Profile V-conformant device and client must implement. It requires OAuth 2.0-based authentication using mutual TLS and access tokens, and specifies how recorded video and audio must be encrypted before being pushed to cloud storage. It’s kept separate from the core profile so security requirements can be updated over time.

Does Profile V mean any camera works with any cloud VMS? That’s the goal, in the same way Profile S and Profile T made local cameras and VMS software interoperable across brands — but only for products that are actually certified as Profile V-conformant, which requires passing ONVIF’s conformance testing once the spec is finalized.

What codec does ONVIF Profile V use for video? H.264 is the mandatory codec for Profile V conformant devices and clients. H.265 is not currently part of the Profile V requirement set.

Why does composable AI matter for ONVIF Profile V? Profile V solves camera-side lock-in by standardizing how cameras connect to the cloud. It doesn’t, by itself, address analytics-side lock-in — most cloud VMS platforms still bundle their own AI. An openness framework that pairs Profile V’s camera-agnostic uplink with a composable, swap-any-AI-model interpretation layer extends the same open-standards principle to the part of the stack that currently has no equivalent standard.

---

Sources: ONVIF Profile V press release and technical FAQ (onvif.org, July 2026); ONVIF WebRTC specification history (v24.06, v24.12, v26.06); ONVIF Profile S deprecation announcement (October 2025); industry coverage via Security Info Watch, Security Sales & Integration, and SecurityWorldMarket.