How video verification supports access-control alarm review

An access control system is a very precise record of credentials. It knows that badge 4471 was presented at the east door at 23:06 and that the door opened. It does not know, and cannot know, who was holding badge 4471.

The camera above that door knows exactly who walked through. It does not know whether they were entitled to.

Each system holds one half of the event. The work of joining them is almost always done by hand, which means it is almost never done.

The four events worth verifying

Not every door event needs a picture. These four generally do.

Denied access

Someone presented a credential that was refused. The system logs a denial; it cannot tell you whether this was an employee whose badge had expired, a contractor at the wrong door, or someone trying badges they found. Those are three very different situations with the same log entry.

The camera view at that timestamp separates them in about two seconds.

Door held open

A door that stays open past its timer. The usual cause is a delivery, a propped door for convenience, or someone carrying something awkward. Occasionally it is a door propped deliberately so that someone can come back later. The log looks identical in all cases.

Badge–person mismatch

A credential presented by someone who is not the person it belongs to. The access system cannot detect this at all — the badge is valid, so the event is not even an exception. It only becomes visible when the person at the door is compared against the badge holder.

This is the one that is genuinely invisible without video, and it is the reason most access-verification projects get funded.

After-hours and anti-passback

An entry outside normal hours, or a badge used to enter an area it had not been recorded as leaving. Both are often legitimate. Both are worth a glance.

What the joined workflow looks like

The mechanics are not complicated:

1. The access system produces an event carrying, at minimum, a system identifier, an event identifier, a badge or user identifier, and a timestamp.
2. The camera covering that door is already watching. It captures the frame at that moment, as part of normal operation rather than as a retrieval.
3. The two are matched on the timestamp, and the person recognised at the door is compared against the badge holder on record.
4. The operator sees one event with both halves attached: the door, the credential, the person, the time.
5. The decision is recorded against the event, and the footage stays with it.

Done well, triage for a denied-access event is a glance rather than an investigation.

The preconditions that decide whether it works

This is where access-verification projects succeed or fail, and none of it is about the software.

The camera has to see faces at the door. A camera mounted high and wide, looking at the top of people’s heads as they pass, will not support person matching. A camera at roughly face height on the approach side will. This is the single most common blocker, and it is a mounting problem.

The clocks have to agree. If the access system and the video system drift apart by more than a couple of seconds, the matching degrades quickly. Time synchronisation across both systems is a prerequisite, not an optimisation.

The access system has to be able to hand over events. Most platforms can, through an API, a database view or a scheduled export. What varies is how much effort it takes and what fields come with it. This is established against the specific platform during onboarding rather than assumed from a compatibility list.

Someone has to decide what an identity match means to you. Matching a person against a badge holder means holding reference images of badge holders. That is a policy decision with privacy implications, and it needs an answer from your side before it is configured, not after.

What it does not do

It does not control doors. Reading events and correlating them is a different thing from locking and unlocking, and keeping those separate is deliberate — your access control system stays the authority on who gets in.

It does not prove intent. It shows you who was at the door. What that means is a judgement, and it stays with your team.

It does not work on doors without a camera. Obvious, but worth saying: coverage decides scope. Most sites find that a small number of doors account for nearly all the events worth verifying.

A sensible way to start

Pick the three doors that generate the most exceptions — usually a main entrance, a service or goods door, and whichever door the out-of-hours alerts come from. Check what the cameras on those doors can actually resolve. Establish what your access platform can export.

Then run it on those three doors on your own footage, and measure: how many events a week, how many needed a response, how long triage takes now versus before. Three doors that work are worth more than forty configured on assumptions.