Facial access control: where recognition breaks down
A checkpoint is the toughest scenario for facial recognition. There is no time for a second frame: a person approaches the camera for a couple of seconds, and during peak load a queue is already behind them.
Any delay in detection and comparison turns not into inconvenience for one employee but into a bottleneck at the entrance and manual mode for security.
Main identification errors appear exactly under peak load. Several faces end up in the frame at once, a person walks without stopping and turns their head, and lighting at the turnstile causes glare or harsh shadow.
If the match threshold is set too tight, false rejection grows: an employee with valid access stands and waits for the operator. If it is too loose, the system starts confusing similar people, and that is already a hole in the perimeter.
The second failure point is a change in appearance. A beard, glasses, a hood, a mask, seasonal lighting changes alter the numerical vector of the face more than the reference recorded once when the pass was issued expects.
The reference needs to be updated periodically, and the solution should combine facial comparison with liveness detection: without it, a photo from a phone screen passes as the owner.
The third scenario is not a malfunction but a bypass. Facial access control loses its meaning if one person opens the turnstile and another passes through.
That is why a checkpoint is designed as a bundle: face, passage event, and a log where it is visible exactly who opened the access point and how many people passed through it. We look at how each of these failures is closed by configuration rather than by replacing equipment.
What changes at a site after biometrics implementation
The access point stops being a bottleneck. In card mode, a person spends 6–8 seconds entering: took out the pass, presented it, waited for the turnstile response, passed.
Facial recognition fits the cycle into 1–2 seconds because the decision is made as the person approaches—by the time they reach the barrier, confirmation is already ready.
Throughput of one lane grows multiple times, and during the morning flow the queue in the lobby either disappears or stops requiring a second lane.
The load on security changes not in quantity but in composition.
Manual checks of "pass not reading," unlocking entrance for contractors and guests, and keeping a paper log go away—perimeter control remains, along with handling exceptions that the system marked as disputed. The share of manual operations at the point drops from most passages to isolated cases per shift.
A class of failures that a card cannot cure in principle is also closed: someone else's or a lost pass, two people passing on one credential, an attempt to show a photo to the camera.
Liveness detection according to ISO/IEC 30107-3—the standard for testing biometrics against spoofing—records such attempts and puts them into the event log, not into the shift's memory.
Incident investigation accelerates because each event is stored with a timestamp and frame. A disputed situation is reviewed from the log in minutes rather than by reviewing footage from the start of the shift.
All the listed effects are calculated at a pilot point before scaling—this shows exactly what the system delivers at a specific site.
Identification methods: comparison of approaches and modes
The identification method is chosen not by demo accuracy but by site conditions: entrance lighting, flow intensity, anti-spoofing requirements, and people's willingness to carry a card.
An outdoor turnstile and an internal door at the same site often operate in different modes—this is normal practice.
| Identification method | Passage mode | When it fits | Limitations |
|---|---|---|---|
| 2D from video stream | 1:N, no credential | Internal doors with stable light, office flow | Backlight and low angle cause false rejections, weaker photo protection |
| Bispectral imaging: visible and IR channel | 1:N | Outdoor entrance, vestibule, variable lighting | Calibration for installation point, shorter triggering distance |
| 3D face model | 1:N with anti-spoofing | Restricted areas, server rooms, cash desks | Sensitive to pose, hoods and masks, requires a capture zone |
| Face and card | 1:1 verification | Manufacturing and warehouses where binding to a pass is needed | Credential is lost and shared, issuance regulations needed |
Compatibility with the existing access system
We keep recognition separate from enforcement: a module from VisionLabs or an open model outputs the decision, while the existing controller controls the turnstile via a relay output—there is no need to rebuild the entire access system.
We select the passage mode for the flow: identification against a database is faster and does not require a credential, but it needs a margin in the match threshold; verification reduces the share of false admits.
Before implementation, we run the real flow and record latency, false rejection rate, and behavior in low light.
How implementation proceeds: stages of engineering work
Implementation begins not with installing cameras but with a survey of the checkpoint: mistakes at this step surface during the morning peak, when the queue to the turnstile grows faster than security can react. Then work proceeds in stages—the next starts after the previous one is confirmed at the site.
-
Checkpoint survey. Peak-hour flow intensity, passage geometry, lighting and backlight from windows and the street, backup doors. We record which ACS and controllers are currently installed, and how guests and contractors are admitted.
-
Scenario design. We decide where passage is face-only and where biometrics supplements a card; we define a fallback method in case recognition fails, the triggering threshold, and the zone where the face is guaranteed to be in frame.
-
Reference database preparation. Photos according to quality requirements, deduplication, binding to employee accounts, biometric processing consents—without them the system cannot be accepted into operation.
-
Installation and commissioning. Cameras according to passage geometry, illumination, calibration of the triggering zone and the junction with the turnstile controller: we test the opening response before going live with a real flow.
-
Live flow testing. We run employees in real mode: false rejection and false admit rates, time per person, behavior at peak. Separately—protection against a presented photo and video from a phone screen.
-
Security briefing and regulations. What to do on rejection, how to open passage manually, where to view the event log, and how to review a disputed case.
-
Handover to operation. We provide the layout diagram, configuration parameters, maintenance regulations, and support contacts—after that the system lives on the security service side, while we remain on support.
Documentation, diagrams, and access regulations
The documentation set is formed in parallel with configuration, not after handover: if the layout diagram and access policies describe the same system state as the configuration, acceptance proceeds without discrepancies.
Below is what the customer keeps in closed form, with version details and the person responsible for updates.
- Project documentation: topology, node composition, redundancy scheme, list of failure points and procedures for eliminating them.
- Layout diagram: floor plans with camera locations by control zones, viewing angles, and overlap boundaries—security uses it to see which passage is controlled and which is not.
- Access policies: rules for matching an employee to a pass, match thresholds separately for passage and for alarm, guest and contractor lists with automatic expiration.
- Security action regulations: what to do on recognition rejection, on an attempt to pass with someone else's photo, on alarm activation, how to issue a manual pass and where it is reflected in the log.
- Administrator instructions: creating and blocking employees, bulk import from the HR system, handling poor-quality images, exporting reports for a period.
- Support service instructions: reading the event log, which errors are resolved on site, which are escalated, how to take a diagnostic snapshot.
- Responsibility matrix and change log: who approves policy edits, how often access is reviewed, where the previous version is stored for rollback.
The set remains operational without us: a new administrator is onboarded into the system according to the instructions, and policy changes do not break already issued passes.
Case: checkpoint of a logistics complex
A logistics complex with four checkpoints and a shift schedule: about 900 people pass through the turnstiles in 15 minutes during shift change, and security manually reviews every disputed pass.
During peak windows the queue stretched outside, and two people entered on one card—the system did not see this.
According to measurements before implementation, throughput held at 380 people per hour, reviewing one disputed situation took an average of 12 minutes, and almost the entire security shift went to investigations instead of perimeter control. At the same time, each checkpoint had its own access policies and its own employee lists.
What was changed
Biometric terminals were installed at the entrance and exit: the face template does not leave the device's secure perimeter, only an identifier goes out.
The terminals were connected to the existing access control system Sigur, leaving the card as a backup passage method—biometric failure does not block the shift.
All checkpoints were connected to a single registry: an employee registers once and works at any point, policies and shift schedules are set centrally. For the warehouse, "face plus card" mode was enabled; for the office part—face only.
After two months, throughput increased to 900 people per hour, disputed case review dropped from 12 to 3 minutes, and the share of card passages fell to 6 percent.
Security was freed from turnstiles and took up patrols: perimeter alarm events are handled three times faster, and an attempt to pass with someone else's card is recorded as an event with a photo rather than discovered after the fact.
How does facial recognition differ from cards and key fobs?
A card and a key fob are an object, not a person. The reader confirms that the tag is in the field but does not check who is holding it: a pass is handed to a colleague, copied onto a blank credential, left in a car.
The access service learns about such an exchange after the fact—by a mismatch in shifts or by a complaint, when the violation has already happened.
| Credential | Transfer to third parties | Wear and maintenance | What happens on loss |
|---|---|---|---|
| Access card | Copied, transferred, no trace remains | Plastic tears and wears, spare stock and reissue needed | Point blocking, reissue, reflashing |
| Key fob | Same, easily moved to someone else's keyring | Mechanical wear, lost more often than a card | Blocking, bypassing all points |
| Mobile pass | Bound to a device: transfer is visible as a second user | The credential is the employee's phone, nothing to replace | Key is revoked remotely |
| Facial recognition | Impossible: the credential is inseparable from the person | No contact elements, no physical wear of the credential | Template is deleted, access is closed |
The difference is not in convenience but in the trust model. Biometrics binds the passage event to a specific person, so the access log becomes evidentiary rather than approximate: access cannot be "lent out" during vacation.
Maintenance costs also stop growing with each new employee—template updates and frame quality control remain instead of purchasing and reissuing credentials.
Biometrics does not remove infrastructure requirements: correct camera installation, control of lighting and angle, and processing of biometric data according to its protection rules are needed.
Therefore, at critical checkpoints we usually leave a backup scenario—a card or mobile pass for guests and contractors.
Technical doubts: answering frequent questions
Doubts about such systems are usually not about identification itself but about operation: what happens to the data, how the camera behaves in backlight, and whether new equipment can be connected to existing turnstiles.
What personal data does the system store?
Not a photograph and not video—a biometric template, a numerical vector from which the original image cannot be reconstructed.
Templates are stored in the customer's perimeter, access to them is restricted, and retention period and deletion procedure are fixed in the data processing policy. The passage log is kept separately: time, point, result—without images.
What happens in difficult lighting?
Backlight, oncoming glare from a window, deep shadow are the main sources of false rejections. We close them with a combination: camera installation point and height, illumination of the working range, a separate capture scenario for street entrance. In complex geometry we install two cameras with zone overlap—the system takes the best frame.
Will old turnstiles have to be replaced?
As a rule, no. The recognition module sends the controller the same "passage permitted" signal as a card reader, so the turnstile mechanics and current access controller remain in place.
Replacement is needed where the controller is closed to integration—this is determined during the survey.
Can the transition to recognition be gradual?
Yes, usually we launch the first points in parallel with cards: we accumulate statistics on false admits and activations, and tune the threshold for the real flow. Full transfer of a zone and scaling to other entrances happens only after that; office operations do not stop.
Let's discuss the task: where we start work
So that project assessment is based on facts rather than assumptions, we ask for a minimal set of input data. Usually it is enough to understand the scope of work and not include unnecessary equipment.
- Access points: how many entrances and checkpoints, what they are equipped with now—turnstile, lock, barrier.
- Scenario: whom we admit—employees, visitors, contractors; whether separate time tracking is needed.
- Infrastructure: whether there is a network to the points, places for installing cameras and controllers, possibility to bring power.
- Current systems: what is used for passes today and whether there is an HR database with suitable photos.
- Reliability requirements: acceptable false rejection and false admit rates, whether a second factor is needed—card or code.
- Legal framework: how biometric processing consents are formalized and how long templates are stored.
- Site constraints: work windows for installation, security service requirements, operating mode.
Then the procedure is: we discuss the task and boundaries of the first stage, show the solution diagram with camera placement and decision logic, then fix the staged work plan and implementation timelines for each point.
Project assessment comes together with the plan—broken down by points so that work can be scheduled in phases. If the site is distributed, we start with one checkpoint: test scenarios on real people and replicate to the others.
