There is a camera architecture that has quietly won a large share of the commercial market, and most of the businesses running it could not describe it in a sentence.
It goes like this. The cameras record to storage on the camera itself, or to a small appliance in your building — so the footage is local, the way it was on a recorder. But there is no recorder to log into. Everything you actually touch — the live view, the search, the user accounts, the health alerts, the sharing of a clip — lives on the vendor's platform, reached through a browser or an app. The cameras dial out to that platform; nothing dials in. Verkada is the archetype most people have seen, and the pattern is now common to several vendors.
We think it is a good architecture, and we say so plainly because the rest of this article is critical. It solves the two worst properties of pure cloud recording and the worst property of pure on-premise recording, in one design. Cloud versus on-premise is the long version of that trade; this is the short version of why hybrid escapes it.
What the architecture actually gets right
Bandwidth. Pure cloud recording pushes every camera's video upstream, all day, forever. Commercial internet connections are built lopsided — plenty of download, far less upload — and video is the one workload that runs the wrong way down that pipe. Hybrid does not have this problem, because the bulk video never leaves the building unless someone asks for it. What crosses your connection is a control channel, thumbnails, and whatever you actually watch.
Outages. Pure cloud recording has a failure mode that owners rarely price properly: when the internet drops, the footage has nowhere to go. Edge buffering mitigates it, but a buffer is a promise with a duration, and BC winters produce outages that outlast the promise. In a hybrid design the recording is local, so the connection dropping costs you access, not evidence. The cameras keep writing. That is a categorically different kind of bad day.
The unmaintained server. On-premise recorders rot. Not dramatically — quietly. An appliance goes in, someone sets a password, and five years later it is running the firmware it shipped with, because nobody's job description contains the words "patch the recorder." Hybrid removes the server from your building entirely and moves the software you depend on to somebody whose whole business is keeping it current. That is a real transfer of a real problem.
Three genuine wins. So where does it go wrong at purchase?
Not in the architecture. In what buyers assume about the commercial and security shape of it.
One: the subscription is not an add-on, it is the product
This is the misreading that costs the most, and it happens because of how the quote is laid out.
A hybrid quote looks like a hardware quote with a service line under it. Cameras, mounts, labour, and then a per-camera licence fee. Read in that order, the licence reads as a maintenance contract — the optional-feeling line, the one a cost-conscious owner mentally flags as "we could drop that later if it gets tight."
It is the other way around. In this architecture the cloud platform is the system. The management plane holds your accounts, your permissions, your search, your alerting, your sharing, and in most designs it is also the only interface through which you retrieve footage. The camera is the sensor. What you bought was access to the software, delivered with the sensors that feed it.
That reframing changes the decision in a specific, practical way: the renewal is not a maintenance decision, it is an operating dependency. Maintenance decisions can be deferred. Operating dependencies are the ones that, when they lapse, take a business function with them. Your internet line is an operating dependency. Your payroll software is an operating dependency. If your video system's management plane is one too, it belongs in the same mental category — and in the same part of your budget conversation, defended by the same person, renewed with the same lack of drama.
Two consequences follow.
The first is that a lapse is not a slow degradation. Depending on the platform, the consequences can range from losing remote access, to losing search and export, to the cameras not being usefully reachable at all. That is a wide range, and the range is exactly the point: most buyers do not know which one applies to the product on their own wall. That is not a criticism of the vendor. It is a question nobody asked.
The second is that the cost comparison people run at purchase is usually the wrong one. Comparing an on-premise recorder against a hybrid system on the first invoice compares a purchase to a subscription — and the honest comparison is over the years you expect to operate the site, at your full camera count, including the cameras you will add. We do not print prices in these articles, because any figure printed today misleads you next year. But run the arithmetic yourself, over your real horizon, before the architecture decision is made rather than after.
Two: nobody asks what happens at the end
Every subscription ends eventually. Some end because a business changes vendors, some because a building changes hands, some because a product line reaches end of life and the platform behind it is retired. This is ordinary. What is not ordinary is how rarely it gets asked about while there is still leverage to ask.
There are three separate questions, and they have different answers:
Do the cameras keep recording? Local storage does not evaporate when a subscription lapses, but whether the camera keeps writing to it — and whether anything can read it back — is a product behaviour, not a law of physics. Ask specifically, and ask for the answer in writing.
Is existing footage retrievable, and how? There is a meaningful difference between "your footage remains on the device" and "you can get your footage off the device." Retrieval usually runs through the management plane. If access to the plane is what ends, the footage can be simultaneously present and unreachable. Ask what the retrieval path looks like without an active subscription, and whether there is a defined export window after an account lapses.
What is the exit path to a different system? This is the one with the longest tail. Cameras built to open standards can usually be re-pointed at other software. Cameras bound to one vendor's platform generally cannot, which means a change of vendor is a change of hardware, and the labour of the original installation does not carry forward. The cabling and the mounting do; the devices may not. Ask whether the cameras speak a standard protocol that another platform could consume, and treat a vague answer as an answer.
None of this argues against buying the architecture. It argues for asking three questions while you are still a prospect, which is the only period in the relationship when questions are answered quickly. Write the answers down and keep them with the as-built documentation. The person who needs them will be the version of you that is eight years older, or the person who buys your building.
Three: the management plane is attack surface, not a convenience
This is the one that generates the most resistance, so let us be careful about what is and is not being claimed.
The claim is architectural, not a criticism of any particular vendor's engineering. It is this: a cloud management plane is a system that holds a list of your user accounts, is reachable from the internet by design, and processes your video. All three of those are properties of the design working as intended. They are also, in exactly those words, the description of something that belongs in your risk register.
Compare it to the failure this architecture is right to avoid. We have written at length about why an open port to a recorder is the wrong answer — an appliance designed for a private network, running the software it shipped with, answering the entire internet, findable with a search box. CISA's own exposure-reduction guidance puts the principle plainly: "Determine which assets need to be internet-accessible for operational purposes. For those that do not need to be internet accessible, implement measures to remove or restrict access."
A hybrid system follows that guidance well. The camera does not need to be internet-accessible and is not — it dials out, and there is no inbound door. That is a genuine improvement over the port-forward era, and it is why we recommend this architecture over an exposed recorder without hesitation.
But the exposure did not disappear. It moved, and it changed shape. It is now a web application with your login on it, and the security controls that matter have moved with it:
Your account hygiene is now a primary control. Multifactor authentication on every account is no longer a nice-to-have on a device nobody can reach; it is the lock on the front door of the system. So is the discipline of removing accounts when people leave — the departed manager who still has a working login is the most common access-control failure we find in any system, and a cloud plane makes that login reachable from anywhere.
Permissions are a design decision, not a default. Who can view live? Who can export? Who can share a clip outside the organization, and does that produce a record? A platform that makes sharing effortless has made disclosure effortless, and disclosure of surveillance footage of identifiable people is a privacy event, not just a convenience.
The vendor's posture is now part of yours. You have adopted their patching cadence, their access controls, and the discipline of whoever inside their organization can reach customer video. That is a reasonable trade — it is the same trade you made with your accounting software — but it is a trade, and it should be made deliberately, on the strength of published security documentation, rather than absorbed silently because the app was easy to set up.
Then there is the privacy footprint, which is where BC businesses have obligations rather than preferences. Surveillance footage of identifiable people is personal information. BC's Personal Information Protection Act requires an organization to make reasonable security arrangements to protect the personal information in its custody or under its control (s.34), and to have a retention and destruction practice for it (s.35). Note the phrase custody or under its control: handing video to a platform does not hand over the obligation. If your retention is a plan setting on a vendor's dashboard, that setting is your retention practice, and someone in your organization needs to know what it is set to and why. Where the footage is stored geographically, who inside the vendor can access it, and whether that access is logged are all questions worth asking in writing — and a provider with good answers gives them quickly.
What to actually do with this
Buy the architecture if it fits your site. It usually does: hybrid is the design we recommend most often for multi-site operators, because centralized management is the thing that prevents the branch recorder that quietly died eight months ago.
Then treat it like what it is. Put the renewal in the operating-dependency column of your budget, not the maintenance column. Get the end-of-subscription and end-of-life answers in writing while you are still choosing. Put multifactor authentication on every account, review the account list twice a year, and know what your retention is set to. And decide deliberately where analytics should run — at the edge, on a server, or in the cloud — because that choice moves data around in ways the architecture diagram does not show. If you are still working out the more basic question of where your video physically lives, start there and come back.
None of that is difficult. It is just work that nobody assigns, in a system that looks finished the day it is installed.
