Integrating access control with video surveillance: why video-only tailgating detection fails, how badge-to-body reconciliation works, what to ask vendors.
Access control knows who presented a credential and video knows what actually happened. The value is in the join rather than in either system alone.
There are four levels of ACS and video integration and vendors call all of them integration. Ask which one they mean, because the answer is usually camera lookup.
Video only tailgating detection does not work. It cannot distinguish two colleagues each badging in from one person with an unauthorised follower, so it alarms on ordinary busy traffic and gets muted.
Badge to body reconciliation is the real method: alert when the number of people who crossed exceeds the number of credentials presented in the same window.
Fix the clocks before anything else. Correlation is a time window operation and drift breaks every rule invisibly, looking like an analytics problem rather than a configuration one.
Search for access control and the entire first page is companies selling the door side: readers, panels, locks, credentials, installation. HID, Avigilon, Axis, Verkada, Johnson Controls, Gallagher, Kisi, Nedap. Good vendors, accurate material.
What none of them writes about is the join. Access control produces a stream of events about credentials, and video produces a continuous record of what physically happened, and the question of how those two become one usable signal is answered by neither side's marketing, because it sits between them.
This guide is about the join, written from the video side.
An access control system decides who may pass through a controlled opening, and records the decision.
Physically it is credentials such as a card, a phone or a biometric, readers at the door, a controller or panel making the decision, a locking mechanism, and software managing who is allowed where. The event stream it produces is the interesting part for our purposes: access granted, access denied, door forced open, door held open too long, credential unknown, and similar.
The theoretical models get asked about frequently, so briefly. Discretionary access control lets the owner of a resource decide who may use it. Mandatory access control enforces a central policy the user cannot override. Role based access control assigns permission to roles rather than to individuals, which is what nearly every commercial building actually uses. Attribute based access control decides from a combination of attributes such as identity, time, location and device. In physical security, role based is dominant, usually with time of day and door group constraints layered on.
The three components people are asked to name are typically the credential, the reader and controller that make the decision, and the management software that holds the policy and the audit trail. What that list omits, and what this guide is about, is that none of those components can tell you what physically happened.
This is the whole reason to integrate. An access control system records that a valid credential was presented at a door and that the door was released. It does not know several things that matter.
It does not know how many people went through, because one badge produces one event however many bodies follow. It does not know who actually held the credential, because a badge is a token rather than a person, and borrowed, shared, cloned and stolen credentials all produce a perfectly clean access granted event. It does not know what happened on the other side, because the event ends at the door. It often does not know reliably whether the door closed. And it cannot tell you what a denial meant: a denied credential could be a new joiner whose access has not propagated, or someone testing doors along a corridor, and the event looks identical either way.
Video knows all of these things and knows none of the identity. That complementarity is the argument for integration, and it is stronger than the usual framing of one pane of glass, which is a user interface benefit rather than a security one.
Vendors use the word integration for all four of these, and they are very different.
Side by side is two systems, two screens, one room. It is not an integration, though it is frequently sold as one, and an operator correlates by hand, in real time, badly.
Camera lookup means clicking an access event and seeing the camera nearest that door. It is genuinely useful, cheap to build, and the level most deployments actually reach. It makes investigation faster and changes nothing about detection.
Event correlation puts access events and video events into the same rule engine so that rules can be written across both, such as a door forced event on this door and a person detected on the camera covering it within thirty seconds. This is the level at which integration starts detecting things neither system detects alone.
Reconciliation means the systems check each other continuously and alert on disagreement, the canonical case being badge to body counting for tailgating. This is the level almost nobody reaches, and it is where the real value is. When a vendor says they integrate with your access control system, ask which of these four they mean, because the answer is usually the second.
This is worth dwelling on, because the standard advice is wrong and it is repeated everywhere, including by AI assistants when you ask them.
The common recommendation is to draw a virtual tripwire at the door, count people crossing it, and alert when more than one person crosses in a short window. It sounds reasonable and it fails immediately in production.
The reason is that legitimate traffic looks identical to tailgating on video alone. Two colleagues arriving together, each badging in properly, produce two people crossing a line within a couple of seconds. So does one person badging in with an unauthorised follower. A camera counting bodies cannot tell those apart, because the difference is not visible: it is in whether a second credential was presented.
The consequence is an alert stream that fires at every busy entrance every morning, which operators mute within a week. That is worse than no detection, because it consumes attention and creates the belief that the capability exists.
Real tailgating detection is badge to body reconciliation. Count the people who physically crossed, count the credentials presented at that door in the same window, and alert when bodies exceed badges. Two people with two badges is normal. Two people with one badge is a tailgate. The signal is the discrepancy rather than the count. This requires the two systems to be genuinely joined, with a shared time base and a reliable mapping from each door to the cameras covering it. It is more work than a tripwire, which is why the tripwire advice persists.
Being specific, because this is a product section.
Visylix accepts inbound access control webhooks from five vendor families directly in their own native payload format: Brivo, LenelS2 with OnGuard OpenAccess, HID covering Origo and Mercury, AMAG Symmetry, and Genea or Openpath, plus a generic shape for anything else. Earlier the endpoint accepted only our own generic event format, which meant every customer needed a translation service in front of it. Removing that is unglamorous and it removes a whole component from the deployment. The normalizers are deliberately defensive: each reads the field names the vendor documents, then falls back through common aliases, so a firmware update that renames a field degrades gracefully instead of silently dropping access events. Silently dropping access events is the worst possible failure in this subsystem, because nothing looks wrong.
The part we would point at first is that there is one rule engine rather than two. Access events do not go into a separate access events feature. They enter the same rule machinery that video detections use, correlated on the same key of rule and camera. A rule such as person detected and door forced, on this camera, within the window, fires only when both legs actually co-occur. A rule with only an access condition, such as door forced, fires immediately.
The reason that matters is not elegance. It means there is one firing path, one arming gate, and one place where rules are evaluated, so access based rules inherit everything the video rules already have: ordered temporal sequences, per condition branching, dry run preview and the rule health board. A separate access events subsystem would have needed all of that rebuilt, and in most products it has not been.
For tailgating, an opt in badge correlation mode buffers access granted events per camera door and counts them against observed crossings, alerting when more people crossed than credentials were presented. The buffer is bounded, holding a limited number of recent events per stream and discarding anything older than a short window, because stale badge events would produce exactly the false reconciliation the feature exists to avoid.
Correlated events flow into Sudarshan, the live intelligence layer, so an operator sees the door event and the camera together with severity indicated rather than having to notice a row in a log. Radha, the on premise copilot, can be asked about access events conversationally alongside video, which matters during an investigation when the question is who went through the loading bay door after eight last night rather than a query anyone wants to write by hand.
What Visylix deliberately does not do is actuate doors. Rules notify, integrate and alert; they do not unlock, lock down or drive hardware. That is a deliberate boundary: the access control system owns the decision to open a door, and a video analytics platform issuing lock commands on the basis of a probabilistic detection is a category of failure we do not want to be the cause of. If you need automated lockdown, that belongs in the access control system, triggered by a notification from ours. Visylix also has no attendance module: access events are security events here, not time and attendance records, and we do not market the capability.
Map doors to cameras first, because nothing else works without it. Every controlled opening needs to know which camera or cameras cover it, on both sides where it matters. This is a data entry exercise and it is the foundation for everything above camera lookup.
Then fix the clocks. Correlation is a time window operation, so if your access controller and your VMS disagree by fifteen seconds, every correlation rule is wrong and the failures will look like analytics problems rather than clock problems. Put both on the same time source. This causes more integration failures than any other single cause and is the cheapest to prevent.
Start with camera lookup, because it is quick, it delivers immediate value in investigations, and it validates the door to camera mapping in daily use before you build anything that depends on it.
Then write correlation rules for the events that matter, where a short list beats a long one. Door forced with nobody detected, which suggests a mechanical fault rather than an intrusion. Door forced with a person detected, which does not. Repeated denials at one door within a few minutes. Access granted at an unusual hour for that door group. And a credential used at two doors too far apart for the time between them, which is the classic cloned badge signal and needs no video at all.
Add reconciliation last, once mapping and clocks are proven, because it is the most sensitive to both.
Clock drift, as above, is the largest single cause.
Door to camera mapping rots. Cameras get moved, doors get renamed, a refurbishment renumbers a wing. The mapping is not self maintaining, and nothing alerts you that it has gone stale, so re verify it on a schedule.
Webhook delivery is assumed reliable. Access control systems push events over HTTP, networks drop, endpoints restart, and vendors rarely retry aggressively. If correlation quietly stops because events stopped arriving, you will not notice, because the absence of alerts looks exactly like the absence of incidents. Monitor for the absence of expected events, not just for errors.
One badge across many doors has unclear semantics. Turnstiles, anti passback configurations and multi door interlocks all produce event patterns that a naive correlation rule reads wrongly, so understand what your access control system emits before writing rules against it.
And privacy scope creeps. Joining identity data to video changes the character of the system, because an access log plus footage is a record of individual movement through a building, which attracts obligations that neither system attracted alone. That is a governance question and it should be answered before the integration is built rather than after.
Access events carry identity and video carries images. Correlating them produces a per person movement record, and in most regulatory regimes that is a more sensitive data class than either input.
Under India's Digital Personal Data Protection Act and comparable frameworks elsewhere, this means establishing your lawful basis for the correlated record specifically, setting a retention period for it that may be shorter than either source system's, restricting who can query across both, and auditing those queries. The fact that an employee consented to badge access does not automatically extend to video linked movement tracking.
Two practical positions are worth taking. Keep the correlation query auditable, so you can answer who looked up whose movements and why. And scope the integration to the doors where it is defensible, which is usually perimeter, restricted areas and cash or asset handling, rather than every internal door in the building.
Running the whole thing on your own infrastructure removes the cross border transfer question from this analysis, which is often the hardest part to satisfy when identity and imagery are joined. Visylix runs entirely on customer infrastructure, including in air gapped deployments.
Unified access control and video earns its place on perimeter and restricted area doors where credential misuse has real consequence; in investigations, where camera lookup collapses hours of review into a click; for genuine tailgating detection at controlled entrances via badge to body reconciliation; for cloned or shared credential detection, where the pattern is invisible to either system alone; and for distinguishing a mechanical door fault from an intrusion, which changes who gets dispatched.
It disappoints in deployments where door to camera mapping was never completed or has gone stale; in environments with unsynchronised clocks, where every correlation rule misfires; wherever video only tailgating detection is used, because it alarms on normal busy traffic and gets muted; in integrations that stop at camera lookup and are described as correlation; and in any deployment where the privacy scope of the joined record was never assessed.
An access control system decides who may pass through a controlled opening and records the decision. In practice it comprises credentials such as cards, phones or biometrics, readers at the door, a controller that makes the decision, a locking mechanism, and management software holding the policy and the audit trail. Its output is a stream of events such as access granted, access denied, door forced and door held open.
Four models are usually named. Discretionary access control lets a resource owner decide who may use it. Mandatory access control enforces a central policy users cannot override. Role based access control assigns permissions to roles rather than individuals, and is what most commercial buildings use in practice. Attribute based access control decides from a combination of attributes such as identity, time, location and device.
Because an access control system records that a valid credential was presented, not what physically happened. It cannot tell you how many people went through, whether the credential holder was the person using it, or what occurred on the other side of the door. Video answers those and knows nothing about identity. Correlating them detects things neither detects alone, such as a cloned badge or a genuine tailgate.
Reliably, it works by reconciling bodies against badges: count the people who physically crossed the threshold, count the credentials presented at that door in the same time window, and alert when people exceed credentials. Video only approaches that count people crossing a tripwire cannot distinguish two colleagues each badging in from one person with an unauthorised follower, so they alarm on ordinary busy traffic and get switched off.
Visylix accepts inbound access control events natively from five vendor families: Brivo, LenelS2 including OnGuard OpenAccess, HID covering Origo and Mercury, AMAG Symmetry, and Genea or Openpath. There is also a generic event shape for any system that can post a webhook, so a platform outside that list can integrate by mapping its output once.
No, and this is deliberate. Visylix rules notify, alert and integrate; they do not actuate door hardware. The access control system owns the decision to open or secure a door. A video analytics platform issuing lock commands on the basis of a probabilistic detection is a failure mode we would rather not introduce. If you need automated lockdown, implement it in the access control system, triggered by a notification from ours.
No. Visylix has no attendance module. Access events are treated as security events rather than time and attendance records, and we do not market that capability.
Physical security information management platforms sit above multiple security systems and aggregate them, typically as a separate product layer with its own cost and integration burden. Correlating access control with video inside the VMS achieves the most valuable part of that, the joining of door events to what the cameras saw, without adding a platform. A PSIM makes sense when you are unifying many more system types than video and access.
Clock drift between the access controller and the VMS, because correlation is a time window operation and a drift of even a few seconds makes every rule unreliable while looking like an analytics problem. After that, door to camera mappings that have gone stale, and webhook delivery that silently stopped, which is invisible because an absence of alerts looks exactly like an absence of incidents.