Face tokenization

Face tokenization replaces the stored face with a protected token. The reason to take the trouble is straightforward: a face is a credential that cannot be reissued. When a password database leaks, everyone rotates and the incident closes. When a face gallery leaks, nobody can rotate anything, and the exposure lasts for the rest of each person's life.

Regulators reached the same conclusion by another route. In most privacy regimes biometric data attracts its own consent, retention, deletion and notification duties, with penalties scaled to how permanent the data is. Tokenization therefore answers a legal problem and a security problem in one move.

There is a third reason that only appears later, during a migration. A stored template is a proprietary format, so the biometric estate becomes the hardest part of ever changing providers. A design that stores no template has nothing to export and nothing to convert.

The word token is applied loosely. Hashing a template does not earn it, and neither does encrypting an image. The properties below come out of the template protection literature, and a design missing any one of them has generally repackaged the original risk rather than removed it.

Put the three to a vendor individually and ask how each one is achieved. Those answers can be checked. The adjective protected cannot.

Encryption is reversible by design. Data goes behind a key, and possession of that key returns the original. Where the data genuinely has to be read again later, that is the right tool, and what it does with the risk is move it onto key custody rather than retire it. Every encrypted biometric store is one key compromise away from being a plaintext biometric store.

A one-way tokenization design has no reversal key. That description must not be extended to every sealed construction or to the authorized processing paths of a licensed deployment. For a one-way design, the intended result is that the original image cannot be recovered from the token. For a face, that protection is the goal.

The distinction changes what a subpoena, a rogue administrator or a full database exfiltration can produce. It is worth being precise about, because these two words are used interchangeably in a great deal of vendor material where the underlying designs are not interchangeable at all.

Face tokenization and Face PKI are patent-pending. Each face verification consumes a disposable token. Enrollment creates a quantum-safe, sealed, biometric-free token; neither the face image nor the template is retained. Phone verification runs on the enrolled handset; licensed on-premises Webcam processes captures inside the customer deployment. A tamper-evident context value binds the token to its tenant.

The construction uses NIST 140-3 approved symmetric and hash primitives exclusively: AES-256-GCM, HKDF-SHA256, SHA-256. No proprietary or non-approved cryptographic primitives are used anywhere. Because there is no public-key mathematics inside the envelope, the sealed material is not exposed to the harvest-now-decrypt-later problem that motivated NIST FIPS 203, 204 and 205 and the migration timelines in US NSM-10. That is the specific and narrow reason the result is described as a quantum-safe face token.

In transit, the platform negotiates hybrid post-quantum TLS (X25519MLKEM768), where negotiated, to help protect recorded traffic; this does not make the full IdP stack post-quantum. Signing key material is sealed at rest under a key-encryption key held outside the database, so the signing keys in a database dump remain sealed without that separate key, and tenants that need a stronger custody model can use non-exportable keys in a managed key service, where the key cannot be copied out by anyone, including us. Offboarding or a right-to-erasure request is answered by crypto-shredding that key material, which makes what it sealed permanently unrecoverable.

IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow. Licensed on-premises Webcam processes captures inside the customer deployment.

This is what biometric-blind means in practice. The platform runs a face-based authentication service while retaining sealed, biometric-free, disposable face tokens and account records. A breach must be assessed against those records, key custody and the authorized processing paths of the deployment.