Face-based identity verification
Positioning
Face recognition combines detection, alignment, feature extraction, matching and liveness checks. Potential applications include access control, attendance and event check-in, identity verification, payment authentication and authorised security alerts. Facial data is sensitive personal information. Design and delivery must be lawful, justified and necessary, with data minimisation, appropriate consent, protected storage, access and deletion processes.
Core functions
Recognition and access functions
Face detection and landmark localisation, including evaluation under different angles, partial occlusion, masks and multiple-person scenes.
1:1 verification, including live-image and identity-document comparison; 1:N matching within an authorised access or attendance database; and N:N grouping for permitted uses.
RGB passive or prompted liveness checks, or near-infrared/structured-light options, with testing against photographs, replay, masks and deepfake attacks.
Image-quality scoring and rejection of unsuitable captures. Optional attribute processing requires a clearly defined purpose and notice and must be capable of being disabled.
Separate databases and groups, validity periods, enrolment, updates, removal, image search and handling of unknown visitors.
Area- and time-based access rules, visitor permissions, allow/deny lists where justified, and combinations with cards, passwords or identity documents.
Operations and individual rights
Record entry and exit, occupancy, departmental/time-period statistics and exceptions such as tailgating, reverse passage or extended presence. Attendance functions may include shift rules, correction/appeal workflows and HR integration; check-in may support meetings, training and examinations. Visitor registration should support time-limited permissions and defined retention. Provide routes to request access, correction, deletion, withdrawal of consent and account closure.
Technical approach
Access terminals can capture and compare locally for offline operation. Edge equipment may support multi-stream processing and liveness checks; a central platform manages templates, permissions, audits and algorithm updates. Protect biometric templates with a suitable cryptographic design and avoid making stored original face images the only credential. Do not assume that a simple hash alone makes biometric matching or privacy protection adequate.
Indicative acceptance targets
The reference design proposes a 1:N recognition rate of at least 99% for a database of 100,000 identities under an agreed dataset and lighting, with FAR at or below 0.1% or a stricter project threshold. Review false rejection rates for access usability. Indicative end-to-end detection and matching targets are 500 ms locally and 1 second over a network. The reference anti-spoofing target is at least 99% rejection of the tested printed-photo, replay and silicone-mask attacks. Evaluate low-light performance from the proposed 10 lux level, backlight compensation and supplementary lighting. All targets require an agreed evaluation method, selected hardware and representative tests.
Security and deployment requirements
For China deployments, review the Personal Information Protection Law, Data Security Law, Cybersecurity Law, relevant standards and the facial-recognition application safety rules effective from 1 June 2025. Assess privacy impacts and any applicable filing obligations. Confirm the current requirements for the project and jurisdiction.
Provide prominent notices and appropriate separate consent, including guardian arrangements where required for minors. Offer non-face alternatives such as cards, passwords or QR codes instead of forcing facial recognition as the sole route.
Classify data, encrypt storage and transmission, minimise retained original images and automate deletion. The source gives 30 days as an example for project review, not a universal retention rule.
Apply least privilege, dual approval for exports, end-to-end audit records, abnormal-access alerts and periodic security assessment.
Do not use the system for unlawful surveillance, discriminatory treatment or unauthorised tracking. Public-area use requires an appropriate legal basis and necessity assessment.
Implementation
Assess the use case, necessity and alternatives. Design locations, camera angles, lighting and backgrounds; select devices, liveness capabilities and offline requirements. Clean and deduplicate any authorised legacy database. Run a limited pilot, tune accuracy and user experience, then load-test and roll out. Acceptance should cover matching, latency, spoof resistance, offline operation and auditing. Agree database maintenance, complaints and deletion-response procedures.
Intended benefits
The goals are smoother access, less identity misuse or proxy check-in, and faster security response while maintaining privacy and alternative access routes.
