Trust & security

Trust the design.
Not the promise.

HamsaID never retains a database of raw palm captures. Biometric-derived templates leave the sensor only after transformation and are encrypted at rest.

The security model

Privacy is not a policy layer. It is where the data is allowed to exist.

01 / Capture

Raw images die at the sensor.

Near-infrared and 3D frames are transformed locally and overwritten before the next capture.

02 / Authority

The private seed stays with the user.

The phone holds the root of authority. HamsaID does not keep a master seed that can impersonate everyone.

03 / Matching

The matching corpus is encrypted and context-bound.

The current deployment uses an attested enclave with per-context partitions. See how the layers separate.

04 / Disclosure

The venue receives an answer, not an identity trail.

Each response is scoped to one relying party, one purpose and one moment. No universal identifier follows the person around.

Trust boundaries

Four layers. Deliberately incomplete views.

Capture, user authority, biometric resolution and the relying-party answer are kept separate. The diagram distinguishes the current deployment’s controls from the distributed-custody target.

Security architecture diagram showing four separated layers: sensor, user phone, resolution core and relying party. Each layer lists what it holds and what it never receives. The current deployment uses an attested enclave, encryption at rest and per-context partitions; the target architecture adds secure multi-party computation across legally separate operators. — Current deployment: hardware isolation, encryption and per-context partitions. Target architecture: distributed custody through secure multi-party computation.

01 / Capture and transform

Sensor / terminal

HoldsRaw frames in volatile memory, and the untransformed embedding.

Never receivesYour seed, your civil identity, or any other context's transform keys.
02 / Root of authority

Your phone

HoldsThe private seed in secure storage, your consent capsules and scoped pseudonym keys.

Never receivesRaw biometric frames, the resolution corpus, or biometric transform keys.
03 / Scoped matching

Resolution core

HoldsTransformed templates in an attested enclave, encrypted at rest in per-context partitions.

Never receivesYour civil identity, card number, private seed or capsule keys.
04 / Minimum result

Relying party

HoldsAn access decision, a scoped pseudonym, a network-token reference.

Never receivesAny biometric raw or transformed, your private seed, or a global identifier.

Plain language

No terms-and-conditions fog. Just hard architectural limits.

No database of raw palm captures to sell or hand over.
No master key that could impersonate every user.
No raw biometric capture ever reaches the resolution core.
No palm data and no global ID reach a relying party.
Permissions are checked against their scope, revocation status and expiry.

Regulatory alignment

Built around minimisation, purpose and control.

HamsaID’s architecture is designed to support privacy and identity programmes operating under Europe’s demanding regulatory environment.

Data protection

GDPR

Data minimisation, explicit purpose, revocable consent and no raw biometric repository.

Digital identity

eIDAS 2.0

User-controlled authority and selective, context-bound assertions rather than broad disclosure.

Biometric systems

EU AI Act

Bounded use, auditable flows and an architecture built to avoid indiscriminate identification.

Regulatory alignment depends on the full deployment, operating context and customer configuration. This page describes architectural design goals, not legal advice or a blanket certification.

A shorter audit begins with fewer things that can go wrong.

The whole model fits on two pages: what each layer holds, what it never receives, and what happens if one party is breached. Take it to your security team before you take a meeting with ours.

Bring us your security team Open the architecture brief