Part 4 of 6 · Biometric Identity Programme Series — next: Managing a Fleet of Identity Terminals

Biometric Data Protection: Consent and Retention

By Xinhong Smart Engineering Team · Published 31 October 2026

Quick answer: Treat the terminal as a capture device, not a database: capture, check quality, encrypt, queue, upload, delete. Biometric data processed to uniquely identify a person is special-category data under Article 9 GDPR, so the lawful basis has to be settled before the first enrolment and a non-biometric alternative has to exist where consent is the basis. Retention, deletion and withdrawal are enforced on the backend, so the device specification should make them possible rather than store templates locally.

Data protection decides where the record lives and how long it stays. Those two choices should be made before the device is specified, because they constrain what the device is allowed to do.

What the main regimes require

Under Article 9 GDPR, processing biometric data for the purpose of uniquely identifying a natural person is prohibited unless an exception applies, of which explicit consent is the usual one in practice. Consent is only freely given when refusing carries no detriment, which in practice means a genuine non-biometric alternative has to exist and be usable. Withdrawal has to be as easy as giving consent, including deletion of the enrolled template.

India's Digital Personal Data Protection Act, 2023 takes a different shape: it does not create a separate sensitive-data category in the way earlier rules did, but its consent and notice obligations apply to personal data including biometric identifiers. In the European Union, Regulation (EU) 2024/1183 amending eIDAS was published on 30 April 2024 and entered into force on 20 May 2024, and requires Member States to provide European Digital Identity Wallets to citizens within 24 months of the adoption of the implementing acts that set the technical specifications.

The practical consequence for a hardware programme: the lawful basis, the notice language and the retention period are inputs to the device specification, not paperwork to be completed afterwards.

Device-side rules that follow from it

The terminal should hold a record for as short a time as physically possible. Capture, run the quality check, encrypt, queue, upload, delete on confirmation. A template store on a field device is an unnecessary concentration of risk, and a biometric template is treated as personal data in most regimes even when it cannot be reversed into an image.

Encryption at rest on the device, key handling that does not put a shared key in every unit, and a deletion path that a supervisor can trigger on a lost device are the three specifications that matter. If the programme spans borders, ask where the backend sits before the order, because transfer rules are decided there.

Consent at the counter

Consent has to be captured in language the person reads, with the purpose stated, and it has to be recorded. A signature or a checkbox on the terminal screen is the usual mechanism, and the record should travel with the enrolment rather than being stored only on the device. Where an alternative exists, the workflow has to offer it, not merely mention it.

Retention and deletion are backend decisions with device consequences

How long a record is kept, what happens when a person withdraws, and how deletion is proved are backend questions. But they only work if the device hands over a clean, identified, encrypted record and does not keep a copy. Specify the deletion behaviour explicitly, including what a wipe does to the queue of unsent records, and test it during acceptance.

What Xinhong ships

We build the device to the data flow you specify: capture, encrypt, queue, upload, delete, with no local template store unless a programme requires offline matching and accepts the risk it carries. We will state in writing what a unit stores and for how long, and we will not describe a build as compliant with a regime it has not been assessed against.

Frequently asked questions

Is a biometric template still personal data if it cannot be reversed into an image?

Yes, in most regimes. The template is derived from the person and can be used to recognise them, which is what the rules are written around. Designing on the assumption that an irreversible template is not personal data is the single most common mistake in this area.

Can we store templates on the terminal for offline matching?

Only if the programme accepts the risk and has a lawful basis for it. Offline matching at a remote enrolment point is a real requirement, and it is achievable, but the device then holds a concentration of personal data that needs encryption, access control and a remote wipe. Most supervised programmes do not need it.

Does consent have to be re-taken for a new purpose?

Yes. Consent is granular: agreeing to enrolment for an identity credential is not agreement to any later use of the same biometrics. If the programme intends to reuse the record for a second service, that purpose has to be in the notice and in the consent.

What should the retention period be?

Whatever the programme can justify and defend. It is not a technical question; it follows from the purpose. What matters for the device specification is that a retention period exists, that deletion is technically possible, and that the deletion actually removes queued records on the device as well as on the backend.

Do these rules apply outside Europe and India?

The specific instruments differ, but the pattern is now common: biometric data used for identification attracts stricter treatment, consent and notice are required, and retention has to be bounded. Confirm the local position with counsel in the country of deployment before the enrolment drive starts.