Biometric Template Protection Guide

A stolen password can be changed, but a stolen fingerprint or face template is tied to a person for life, so where and how you store biometric templates decides whether a breach is an incident or a permanent harm. This guide covers the storage side of biometrics: what a template is, the four main storage models from on-device matching to central databases, the protection properties set out in ISO/IEC 24745, cancellable and encrypted templates, match-on-card, and the retention and destruction duties that laws such as the Illinois Biometric Information Privacy Act attach to template stores. It is written for security architects, identity engineers and privacy leads who are choosing or reviewing a biometric system. For modalities, accuracy and attacks in general, start with the Biometrics Guide; this page goes deeper on the data you keep afterwards.

Source note: legal and standards requirements below are summarised from 740 ILCS 14/15, EDPB Opinion 11/2024, NIST SP 800-63B-4, NIST SP 800-76-2 and the ISO/IEC 24745 catalogue page as checked in November 2026. This is not legal advice. Confirm against the official text before relying on it.

Key takeaways

Location is the biggest decision. A template that stays in a phone's secure hardware or on a smart card cannot be stolen in bulk; a central template database is a high-value target and the European Data Protection Board found two centralised airport designs incompatible with data protection by design.
Encryption alone is not template protection. ISO/IEC 24745 asks for confidentiality, integrity and renewability or revocability, which means you must be able to cancel a compromised reference and issue a new one without re-using the same characteristic.
Keep keys apart from templates. If the service that stores templates also holds the decryption keys, a single compromise exposes everything; split them, or let the user hold the key.
Delete on a schedule you can prove. BIPA section 15(a) requires a public retention schedule and destruction when the purpose is satisfied or within 3 years of the last interaction, whichever comes first; build the purge job before go-live.
Treat raw images as the worst case. Enrolment photos and fingerprint images are more reusable than templates; erase samples after processing and never store them beside the template without a documented need.

What a biometric template is and why it needs its own controls

A biometric system captures a sample (a face image, a fingerprint scan), extracts features, and stores the result as a reference template. At each later authentication it extracts features from a fresh sample and compares them with the reference, producing a score that is accepted if it passes a threshold. The template is smaller than the image and is often described as a mathematical representation, but it is still biometric data: it was derived from one person's body and is used to recognise them.

Three properties make templates different from other credentials:

Not secret: faces are visible and fingerprints are left on surfaces. NIST SP 800-63B-4 says biometric characteristics are not secrets, which is why it allows biometrics only as part of multi-factor authentication with a physical authenticator.
Not replaceable: a person has one face and ten fingers. If a template in a reusable format leaks, the characteristic behind it is burned for every system that uses the same algorithm.
Linkable: two databases holding templates from the same algorithm can be cross-matched to link a person across services, a privacy harm even without a breach.

NIST SP 800-63B-4 section 3.2.3 requires biometric data to be treated and secured as sensitive personal information, and requires a non-biometric alternative to be offered; elsewhere the guideline states a preference for local verification over central comparison. Its activation-factor rules for multi-factor authenticators require the biometric sample and derived data to be erased after the authentication operation. Those three ideas, sensitivity, local comparison and erasure, are the foundation for everything below.

Storage models compared

Most deployments fall into one of four models. The EDPB used a similar split in Opinion 11/2024 on facial recognition at airports, which is the clearest regulator analysis of the trade-offs.

Model	Where the template lives	Who holds the key	Bulk breach exposure	Typical use
On-device, secure hardware	Phone or laptop secure element, Secure Enclave or TEE	Device-specific key never exported	Very low: one device at a time	Platform unlock, passkeys, Windows Hello, banking apps using platform biometrics
Match-on-card or token	Smart card or security key chip	Card	Very low	PIV on-card comparison, biometric security keys, some physical access cards
Central, user-held key	Server database, encrypted per user	The user (on a device or QR code); server adds a second layer	Low if keys never reach the server	Airport and venue enrolment where 1:1 is enough
Central, operator-held key	Server or cloud database	Operator or its processor	High: one compromise can expose every template	1:N identification, walk-through access, time and attendance terminals

The EDPB concluded that storage only on the passenger's device, and central storage encrypted with a key that only the passenger holds, could in principle be compatible with GDPR Articles 5(1)(f), 25 and 32 with appropriate safeguards. It found that central storage under the airport operator's control, and cloud storage under an airline or its processor, could not be compatible with Article 25 (data protection by design and by default), because a central database creates a high-value target and a less intrusive design achieves the same result. That reasoning applies well beyond airports: if 1:1 verification meets the need, do not build a 1:N database.

On-device platform storage

Platform vendors document how their secure hardware holds templates. Apple's Platform Security Guide states that the Secure Enclave processes, encrypts and stores enrolled Face ID template data, and that the Touch ID template is stored in a format only the Secure Enclave can read, never leaves the device, is not sent to Apple and is not included in device backups. The Android biometric documentation requires that raw biometric data and derived templates are never accessible from outside the secure isolated environment (a TEE or secure element), that stored data is encrypted with a device-specific key known only to the TEE, that templates are signed with a device-specific key and bound to their file-system path, group and biometric ID so they cannot be replayed on another device or by another user, and that a user's template data is erased when that user is removed. Android grades biometrics as Class 3 (formerly Strong), Class 2 (formerly Weak) and Class 1 (formerly Convenience); only Class 3 can unlock Android Keystore keys, so apps that release a cryptographic key on biometric success should require Class 3. See the Windows Hello for Business Guide and the Passwordless and Passkeys Guide for how local biometrics unlock a device-bound key.

The design pattern is the same everywhere: the relying party never receives the biometric. It receives a signature from a key that the biometric unlocked locally. That removes the server-side template store entirely.

Match-on-card

NIST SP 800-76-2, the PIV biometric specification, added on-card comparison (OCC) as an alternative to PIN-mediated card activation and as an additional authentication method. The reference template is written to the card at issuance, the live sample is compared inside the card, and the template need not be read out. Organisations that issue cards should still check whether the issuing system keeps a copy of enrolment data, because the card is only as private as the enrolment back office. See the Smart Card and PIV/CAC Authentication Guide.

Protection properties: what ISO/IEC 24745 asks for

ISO/IEC 24745:2022 (Information security, cybersecurity and privacy protection: Biometric information protection) covers the protection of biometric information under requirements for confidentiality, integrity and renewability or revocability, and gives requirements and recommendations for secure and privacy-compliant management of biometric information. In practice those properties translate into concrete design questions.

Property	What it means for a template store	Controls that deliver it
Confidentiality	Templates and samples cannot be read by unauthorised parties at rest, in transit or in memory	Secure hardware storage, per-record encryption, keys in an HSM or held by the user, TLS for capture devices, erasure of samples after use
Integrity	A reference cannot be swapped or altered to let an attacker enrol their own face against a victim's account	Signed templates bound to the subject and device, write access limited to the enrolment service, audit of every enrolment change
Renewability and revocability	A compromised reference can be cancelled and a new, different one issued from the same characteristic	Cancellable transforms keyed per application, re-enrolment workflow, revocation list for identifiers
Unlinkability (privacy goal)	Templates from two applications cannot be matched to each other	Different transform keys or parameters per application, no shared template format across services
Irreversibility (privacy goal)	The original sample cannot be reconstructed from the stored reference	One-way transforms, no storage of raw images, vendor evidence on reconstruction resistance

Template protection techniques

Cancellable biometrics: the feature set is passed through a keyed, non-invertible transform before storage and comparison happens in the transformed space. A new key produces a new, unrelated template, which gives renewability and unlinkability across applications.
Biometric cryptosystems: helper data is stored instead of the template, and a key is released only when a close-enough sample is presented. They avoid storing a matchable template but can cost accuracy.
Encrypted-domain matching: comparison runs on encrypted templates, for example with homomorphic encryption, so the matcher never sees plaintext. It reduces server exposure at a performance cost.
Plain encryption at rest: necessary but not sufficient. It protects against stolen disks and backups, not against an attacker with access to the running matcher, which must decrypt to compare.

Ask vendors which technique they use, whether it has been evaluated against ISO/IEC 24745, what accuracy change it introduces, and whether templates are interoperable with other products. Interoperable templates are convenient and also linkable.

Choosing a design

Choose on-device or match-on-card when the goal is authentication of a known user who carries a phone, laptop, card or key. This covers most workforce and consumer login. There is no server template store to protect.
Choose central with a user-held key when users do not carry capable hardware but you still only need 1:1 verification, such as a venue or travel enrolment. The server stores ciphertext and an unrelated index; the user presents the key at the point of use.
Accept central with an operator-held key only when 1:N identification is a genuine, documented requirement. Then apply the strongest template protection available, keep keys in an HSM outside the template database's trust boundary, set short retention, and run a DPIA. See the DPIA Guide: Running a Data Protection Impact Assessment.
Small organisations: prefer platform biometrics on managed devices over buying a terminal that keeps its own fingerprint database. A time and attendance clock with an embedded template store is a central database, however small.
Large organisations and identity providers: assume your store will be targeted. Segment the matcher, use cancellable templates keyed per tenant, and test re-enrolment at scale before you need it.

Retention, destruction and legal duties

The template store is where biometric privacy law bites. The Biometric Privacy Laws Map covers the jurisdictions; the storage-relevant points are these.

Source	Storage obligation	Engineering consequence
Illinois BIPA s15(a)	Public written retention schedule; destroy when the initial purpose is satisfied or within 3 years of the last interaction, whichever occurs first	Last-interaction timestamp per subject, automated purge, deletion evidence
Illinois BIPA s15(b) to (d)	Written notice and release before collection; no selling or profiting; no disclosure except listed exceptions	Consent record linked to the template; no export to vendors without a basis
Illinois BIPA s15(e)	Store, transmit and protect biometric data with the reasonable standard of care in the industry, at least as protective as other confidential information	Template store in the highest data classification tier, with matching controls
GDPR Art 9 and EDPB Opinion 11/2024	Biometric data for unique identification is special category data; data protection by design (Art 25) and security (Art 32) favour user-controlled storage; enforce retention through automatic routines	DPIA, user-held keys where possible, deletion from memory, caches and backups
NIST SP 800-63B-4 s3.2.3	Treat biometric data as sensitive PII; erase samples and derived data after the authentication operation	No sample logging; scrub debug and crash dumps

Backups are the usual gap. The EDPB recommends deleting biometric data at the checkpoint promptly, including from memory, caches and backups. If your backup retention is longer than your template retention, your schedule is not being met. See the Illinois BIPA and Biometric Privacy Guide and the Data Retention and Secure Deletion Guide.

How to implement

Inventory every template store. Include identity platforms, door controllers, time clocks, visitor kiosks, contact-centre voice systems, test environments and vendor-hosted services. Record modality, count, location, key holder and retention.
Challenge the need for central storage. For each store, document why on-device or match-on-card would not work. Retire stores that only exist for convenience.
Classify and isolate. Put remaining template databases in a dedicated segment with no direct user access, admin access through privileged access management, and keys held in an HSM or key service outside the database's administrative domain.
Apply template protection. Require cancellable or encrypted-domain templates from vendors where central storage remains; set distinct transform keys per application and per tenant.
Remove raw samples. Confirm enrolment images are discarded after feature extraction unless a documented requirement exists, and check logs, debug captures and crash dumps for samples.
Build retention and deletion. Store a last-interaction date per subject, run an automated purge, propagate deletion to replicas and backups (or crypto-shred per-user keys), and keep deletion evidence.
Test revocation. In a pilot, simulate a template store compromise: rotate transform keys, invalidate references, and re-enrol a test group. Measure how long full re-enrolment would take.
Roll back safely. Keep the non-biometric alternative that NIST SP 800-63B-4 requires working at all times, so you can switch biometrics off for a population without locking people out.

Detection and measurement

Log access to the store: every read of more than one template, every bulk export, every new service account with template access, and every enrolment or re-enrolment.
Alert on volume: reads outside the matcher's normal pattern, queries from hosts other than the matcher, and enrolment changes without a matching identity proofing event.
Watch key use: HSM or key service logs for decryption volumes that exceed authentication volumes.

Metrics that show the programme is working:

Percentage of biometric authentications performed on-device or on-card rather than against a central store.
Number of central template stores, and the count of templates in each, trending down.
Percentage of subjects past their retention date whose templates have been destroyed (target 100 percent).
Time to revoke and re-enrol a test population after a simulated compromise.
Number of systems found holding raw biometric samples outside the enrolment process.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	IA-5(12) Biometric Authentication Performance	Biometric mechanisms meet defined quality requirements
NIST SP 800-53 Rev. 5	SC-28, SC-28(1) Protection of Information at Rest; SC-12 Cryptographic Key Establishment and Management	Encrypted template stores and separated keys
NIST SP 800-53 Rev. 5	SI-12 Information Management and Retention; PT-3 Personally Identifiable Information Processing Purposes; RA-8 Privacy Impact Assessments	Retention schedules, purpose limitation, impact assessment
NIST CSF 2.0	PR.DS-01, PR.DS-02, PR.AA-03, GV.OC-03	Data at rest and in transit, authentication, legal and privacy obligations
ISO/IEC 27001:2022 Annex A	5.34 Privacy and protection of PII; 8.10 Information deletion; 8.24 Use of cryptography	Template privacy, deletion and encryption
ISO/IEC 24745:2022	Confidentiality, integrity, renewability and revocability	Template protection design

Common failure patterns

Central store by default: buying a system that keeps a cloud template database for a use case where users already carry a phone or badge capable of local matching.
Keys beside templates: template encryption keys stored in the same database or on the same application server, so a single compromise yields plaintext.
Images kept "for re-enrolment": enrolment photos or fingerprint images retained indefinitely so the vendor can upgrade algorithms, turning a template store into a raw biometric archive.
Retention that ignores backups: a purge job that deletes live records while backups and replicas keep templates for years.
No revocation path: templates in an interoperable, unkeyed format, so a leak cannot be fixed by re-enrolment and the same data matches other systems.
Forgotten edge devices: door readers, time clocks and kiosks that hold local template databases outside the identity team's inventory.

Practitioner checklist

Maintain an inventory of every biometric template store with modality, count, location, key holder and retention.
Prefer on-device or match-on-card comparison; document the requirement for every central store.
Hold template keys outside the template database's administrative domain, or with the user.
Require cancellable or encrypted-domain templates with per-application keys where central storage remains.
Discard raw samples after feature extraction and scrub them from logs and dumps.
Publish a retention schedule and run an automated purge that reaches replicas and backups.
Keep consent and notice records linked to each template where law requires them.
Test revocation and re-enrolment at least yearly, with the non-biometric alternative always available.
Alert on bulk template reads, exports and enrolment changes.

Biometric Template Protection: Keep a Breach From Being Permanent