The gap between demo and production Face recognition demonstrations typically use controlled conditions: frontal face, adequate lighting, high-resolution close-up camera, cooperative subject. CCTV footage has none of these. Faces appear at distance, at angle, under variable and often poor lighting, partially occluded, and in motion. Production face recognition from CCTV streams performs substantially worse than controlled-condition benchmarks — often by a margin that makes real-time recognition impractical outside specific, constrained scenarios. Understanding why production performance degrades — and where it does not — is the difference between a deployment that delivers operational value and one that delivers tens of false alerts a day. Before getting into the geometry and the compliance reality, it is worth situating this piece against the broader pipeline: detection, alignment, embedding, and matching against a gallery are explained end-to-end in facial recognition in computer vision: how the pipeline actually works. This article zooms in on the production-environment failure modes of stage one and stage four — the parts that CCTV geometry actually breaks. How does face resolution determine whether recognition is viable? Face recognition models require a minimum face size in pixels to extract a discriminative embedding. Below that threshold, the network has insufficient information; accuracy collapses and false positive rates climb. The thresholds below are observed-pattern guidance across our deployments — they are not a benchmarked rate, and the precise numbers shift with the embedding model in use. Use Case Minimum Inter-Ocular Distance Approximate Face Height Notes Detection only (is there a face?) 10–20 pixels 30–50 pixels Reliable detection; no recognition Low-confidence recognition 30–40 pixels 70–90 pixels Recognition possible; high error rates Operational recognition (1:1 verification) 60–80 pixels 140–180 pixels Practical accuracy for controlled scenarios Watchlist matching (1:N search) 80–120 pixels 180–280 pixels Required for acceptable FAR in large galleries High-confidence identification 120+ pixels 280+ pixels Approaches benchmark accuracy levels A person standing 5 metres from a standard 1080p camera with a 4mm lens — the geometry of most indoor CCTV — fills roughly 80–120 pixels of face height. At 10 metres, that drops to 40–60 pixels, below the threshold for reliable recognition. At 15–20 metres, face recognition is not operationally viable without specialised long-range cameras carrying telephoto lenses. The implication is structural, not algorithmic: most building CCTV cameras are not positioned for face recognition. They are positioned for scene coverage. Retrofitting recognition onto existing camera infrastructure typically yields poor results because the cameras are simply too far from subjects. No upgrade of the embedding model fixes this — the missing pixels were never recorded. Angle, occlusion, and the geometry of real corridors Face recognition models are trained predominantly on frontal and near-frontal images. Performance degrades with yaw (side-to-side rotation) and pitch (up-down tilt) along a fairly predictable curve: Up to ±15° yaw: accuracy close to frontal baseline. ±15–30° yaw: moderate degradation, typically a 10–20% drop in verification accuracy. ±30–45° yaw: significant degradation; recognition is unreliable for watchlist matching. Beyond ±45° (near-profile): recognition is not viable with standard models. In building CCTV, people rarely present a frontal face to cameras. Corridor-mounted cameras see the tops of heads. Entry cameras see a mix of frontal and angled views depending on approach geometry. The only camera position that consistently generates usable face data is at the entry point of a controlled access lane — where subjects stop, look forward, and stand close enough to fill the pixel budget. Partial occlusion compounds the problem. Glasses, masks, hats, and hair across the forehead each remove signal that the embedding network was trained to rely on. Post-pandemic deployments that were specified before widespread mask use saw substantial accuracy degradation when masks became common, and the recovery required either model retraining on masked-face datasets or a workflow change that treated mask-wearing subjects as out-of-distribution for matching. False positive rates in watchlist matching The false positive rate (FAR) — the probability that a genuine non-match is incorrectly flagged as a hit — is the operational risk metric for CCTV face recognition. In watchlist applications, false positives mean innocent people being flagged and reviewed. The cost is human review time, the legal exposure is real, and the reputational exposure scales with deployment size. FAR is a function of two things: the matching threshold, and the size of the gallery. A threshold calibrated for 0.1% FAR in a 1:1 verification scenario produces a higher effective FAR in 1:N watchlist matching because each capture is now compared against every gallery entry — every comparison is another opportunity for a false match. Across our deployments, the realistic operating range for CCTV watchlist matching with mixed angles, mixed image quality, and diverse subject populations is the following observed pattern (not a benchmarked rate; portability to other camera estates and other embedding models is limited): 1–5% FAR at thresholds that achieve roughly 80% true positive rate. 0.1–1% FAR at thresholds that achieve 50–60% true positive rate. In a high-throughput deployment — a shopping centre processing thousands of face detections per day — a 1% FAR generates tens of false flags daily. Each flag triggers human review; the cumulative alert volume is what makes the deployment operationally unsustainable, not any single missed identification. Designing the workflow around the alert rate, not around the demo accuracy figure, is the part most procurements skip. GDPR and the compliance reality Face recognition in the EU is governed by GDPR Article 9, which treats biometric data processed for identification purposes as a special category requiring an explicit legal basis. The lawful-basis options practically available for CCTV face recognition are narrow: Explicit consent is workable for access control with voluntary enrolment; it is not workable for general surveillance because the subjects passing through a camera’s field of view have not given consent. Vital interests is very narrow and does not apply to general security use. Substantial public interest (Article 9(2)(g)) requires a specific national-law provision; it is not a catch-all authorisation. Legitimate interests is contested for surveillance purposes. Data Protection Authorities in France, the UK, and Sweden have ruled against legitimate interests as a basis for mass biometric surveillance. The practical compliance path runs through five steps: define the specific purpose (watchlist matching for loss prevention, access control for enrolled employees — not “security in general”); complete a Data Protection Impact Assessment before deployment, which is mandatory under GDPR Article 35 for systematic biometric processing; establish a specific legal basis tied to that purpose; minimise the biometric data retained, typically storing embeddings rather than face images and setting defined retention windows; and place required transparency notices at entry points. Retailers and building operators in the EU who have deployed face recognition without a completed DPIA and explicit legal basis have faced enforcement action from national DPAs. This is not a theoretical risk; the published rulings name operators and quantify the fines. CCTV face recognition compliance checklist Specific purpose defined (not “security in general”). Legal basis identified and documented for the specific processing purpose. DPIA completed and filed before deployment. Transparency notices placed at entry points. Enrolment process documented (how are subjects added to watchlist or access list?). Retention period defined for biometric embeddings and face images. Subject rights procedures in place (access, deletion, correction). Vendor data processing agreement reviewed for GDPR compliance. Where CCTV face recognition actually works Despite the challenges, face recognition from CCTV is operationally viable in specific, constrained scenarios. The pattern is consistent: every viable scenario controls the geometry that the open building does not. Controlled access lanes — a single entry point, cooperative subject, camera positioned at 1–3 metres, frontal orientation enforced by physical design. Small-gallery matching — a watchlist of under roughly 100 known individuals in a specific venue context (staff access, VIP recognition in controlled environments). Small galleries keep the 1:N comparison count low and the effective FAR manageable. Post-incident investigation — after-the-fact matching of captured face images against a suspect gallery, with human expert review at every step. This is not real-time alerting; it is forensic search. High-value asset zones — small areas with dedicated high-resolution cameras positioned for face-compatible geometry, treated as a separate sub-system from the wider CCTV estate. General deployment of face recognition analytics across building CCTV infrastructure — the implicit promise of identifying individuals from standard ceiling-mounted cameras — does not deliver operational results that justify the cost and the compliance burden, in our experience. The systems that work are the ones designed for recognition from the camera plan upward, not the ones bolted onto an existing surveillance estate. The honest framing for a procurement conversation is therefore narrow: which lane, which gallery, which review workflow. A vendor demo that does not answer those three questions is not describing a system you can deploy. FAQ How does the facial recognition pipeline decompose — detection, alignment, embedding, matching? Detection locates faces in a frame, alignment normalises pose and scale, an embedding network produces a fixed-length vector representing identity, and matching compares that vector against a gallery using a distance threshold. CCTV stresses stage one (small, angled faces) and stage four (large galleries inflate the effective false positive rate). The full pipeline is laid out in facial recognition in computer vision: how the pipeline actually works. Why is MTCNN typically preferred over Haar cascades in modern face detection, and where does that trade-off flip? MTCNN handles pose variation and partial occlusion far better than Haar cascades because it learns features end-to-end rather than relying on hand-engineered intensity contrasts. Haar can still win on extremely low-power edge devices where MTCNN’s three-stage CNN does not fit the compute budget — at the cost of recall on non-frontal faces. Where does facial recognition sit in the broader CV pipeline (image recognition, pattern recognition, deep learning)? Face recognition is a specialisation of pattern recognition, implemented today with deep-learning embedding networks. It sits downstream of image recognition (which classifies whole scenes or objects) and shares architectural ancestry with other metric-learning systems. What are the realistic accuracy and bias limits of production facial recognition in 2026 deployments? True positive rates of 50–80% at operationally acceptable false-positive thresholds are realistic for CCTV watchlist matching; demographic bias remains measurable, with elevated error rates for under-represented groups in training data. These are observed patterns across our engagements, not benchmark figures. Which CV algorithms (eigenfaces, deep embeddings, transformers) are still relevant for face recognition, and which are obsolete? Deep CNN embeddings (ArcFace-style) are the production default; vision transformers are competitive on benchmarks and increasingly deployed. Eigenfaces and other PCA-based methods are obsolete for operational use, retained only as teaching examples. How does facial recognition deployment differ across cloud, on-device, and edge inference settings? Cloud deployment centralises the gallery and the model but raises GDPR transfer questions. On-device (e.g. access-control terminals) keeps embeddings local and simplifies consent. Edge inference on the camera reduces network load and supports retention minimisation, but constrains the embedding model size — which in turn affects the achievable accuracy.
