Pedestrian & Door Access Control

Face recognition-powered entry for gates and staff doors — no fobs, no cards, no friction

Access Control That Knows Your Face

We've taken the same AI and cloud-native technology behind our ANPR platform and extended it into pedestrian access control. The result: a face recognition system that manages who enters your building or gates — automatically, securely, and without a single card or fob in sight.

Whether you need to control an outdoor pedestrian gate, a staff entry door, or an entire building's access hierarchy, our platform handles it. Permissions can be managed from our dashboard directly, or driven automatically by your existing HR software via our API — so when someone joins or leaves your organisation, their access is provisioned or revoked instantly, with no manual IT intervention required.

99.5%
Face Match Accuracy
<1s
Unlock Response Time
0
Cards or Fobs Required
24/7
Automated Monitoring

How It Works

From face to unlocked door in under one second

1
Approach & Capture

Person approaches the door or gate. An IP camera captures a high-quality frame of their face in real time.

2
Liveness & Match

AWS Rekognition checks for liveness (preventing photo attacks), then searches the enrolled face collection for a match with a confidence score.

3
Permission Check

The matched identity is checked against their permissions: is this door allowed? Is it within their schedule? Does their role grant access?

4
Unlock & Log

Door unlocks instantly. Every access event — granted or denied — is written to an immutable audit log with person ID, door, timestamp and confidence score.

Event Flow — Happy Path

Person approaches door or gate
IP camera captures face frame
AWS Rekognition liveness check (anti-spoofing)
SearchFacesByImage — match against enrolled collection
✓ Match > 95% confidence — identity confirmed
✗ Below threshold → Access denied, event logged
Permission check: door allowed? schedule valid? role matches?
Unlock signal sent — door opens — audit log written

Ready to Ditch the Fobs?

Face recognition access control — cloud or on-premise — installed and running in weeks, not months

Who Is This System For?

Three types of customers, one platform

01
The All-In-One Customer
No HR. No access control. Starting fresh.

Growing SMEs and multi-site businesses currently relying on keys, paper sign-in, or unmanaged fobs. One vendor, one contract — we handle everything.

  • Keys get lost or copied — no audit trail
  • No way to remotely revoke ex-employee access
  • Manual visitor sign-in with no digital record
  • No compliance reporting
Full stack — hardware, install, SaaS
02
The Integration Customer
Has HR. Needs smart doors that plug straight in.

Already running BambooHR, Sage, or similar. Want HR data to drive door access automatically — day one provisioning, instant revocation on exit.

  • HR offboarding doesn't kill building access
  • IT teams manually manage fob lists — slow, error-prone
  • No audit trail linking HR identity to physical access
  • Lost cards are a recurring headache
Hardware + SaaS + HR API integration
03
The Switcher
Has a legacy system. Wants better tech, lower cost.

Running Paxton, HID, or Salto — approaching end of contract, frustrated by fob admin costs, or locked out of modern integrations. Face recognition is the upgrade.

  • High cost of issuing and replacing physical cards
  • On-premise system — no remote management
  • Expensive vendor maintenance contracts
  • No API — can't connect to HR or other systems
Hardware refresh + full platform migration

Two Deployment Models

Same platform, same features — choose where your data lives

Cloud Hosted
Managed by us · Runs on AWS eu-west-2 (London)
Face MatchingAWS Rekognition
Biometric DataAWS eu-west-2 (London)
DatabaseAWS RDS (managed)
MQTT BrokerAWS IoT Core
Admin DashboardAny browser, anywhere
UpdatesAutomatic — zero effort
Pricing ModelPer-door monthly SaaS

Best for most businesses

Our cloud model is the fastest path to deployment. We manage everything — the infrastructure, updates, monitoring, and backups. Your team just uses the dashboard and manages permissions. Biometric data is held in AWS London (eu-west-2) and never leaves the UK.

  • Zero infrastructure to manage — no servers to buy, configure or maintain
  • Instant updates — new features and security patches applied automatically
  • UK data residency — all biometric data stays in AWS eu-west-2 (London)
  • Scales automatically — add doors and sites with no infrastructure planning
  • Accessible from anywhere — manage permissions and review audit logs from any browser
Ideal for: SMEs, multi-site operators, businesses without dedicated IT teams, and ANPR customers looking to extend their existing contract.
On-Premise
Runs inside your network · You control the data
Face MatchingCompreFace (self-hosted)
Biometric DataYour server — never leaves premises
DatabasePostgreSQL (self-hosted)
MQTT BrokerMosquitto (self-hosted)
Admin DashboardInternal network / VPN only
UpdatesVersioned Docker releases
Pricing ModelAnnual software licence

For organisations where data sovereignty is non-negotiable

In some sectors, biometric data simply cannot leave your own infrastructure — regardless of where the cloud servers are located. Our on-premise model runs entirely within your network. No biometric data ever touches a third-party cloud. You are the sole data controller and processor.

  • Complete data sovereignty — biometric data never leaves your premises
  • No third-party processors — you are the sole data controller under UK GDPR
  • SIEM integration — audit logs exportable to Splunk, Microsoft Sentinel and more
  • Signed Docker images — cryptographically verified updates, applied on your schedule
  • Air-gapped capable — the system can operate with no internet connectivity whatsoever

Sectors that require on-premise:

Government NHS / Healthcare Financial Services Legal Defence Universities

Powerful Access Control Features

Everything you need to manage who goes where — and when

AWS Rekognition Face Matching

Industry-leading face recognition via AWS Rekognition. No custom AI engine to build or maintain — we leverage managed infrastructure for 99.5%+ accuracy with built-in liveness detection to prevent photo and screen-based spoofing.

Role-Based Permissions

Assign roles to people, not doors. A "Finance Manager" role automatically grants the right doors — main entrance, finance floor, meeting rooms. Add a new employee to a role and they have full access from day one.

Time-Based Schedules

Configure access windows per person, role, or door. A valid face match outside permitted hours is automatically denied and logged. Visitor day passes, contractor access windows, and out-of-hours restrictions all managed in one place.

HR Software Integration

Connect BambooHR, Sage, or any HR platform via our REST API. New employees get access provisioned on their start date. When HR processes a leaver, their face is removed from every door instantly — no IT ticket required.

Full Audit Trail

Every access event — granted, denied, emergency unlock, or out-of-hours attempt — is logged with person ID, door, timestamp, and confidence score. Exportable for compliance reporting, insurance, or SIEM integration.

Offline Fallback Mode

Door controllers maintain an encrypted local cache of permitted face vectors. If internet connectivity drops, access continues for known faces — with events queued and synced when connectivity is restored. Your building never locks out your staff.

Built for the Real World

We've thought through every failure scenario — not just the happy path

Every door has a configurable fail behaviour set at installation time — fail-safe (lock releases, door opens) for life-safety doors, or fail-secure (lock holds) for high-security areas. A small UPS on each door controller bridges short outages without changing behaviour at all.

Fail-Safe doorsGates, fire exits — lock releases on power loss. Life safety always wins.
Fail-Secure doorsHigh-security staff areas — lock holds on power loss.
UPS fittedNormal operation continues for the battery duration — most outages bridged.
Power restoredControllers reconnect automatically. No manual reset required.

Door controllers maintain an encrypted local cache of permitted face vectors — raw images are never stored locally, only compact face templates. If the internet goes down, your staff still get in.

Known face (cached)Access granted locally. Event queued for audit log sync when connectivity returns.
Unknown faceAccess denied. Admin can issue a remote unlock via fallback channel.
Cache TTLConfigurable expiry (e.g. 24hrs). Expired cache triggers deny and alert.
ReconnectedController re-syncs with cloud. All queued audit events flushed automatically.

Fire alarm integration is hardwired — a dry contact input on each door controller wired directly to the building fire panel. It operates completely independently of network, cloud, and software. This is a legal requirement under UK fire safety regulations.

Alarm triggeredAll fail-safe doors release immediately. Face recognition bypassed entirely.
Fail-secure doorsAlso release via hardwired override — legally required.
Audit loggedFIRE_ALARM_OVERRIDE reason code written with timestamp per door.
Alarm resetDoors return to normal access control mode automatically.

TailgatingDoor held open beyond expected duration after valid unlock → admin alert raised.
Low confidence matchBelow 95% threshold → access denied, flagged for admin review.
Camera tamper / obstructionNo valid frame detected → door defaults to fail state → tamper alert raised.
Out of hours attemptValid face, valid door — but outside their permitted schedule → denied and logged.

A lockdown is the deliberate, software-initiated locking of all or selected doors — the operational opposite of a fire alarm. Where a fire alarm releases doors for evacuation, a lockdown seals them to prevent movement during a security threat. During an active lockdown, face recognition does not fail — it is deliberately overridden. Even a confirmed face match will be denied if a lockdown is active.

Trigger methods:

Admin dashboard (one-click lockdown) Platform API (POST /v1/sites/{id}/lockdown) Hardwired panic button at door controller Mobile app for roaming security staff

Lockdown levels:

Level 1 — Soft
Entry locked, exit open

External doors lock — no new entries. People inside can still exit. Face recognition disabled on entry doors only.

Level 2 — Full
All doors locked

All doors lock — entry and exit. No movement permitted. Fire alarm override remains active and legally cannot be disabled.

Level 3 — Selective
Zone or door specific

Specific zones, floors, or individual doors locked while others remain in normal operation. Isolate a threat area.

Face match during lockdownEven a confirmed 99% match is denied. Reason code: LOCKDOWN_ACTIVE — logged with person ID, door, and lockdown level.
Exempt rolesSecurity personnel, designated responders, and emergency services can be configured as lockdown-exempt. All exemption grants are still audit logged.
Lifting a lockdownManual lift via dashboard or API, automatic timeout (e.g. 30 mins), or all-clear signal from integrated alarm system.
Hardwired panic buttonOptional add-on (~£20–£50/door) wired to dry contact input on the controller. Triggers door-level lockdown instantly — no cloud dependency.
Lockdown vs Fire Alarm — The Hierarchy

Fire alarm always wins. If a fire alarm triggers during an active lockdown, all fail-safe doors release immediately — regardless of lockdown state. This hierarchy is hardwired at the controller level and cannot be changed by any software configuration.

Fire alarm = unlock (hardwired). Lockdown = lock (software). One always overrides the other.

API-First Design

Every feature in our dashboard is available via a clean REST API — so your HR software, visitor management system, or internal tools can drive access control automatically.

Person & Enrolment
POST/v1/personsCreate a person record
POST/v1/persons/{id}/faceEnrol a face — triggers Rekognition IndexFaces
DEL/v1/persons/{id}Remove person + biometric data (GDPR erasure)
Permissions & Doors
POST/v1/permissionsGrant door access to a person
PUT/v1/permissions/{id}Update schedule or role
POST/v1/doors/{id}/unlockRemote manual unlock
Audit & Webhooks
GET/v1/audit-logQuery access events
POST/v1/webhooksReal-time access event notifications
HR Integration Lifecycle
New hire onboarded in HR
HR calls POST /v1/persons — record created instantly
Face enrolled
HR uploads photo → Rekognition IndexFaces → face added to collection
Permissions auto-applied
Role rules grant all relevant doors. Access live on start date.
Day one — they walk straight in
No IT ticket. No fob collection. No manual setup.

Employee leaves
HR calls DELETE /v1/persons/{id} → face removed from Rekognition → local caches invalidated → access revoked across all doors in real time.

Under the Hood — How the Technology Works

From camera to unlocked door — the complete technical flow

The Camera Bridge

A standard IP camera is a dumb device — it only streams video. It cannot call an API. We use a Hikvision smart face terminal which combines camera, onboard processor, and relay in a single wall-mounted unit. When it detects a face, it captures a JPEG and fires it directly to AWS API Gateway via HTTP POST — no separate edge device needed.

Full Event Flow

Hikvision TerminalFace detected → JPEG captured → HTTP POST fired
AWS API GatewayPublic HTTPS endpoint — validates API key, triggers Lambda
AWS LambdaCalls Rekognition, checks permissions, fires unlock signal
AWS RekognitionSearchFacesByImage — returns match + confidence score
Match ≥ 95% + permission check passed
Your Platform APIReceives unlock instruction from Lambda
Door Controller → Lock ReleasesRelay triggered — electric strike or mag lock opens

What Rekognition actually stores:

Face templates (mathematical vectors) only — not images. The door camera photo is never stored. Templates cannot be reverse-engineered into a photograph.

The Last Mile — Platform to Door Controller

Your cloud platform cannot reach a door controller on a customer's private network directly. We solve this with one of two approaches depending on the installation:

MQTT
via AWS IoT Core

Controller maintains a persistent outbound connection to AWS IoT Core. Platform publishes an unlock message to a door-specific topic — controller receives it instantly.

Latency~50–100ms
Port forwardingNot required
Static IP neededNo
SecurityTLS + device certs + JWT
Recommended
Webhook
Public HTTPS URL

Platform calls a public HTTPS URL on the controller (or edge device). Customer needs port forwarding and a static IP or dynamic DNS service.

Latency~100–300ms
Port forwardingRequired
Static IP neededYes / dynamic DNS
SecurityHTTPS + secret token
Simple installs
Polling
Controller polls API

Controller asks your API for queued commands every 1–2 seconds. Simple but adds noticeable latency. No firewall changes needed.

Latency0–2 seconds
Port forwardingNot required
Static IP neededNo
SecurityHTTPS + API key
Fallback only
Response Time — End to End
Step Typical Time
Hikvision captures face~200ms
HTTP POST to API Gateway~50–100ms
Lambda (warm) + Rekognition~250–450ms
Permission check + unlock signal~100–200ms
Door controller triggers lock~50–100ms
Total (warm Lambda)~650ms – 1,050ms

Sub-second response feels instant at the door — comparable to a fob or card reader. Lambda is kept warm via a scheduled CloudWatch ping every 5 minutes.

GDPR & Biometric Data Compliance

Face recognition data is classified as special category biometric data under UK GDPR (Article 9). We take this seriously. Both deployment models are built from the ground up to meet these obligations.

Right to Erasure

A single API call removes all biometric data — from Rekognition collections and all local door controller caches. Fully compliant with UK GDPR Article 17.

UK Data Residency

Cloud model: all biometric data held in AWS eu-west-2 (London). On-premise model: data never leaves your building. Both fully UK GDPR compliant.

Data Minimisation

Only compact face vectors (templates) are stored — not raw images. Templates cannot be reverse-engineered into photographs.

Audit Trail

Every data access, deletion, permission change, and access event is logged. Full audit trail for DPIA compliance, ICO enquiries, and internal governance.

Important: Required Before Go-Live

As biometric data is special category data, the following steps are mandatory before deploying any face recognition access control system:

  • Complete a Data Protection Impact Assessment (DPIA)
  • Establish the lawful basis — explicit consent or legitimate interest — documented per person
  • Install physical privacy notices at every access point informing of face recognition use
  • Confirm a documented biometric data retention and erasure policy

We provide compliance documentation templates and can refer you to specialist legal advisors as part of our onboarding process.

How We Compare

Face recognition at the price of a card system — with the integrations a modern business actually needs

Paxton Net2
UK market leader — fobs & cards
Install per door£400–£900
Software licence£20–£100/door/yr
SaaS / cloudNone — PC only
Fob / card cost£1–£8 each
Face recognitionNot available
HR APINot available
Market leader
Salto KS
Cloud subscription — wireless locks
Install per door£500–£1,000
SaaS per door£10–£25/door/month
Card cost£3–£12 each
Face recognitionAdd-on +£700–£1,000/door
HR APILimited partner only
5yr cost (10 doors)~£25,500+
Expensive long-term
Generic biometric
Standalone face terminals — no cloud
Hardware per door£350–£1,300
SaaS / cloudNone
Credential cost£0 (biometric)
Remote managementNot possible
HR APINone
Revoke on leaverManual — per device
No cloud, no API
Our system
Face recognition + cloud + HR API
Install per door£330–£730
SaaS per door£15–£30/door/month
Credential cost£0 — face is the key
Face recognitionIncluded — AWS
HR APIFull REST API
5yr cost (10 doors)~£18,800
Our proposition

5-year total cost of ownership

Based on a 10-door site with 100 staff. Includes hardware, install, software, credentials, and maintenance. Face recognition included where available.

Paxton Net2 No face recognition included
£11,600
Salto KS Without face recognition
£25,500
Salto KS With XS4 Face add-on
£33,000+
Generic biometric No cloud, no support
£8,250
Our system Face recog + cloud + HR API included
£18,800

We save ~£14,200 vs Salto KS with equivalent face recognition capability over 5 years.

The credential cost nobody talks about

On a 100-person site with 15% annual staff turnover, here's what competitors charge just for replacement credentials every year — before any other costs.

Paxton fobs
£150–£1,200
per year, every year
Salto cards
£450–£1,800
per year, every year
Our system
£0
The face is the credential. It can't be lost, cloned, or left at home.

Calculate your savings vs Salto KS

Adjust the sliders to see how much you'd save switching to our platform

10
100
15%
Salto KS 5yr cost
£25,500
incl. cards + licence
Our system 5yr cost
£18,800
incl. face recog + support
Annual credential saving
£900
vs Salto cards
Your estimated 5-year saving vs Salto KS with face recognition
£14,200

Why switch from your current system?

Whether you're running Paxton, Salto, or a standalone biometric terminal — here's what you gain by moving to our platform.

Talk to us about switching
No more fobs, cards, or key admin The face is the credential. Staff can't lose it, forget it, or share it. No re-issuing when someone leaves — their access is revoked the moment HR processes the departure.
HR system drives access automatically Connect BambooHR, Sage, or any system via our REST API. New starter gets access on day one — no IT ticket. Leaver loses access in real time — no security gap.
Manage everything from your browser No PC software to install, no VPN required. Add doors, update permissions, review the audit log, and trigger a lockdown — all from any browser, anywhere.
Save ~£14,200 vs Salto KS over 5 years Based on a 10-door site with 100 staff. We include face recognition as standard — Salto charges £700–£1,000 extra per door on top of their cloud subscription.
One price, no hidden extras Our SaaS fee covers face recognition, cloud management, the audit trail, HR API access, and hardware maintenance. No licence fees on top. No surprises.

Ready to Ditch the Fobs?

Face recognition access control — cloud or on-premise — installed and running in weeks, not months

Frequently Asked Questions

Common questions about face recognition access control

Because face matching is handled in the cloud by AWS Rekognition, you don't need expensive edge AI cameras with onboard processing. A good quality IP camera (2MP or higher, with decent low-light performance) is sufficient — which is actually a significant hardware saving compared to edge-based competitors. For outdoor gates, we recommend weatherproof housing and cameras with IR capability for night-time operation. We'll specify the right camera for each location as part of our installation survey.

AWS Rekognition includes a Face Liveness feature that verifies the subject in front of the camera is a real, live person — not a photograph, video, or 3D mask. The liveness check runs before the face match, so any spoofing attempt is caught before it reaches the identity lookup. We recommend enabling liveness checking on all outdoor gates where spoofing risk is higher, and it can optionally be disabled on internal staff doors where the physical environment provides additional security context.

Door controllers maintain an encrypted local cache of permitted face vectors — so known, enrolled staff can still access the building during an internet outage. The cache contains face templates only (not raw images) and is encrypted at rest on the controller. Any access events during the outage are queued locally and automatically synced to the audit log when connectivity is restored. Unknown faces (people not in the local cache) will be denied during an outage, and an admin can issue a manual remote unlock via a fallback channel if needed.

Enrolment is straightforward. A photo of the employee is uploaded via our dashboard or via the API (for HR system integrations). We send this to AWS Rekognition's IndexFaces function, which extracts a compact face template and stores it in the client's collection. The raw photo is not retained after the template is extracted. The employee is then assigned a role or specific door permissions, and they're ready to go. The whole process takes under a minute. For HR-integrated customers, enrolment can be fully automated as part of your existing onboarding workflow.

Absolutely. Each door or gate is configured independently. You can set different fail modes (fail-safe vs fail-secure), different access schedules, different role requirements, and different confidence score thresholds per door. A main entrance might be fail-safe with a 9am–7pm schedule for all staff, while a server room is fail-secure with a 95% confidence threshold and restricted to IT Engineers only. Time-based rules, zone-specific rules, and role-based access can all be combined in any combination.

Fire alarm integration is hardwired — not software-dependent. Each door controller has a dry contact input that connects directly to the building fire alarm panel. When the alarm triggers, all doors configured as fail-safe release immediately, regardless of the state of the internet, cloud, or software. This is a legal requirement under UK fire safety regulations, and our installation process includes verifying this integration with your fire alarm contractor. All emergency unlock events are logged with a FIRE_ALARM_OVERRIDE reason code and timestamp.

Yes — both deployment models are designed to meet UK GDPR obligations for special category biometric data. Key protections include: UK data residency enforced at infrastructure level, data minimisation (face templates stored, not raw images), right to erasure via API (removing data from all collections and local caches), and a full audit trail. That said, face recognition does require a Data Protection Impact Assessment (DPIA) before deployment, and you'll need physical privacy notices at each access point. We provide compliance documentation templates and can point you towards specialist legal advisors as part of our onboarding process.

Both models offer identical features. The difference is where the software runs and where biometric data is stored. Cloud: everything runs on our AWS infrastructure in London, managed by us, billed monthly per door. On-premise: everything runs on a server inside your network, biometric data never leaves your building, billed as an annual software licence. On-premise is aimed at organisations in regulated sectors — government, NHS, finance, legal, defence — where data sovereignty requirements prohibit cloud storage of biometric data. The on-premise model uses CompreFace (an open-source, self-hosted face matching engine) as a drop-in alternative to AWS Rekognition.

The Hikvision smart face terminal has an onboard processor that detects a face in its camera feed, captures a JPEG still image, and immediately fires an HTTP POST to your AWS API Gateway endpoint — a standard public HTTPS URL. The image travels over the internet to API Gateway, which validates the device's API key and triggers a Lambda function. The Lambda function extracts the image and calls AWS Rekognition to perform the face match. The Hikvision's built-in face matching is deliberately disabled — AWS Rekognition handles all matching centrally, so enrolling a new person once makes them accessible at every door instantly.

Your platform can't directly reach a door controller on a customer's private network, so we use one of two approaches. For production and multi-site installations, we use MQTT via AWS IoT Core — the door controller maintains a persistent outbound connection to IoT Core, and when an unlock is needed, your platform publishes a message to a door-specific topic which the controller receives instantly (~50–100ms). For simpler installations, the controller exposes a public HTTPS webhook URL that your platform calls directly — this requires port forwarding on the customer's router but is easier to set up. Both approaches use signed tokens for security.

A lockdown is a deliberate, software-initiated locking of all or selected doors in response to a security threat — the operational opposite of a fire alarm. During an active lockdown, face recognition does not fail — it is deliberately overridden. Even a confirmed face match at 99% confidence will be denied if a lockdown is active, and the event is logged with a LOCKDOWN_ACTIVE reason code. Lockdowns can be triggered via the admin dashboard, the API, a mobile app, or an optional hardwired panic button at any door controller. There are three lockdown levels: soft (entry locked, exits open), full (all doors locked), and selective (specific zones or doors). Certain roles — such as security personnel and designated responders — can be configured as lockdown-exempt. Crucially, a fire alarm always overrides an active lockdown — fail-safe doors will release immediately regardless, as this is hardwired at controller level and cannot be changed by software.

Our all-in installation cost of £330–£730 per door is comparable to Paxton and lower than Salto — but with face recognition included as standard, which neither offers without significant additional cost. Paxton doesn't offer face recognition at all. Salto charges £700–£1,000 extra per door for their XS4 Face add-on hardware. On our monthly SaaS of £15–£30 per door, you get face recognition, cloud management, the HR API, audit logging, and hardware maintenance — all included. There are no hidden licence fees on top. On a 10-door site over 5 years, our platform costs approximately £14,200 less than Salto KS with equivalent face recognition capability.

It depends on what you need. If you just want basic card or fob access with no cloud management and no face recognition, Paxton Net2 is a solid, cost-effective system. However, if you want face recognition — which Paxton simply doesn't offer — you'd need to either add a separate biometric system or switch platforms entirely. If you want HR system integration for automatic provisioning and revocation, or cloud-based management without a Windows PC on site, Paxton can't deliver those either. We'd suggest a conversation about your specific requirements — we can model the 5-year cost comparison for your site and be upfront about whether switching makes financial sense.

Get In Touch

Fields marked as * are mandatory.

Related Features

ANPR Camera Management

Centralized control of all ANPR cameras with health monitoring, firmware updates, configuration management, and real-time diagnostics across multiple sites.

Learn More

Automated PCN Management

Detect violations and issue parking charge notices automatically — from detection to legally compliant notice in under 60 seconds.

Learn More

Flexible Payments

Accept all payment types including contactless, mobile wallets, subscription-based parking passes, and event-specific ticketing integration.

Learn More