Unlock the full potential of Wavestore v6.50 -view our launch presentation today and explore the latest innovations in video management.
GSX 2026 opened with three major vendors announcing "unified" platforms in the same week. Gallagher and Luxriot unveiled a bi-directional Operational Intelligence Platform bringing video, access control and analytics together. Honeywell's LenelS2 shipped OnGuard 8.4 with unified cloud and video-access capability. Acre updated Access It! with similar integration claims. Three separate press releases, one shared word: unified.
For security integrators, that word now needs translating before it can be repeated to a client. Not every platform calling itself unified is built the same way underneath, and the difference determines what a client actually gets — and what breaks first when something goes wrong. This guide gives you a practical framework for telling a genuinely unified security platform from one that's simply had its systems bridged together.
Vendor language around "unification" has been used loosely for years. What's different this year is the volume and the timing. Multiple established vendors moving on the same architecture claim in the same seven-day window signals that the market has decided this is where buyer expectations are heading — which means more clients will start asking for it by name, whether or not they understand what it means.
That puts the burden of translation on the integrator. A client who's read a trade press headline about a "unified operational intelligence platform" will expect you to know whether the product in front of them delivers that, or whether it's a rebadged integration with a new interface layer on top.
Read our explainer on native vs. bolted-on integration
The core technical question is simple to ask and often uncomfortable for a vendor to answer directly: does this platform run on one shared event system, or are two (or more) separate systems exchanging data through an interface?
.png)
In a natively unified platform, video, access control, and alarms events are all first-class participants on the same underlying event bus. There is no translation step between "an access denial happened" and "the video system needs to know about it" — because they were never separate systems to begin with. This tends to produce:
A bridged or "bi-directional interface" platform takes two (or more) mature, separately-developed products and builds a connector between them. This is a legitimate and often useful engineering approach — it's how most integrations have worked for two decades — but it is architecturally different from native unification, even when the user interface looks seamless. Signs of a bridged approach include:
Neither approach is inherently wrong for every use case. But a client paying for "unified" should know which one they're getting, because it changes the total cost of ownership and the failure modes they'll eventually encounter.
Recent Security Info Watch coverage of the GSX 2026 unified platform announcements
Use these in a vendor call, a demo, or an RFP response. A vendor with a genuinely native platform should be able to answer all five without hedging.
1. Is there one database, or two databases with a synchronisation layer between them?
This is the single clearest tell. A synchronisation layer is a bridge, however fast it is.
2. What happens to event correlation if the connection between systems drops?
In a native platform, this question doesn't really apply — there's no connection to drop. In a bridged platform, the answer reveals how much functionality depends on both vendors' infrastructure staying online simultaneously.
3. Is licensing per-camera and per-reader, or does it stack a platform fee on top of each underlying product's own licensing?
Bridged platforms often carry the licensing complexity of both source products.
4. How long has this specific integration existed, versus how long has the platform architecture existed?
A partnership announced this month is, by definition, new. A native architecture that's been running in production for years has had time to be tested against real failure conditions.
5. Can I see the system running with the network connection between components deliberately interrupted?
Ask for this in a demo. It's the fastest way to separate marketing language from architecture.
If you're drafting or reviewing an RFP for a client evaluating "unified" platforms this year, build these questions into the technical requirements section rather than leaving them as verbal demo questions. A written answer is harder for a vendor to soften than a spoken one, and it gives you a paper trail if the platform doesn't perform as claimed post-installation.
As one data point in this discussion: WaveFusion runs video, access control, and alarm handling on a single shared event bus by design, not as a partnership layered on afterwards. That's a description of the architecture, not a claim that it's the only way to build a good platform — bridged integrations serve plenty of legitimate use cases where the underlying products are best-in-class in their own right. The point of this framework isn't to rule out bridged platforms; it's to make sure you and your client know which one you're recommending, and why.
It should mean video, access control, and analytics operate on a single underlying system rather than as separate products connected by an interface. In practice, the term is used for both native architectures and bridged integrations, so it needs verifying rather than taken at face value.
Not inherently. Bridged integrations can combine genuinely strong individual products and are a well-established engineering pattern. The issue is only when "unified" is used to describe a bridge as though it were native architecture, which affects a client's expectations around cost, latency, and failure handling.
Ask to see the system with the connection between its components deliberately interrupted. A native platform's core functionality won't depend on that connection. A bridged platform's cross-system features typically will.
It means several major vendors are positioning toward unified architecture as a market expectation. It doesn't mean every product using the term has reached the same level of integration, which is exactly why a due-diligence framework matters this year specifically.
Ask whether licensing is per-camera and per-reader across the whole platform, or whether it stacks a platform fee on top of licensing for each underlying product. The latter is often a sign of a bridged rather than native architecture.
The volume of "unified" announcements coming out of GSX 2026 is a genuine signal about where the market is heading, but it also means the word itself has become less reliable as a shorthand. The integrators who come out of this GSX cycle ahead are the ones who can explain the difference between native and bridged architecture to a client in plain terms, and who've built that distinction into how they evaluate and recommend platforms going forward.
Bring the five questions in this guide into your next vendor conversation, and you'll have a definitive answer before you put your name behind a recommendation.
Solutions for a world we can't yet see. Discover v6.50 features helping people and businesses.
