BIPA-safe biometric architecture.

Illinois passed the Biometric Information Privacy Act in 2008. The first time most technology companies heard about it was around 2018, when the class-action settlements started landing in the seven and eight figures. Facebook paid $650 million. Six Flags paid $36 million. A facial-recognition vendor named Clearview AI is still in active litigation as of this writing.

The Act is not complicated. It says: if you collect a person's biometric — a face geometry, a fingerprint, a retinal scan — you need their written consent, you need a written retention and destruction policy, and you cannot sell, lease, or trade that biometric. It also gives a private right of action with statutory damages. That last part is what makes it lethal.

Texas, Washington, and California followed with similar regimes. Other states are drafting. The federal government is, predictably, lagging. The pattern at this point is clear: biometric data is becoming the most expensive class of data a company can hold.

The naive architecture

The naive way to build a biometric verification product is this: enroll the user, capture their face geometry, send it to your server, store it, and on every subsequent verification compare the new capture against the stored template. Most products do this. Most products are also one breach away from a class action.

If your server is breached and an attacker walks away with the biometric template database, you cannot un-breach a face. You cannot rotate a fingerprint the way you can rotate a password. The breach is permanent. The lawsuit is, accordingly, also large and permanent.

What we did instead

VisitLock's biometric architecture has a single defining property: the biometric template never leaves the device. Not in transit, not at rest, not for matching, not for any reason. This is not a marketing line. It is a hard constraint on the engineering, and everything else flows from it.

Here's how it works:

• At enrollment, the aide's face is scanned by the phone. The face geometry is converted into an encrypted template on-device, using the phone's secure enclave (iOS Secure Enclave, Android StrongBox).
• The template is wrapped in an AES-256 key that is itself protected by the secure enclave. The key cannot be exported. The template cannot be extracted from the enclave by any software running on the phone — including our own app.
• At every subsequent visit, the aide's new capture is compared against the stored template on the device. The comparison produces a match score (a number between 0 and 1). The score is signed by the device's keypair.
• Only the signed score travels to our servers. Never the template. Never the new capture.

In the event of a server breach, the attacker walks away with a database of signed match scores — useless without the corresponding device keys, and useless to identify any aide. There is no biometric on our servers to exfiltrate.

The trade-off

The honest version: this architecture is harder to build, harder to debug, and harder to scale. It also means we can't do "cross-device" enrollment without re-enrolling — if an aide loses her phone, the new phone needs to enroll fresh. We accept that. The alternative is a database that, the day it's breached, ends our company.

It also means we cannot share biometric data with our customers, even if they ask. We've had agency owners ask if they can "see the face data" for an aide who flagged. The answer is no — and we tell them that's not a limitation, that's the whole point. They cannot see it. We cannot see it. The state cannot subpoena it from us. The aide controls her own biometric.

What this means for BIPA

Under BIPA's strict reading, the question of whether VisitLock "collects" or "captures" biometric information is genuinely interesting. We argue we don't — the biometric is captured, processed, and stored entirely on the user's own device, by software the user has consented to install. We never receive the template. We never have custody of it. The aide remains the sole party in possession of her own biometric.

Whether courts agree is, at the moment, an unsettled legal question. Our customers' lawyers and ours have looked at this carefully. The conservative answer is to issue a BIPA-compliant consent flow at enrollment regardless — written notice, written consent, a written retention and destruction policy — even though our retention period is, in a meaningful sense, "the lifetime of the user's phone."

Why this matters for the agency

If you're an agency owner running biometric EVV, the question to ask any vendor is brutally simple: where does the biometric live?

If they tell you it lives on their servers — even encrypted, even compliant, even SOC 2'd — they are one breach away from naming you in a class action. (You're a co-defendant under BIPA when you're the agency that collected the consent.) If they cannot answer the question, walk away.

The biometric should live on the device. End of architecture diagram.

Kara Mendez is co-founder and CEO of VisitLock. She previously ran operations at a 200-aide PCS network in Florida.