Most identity verification flows end the same way. The user scans a document, takes a selfie, passes the check, and the images go into storage. Sometimes the vendor keeps them, sometimes the platform does, often both. Nobody decided that this was the goal. It is simply what the pipeline does by default.
That default creates a database of faces linked to real identities. For an attacker, it is one of the most valuable things a company can hold. For the company, it is a risk that grows with every user it verifies.
What a honeypot is, and why face data qualifies
In security, a honeypot is a target that attracts attackers. A store of face images, document scans and biometric templates fits the description without anyone intending it. It concentrates data that is hard to obtain elsewhere and directly useful for identity fraud.
A leaked password database lets attackers into accounts until users change their passwords. A leaked identity database gives them a person: the face, the document, the name and the number, already matched. That bundle is what fraudsters need to open accounts in someone else's name, to build synthetic identities, or to rehearse attacks against other verification systems.
You cannot rotate a face
The standard response to a credential breach is rotation. Reset the passwords, revoke the keys, reissue the cards. The damage has a ceiling because the secret can be replaced.
Biometrics do not work that way. A person has one face. Once a high-quality image or a template derived from it is out, it stays out for the rest of that person's life. No support ticket fixes it. The breach does not end when the incident is closed; it moves from your systems into the general supply of material available to fraudsters.
Templates are sometimes presented as safer than images because they are not pictures. That is a weaker argument than it sounds. A template is still derived from a unique physical trait, it is still linked to an identity record, and its usefulness to an attacker depends on details the data holder does not control.
The regulatory exposure
Regulators tend to treat biometric data as a special case. Under the EU General Data Protection Regulation, biometric data processed to uniquely identify a person falls within the special categories of Article 9, which are prohibited by default and allowed only under specific conditions. Article 5 adds the principles of data minimisation and storage limitation, and Article 25 asks for data protection by design and by default.
Israel has moved in a similar direction. Amendment 13 to the Privacy Protection Law, in force since 2025, strengthened the regulator's enforcement powers and gives particular weight to sensitive categories of information, which include biometric data. Other jurisdictions have their own biometric rules, some with private rights of action.
The details differ by jurisdiction and by use case, and none of this is legal advice. Consult counsel about your own obligations. The direction, though, is consistent: the more biometric data you hold and the longer you hold it, the more you have to justify, secure, document and eventually explain after an incident.
The real cost of being a honeypot
The cost of retained face data does not appear as a line item, which is why it is easy to underestimate. It shows up in several places at once:
- Security: the store has to be protected to a standard that matches its value to an attacker, including access controls, encryption, monitoring and key management.
- Compliance: retention schedules, lawful basis, impact assessments, subject access requests and deletion requests all apply to every image you keep.
- Vendor risk: if your verification provider keeps the images, their breach becomes your breach notice, and your security officer has to assess their storage as well as yours.
- Incident impact: notification, investigation and remediation after a biometric breach are harder because the core remedy, replacing the secret, is not available.
- Trust: users increasingly ask what happens to their face after a check. A vague answer costs conversions.
None of these costs buys better verification. The check has already happened. Retention after the decision adds risk without adding assurance.
Why images get kept anyway
There are honest reasons. Some regulated sectors must keep evidence of a check for a defined period. Some teams want images for manual review or dispute handling. Some vendors use them to improve their models.
Each of these is a decision worth making explicitly, not inheriting. If your platform is not under a retention obligation, the question to ask is simple: what does keeping this image let us do that we could not do with the verification result alone? Often the answer is very little.
The alternative: verify, then delete
The safer architecture separates the decision from the evidence. The system uses the images to reach a decision, records the decision, and then deletes the images and the biometric data. What the platform keeps is the outcome, not the material.
For this to work, the verification has to be strong at the moment it happens, because there is no archive to revisit later. That favours checks whose strength comes from provenance rather than from how good a picture looks: a cryptographic signature on a document chip, or a capture that can be proven to come from a genuine device.
A practical checklist for product and compliance teams:
- List every place a face image or template is stored after a check, including your vendor's systems and logs.
- For each one, write down the specific reason it is kept and for how long.
- Ask your vendor whether images and biometrics can be deleted after the decision, and how that is verified.
- Decide what your product actually needs downstream: usually a yes or no, an assurance level and a stable way to recognise a returning user.
- Make deletion a property of the architecture, not a setting someone can change later.
How JERIX approaches it
JERIX is built around verify, then delete. For passports, it reads the NFC chip and verifies its signature to the issuing state's root certificate, offline. The face stored on the chip is matched against a live selfie.
After the check, the images and biometrics are deleted. JERIX retains no face images, no face templates, no document images and no chip data. The platform receives a verification result and a one-way token that recognises the same person again, and each client receives a different token for the same person, so two platforms cannot cross-reference their users.
If you are reviewing what your current verification flow leaves behind, we are happy to walk through the architecture with your security team.