Every video and access proposal that crosses our desk uses the word unified. It appears in the headline, in the summary paragraph, and in the line item that costs the most. It is never defined.
That is not sloppiness. It is the most useful word in the industry precisely because it can mean four different things, and three of them are cheap to deliver. A buyer hears the expensive one and pays for it. A vendor delivers the cheap one and is not lying, because nobody ever wrote down which one was meant.
So this article does the thing the quote does not. Here are the four things "unified" can mean, in ascending order of how much they change your life, and the questions that tell you which one is in front of you.
Meaning 1: one pane of glass
The weakest version, and the most commonly demonstrated, is that video and access appear in the same interface. One login, one window, cameras down one side, door events down the other.
This is genuinely worth something. Staff who have to alt-tab between two applications under stress will, reliably, only look at one of them. Consolidating the screen is a real operational gain and you should not sneer at it.
But it is also the version that can be assembled with almost no engineering. A single window can be two independent products stitched into one page, each still holding its own list of users, its own permissions, its own clock. Everything below the glass is unchanged. When the access system says a door was forced at 02:14 and the video system's clock is running ninety seconds behind, the shared window does not help you — it just puts the two disagreeing answers next to each other.
The test. Ask what happens in that window when the connection between the two systems drops. If the answer is "the video panel goes blank and everything else works normally," you are looking at two systems sharing a frame. If the answer involves anything degrading in a coordinated way, there is something underneath. Then ask the more revealing question: how is time synchronized between the recorder and the access controllers, and what is the source? A vendor who has actually integrated two systems has thought hard about clocks, because correlation is impossible without them. A vendor who has built a shared web page has not thought about it at all, and the pause before the answer will tell you which one you have.
Meaning 2: shared identity
The second meaning is that a person exists once across both systems.
This one is quietly excellent and almost never demonstrated, because it does not look like anything on a screen. When a person is added, they get their access rights and their video-system login from the same act. When they leave, one action ends both.
To see why that matters, consider the failure it prevents. A supervisor resigns. Property management deactivates the card that afternoon — that part usually happens, because the card is a physical object somebody wants back. Nobody touches the video management software, where the same supervisor has an account that can pull footage, export clips and change retention settings. The card is gone. The login is not. Six months later, that account is still there, still working, and nothing in the building generates an alert about it.
We wrote elsewhere that an access system is four separate lists — people, credentials, doors and time — and that the people list is the one nobody owns. A genuinely shared identity layer takes the two most-forgotten lists in the building and makes them one list, which means forgetting it once is no longer enough to leave a hole open.
The test. Ask to watch a person be removed. Not described — watched. Have them delete a test identity in front of you, then log into the video side and search for that person's account. If it is gone, the identity layer is real. If the answer is "we would also need to remove them over here," you have two systems and a habit, and habits are exactly what fails during a resignation nobody enjoyed.
Ask the same about permission changes. If someone's access level is narrowed, does their video access narrow with it? Shared identity that only handles creation and deletion, but not the middle of the lifecycle, still leaves you reconciling two lists by hand.
Meaning 3: event correlation
The third meaning is the one worth paying for, and it is the hardest to fake.
Event correlation means the access system's events are indexed against the video, so that an event carries its footage with it. A door-forced alarm is not a line in a log that you then go hunting for — it is a line in a log that opens the clip from that door, at that second, from the cameras that see it.
The difference is not aesthetic. Without correlation, investigating a single event goes like this: read the access log, note the time, open the video system, find the right camera, find the right time, allow for clock drift, scrub until you find the moment, then start again for the second camera that also covers that door. Half an hour of skilled work, per event, done by whoever is available and motivated. With correlation, it is a click.
That difference decides whether the work happens at all. Any procedure that costs thirty minutes per event gets done for the incident somebody escalated and skipped for the forty ambiguous events that month. The same procedure at thirty seconds gets done for all of them — and the pattern that only shows up across forty events is exactly the pattern nobody has ever found in your building. This is the same argument we make about the four reports an access system owes you: the value is not in the data existing, it is in the cost of looking being low enough that someone actually looks.
Correlation also runs the other way, and this is where you separate a demonstration from a product. Can you start from the video — scrub to something odd at 03:40 — and ask the system which access events happened at that door in that window? One-directional correlation is common. Bidirectional correlation is a much stronger claim about how the two systems are joined.
The test. Ask them to demonstrate it on their own demo system, from a cold start, with an event you choose — not the rehearsed one. Then ask three follow-ups that separate real indexing from a search shortcut:
- Which camera or cameras get associated with a given door, and who configures that mapping? If it is manual, per door, then the feature is only as good as the day someone finished the configuration — and it silently rots every time a camera is moved.
- Does correlation survive after the fact? If a camera is added next year, do older events at that door pick it up, or only new ones?
- What happens when the video is already past its retention window? An event that correlates to deleted footage should say so plainly, not fail quietly.
Meaning 4: one vendor, one support contract
The fourth meaning is commercial. One company, one number to call, one renewal, one invoice, no argument about whose fault the outage is.
This is a legitimate thing to want. Anyone who has stood between two suppliers each insisting the problem is on the other side of the wire knows exactly what it is worth. Single accountability is a real product.
But notice that it is a commercial property being sold in technical language. Nothing about a single support contract requires the identity lists to be shared or the events to be correlated. You can have one vendor and one invoice on top of two products that know nothing about each other — and the way you find out is at 02:00 on a Sunday, when the single number you call routes you to a first-line agent who owns the relationship and not the software.
The test. Ask which parts of the stack the vendor builds, which they resell, and which they integrate. There is nothing wrong with any of the three. But a vendor who resells the video and builds the access is describing a very different escalation path than one who builds both, and only one of them can fix a video bug without filing a ticket with somebody else. Ask what their escalation looks like for a defect in a component they did not write, and how long that took the last time it happened.
The honest trade nobody prints on the quote
Here is the part that gets left out of the unified pitch, and it is not a small part.
Unification is achieved by coupling. The tighter the coupling — shared identity, correlated events, one data model — the more of your building's operational logic lives inside one company's product. That company then owns your roadmap and your pricing. When they change their licensing model, deprecate the module you depend on, get acquired, or decide the feature you rely on now belongs in a higher tier, your options are to accept it or to replace the whole thing.
And "replace the whole thing" is a much bigger number than most owners expect, because it is not the hardware cost. It is the reconfiguration of every access level, every schedule, every camera-to-door mapping, every report, and the retraining of everyone who uses it, plus the awkward question of what happens to the historical records that only the old system can read.
This is the same argument, from the other side, that we make about asking for an ONVIF profile letter in writing and about the wire between the reader and the controller. Open interfaces exist precisely so that one component can be replaced without replacing all of them. The reader-to-controller connection has an open published standard — OSDP, maintained by the Security Industry Association and published as IEC 60839-11-5:2020 — and the video side has ONVIF's published profiles. Neither is a magic escape hatch. Both mean that at least one seam in your system is a seam somebody other than your incumbent can work across.
The trade is real in both directions, and reasonable buyers land in different places. What is not reasonable is making the trade without knowing you made it.
Our position, stated plainly: buy the coupling where it changes the work — shared identity and event correlation — and keep the seams open where it does not. Insist on documented, standards-based interfaces at the component level even inside a unified platform, so that "unified" describes how the system behaves rather than how thoroughly you are held.
Put it on the quote
Before you sign anything that says unified, ask for these in writing:
- Which of the four — shared interface, shared identity, event correlation, single support contract — the word covers on this quote. All four is a fine answer. Any subset is a fine answer. No answer is the answer.
- How time is synchronized across recorders and access controllers, and from what source.
- A demonstrated deletion: one action removes a person's door access and their video login, watched, not described.
- A demonstrated correlation on an event you pick, in both directions, plus who maintains the camera-to-door mapping.
- Build, resell or integrate for each major component, and the escalation path for a defect in a component they did not write.
- The exit: what your data looks like on the way out. Can access levels, cardholder records and event history be exported in a documented format, and can video be exported in a form that plays without their software?
Question six is the one that gets the longest pause. That pause is the most honest thing in the meeting, and it is worth more than the rest of the presentation.
