Privacy in Airport Biometrics: Verifying Passengers Without Storing Facial Data

Facial recognition at the airport is fast; however, the permanent sharing of the same biometric data across check-in, security, lounge, border control, and boarding systems could lead to passengers being tracked by different organizations. A professional architecture asks, “Is facial data really necessary at this point?” before asking, “Where do we store facial data?”

1:1 Verification and 1:N Identification

In 1:1 verification, the passenger presents a journey reference or credential; the system compares the face only against that identity reference. In 1:N identification, however, the camera image is searched against a large database of passenger images. Although the second method may seem less cumbersome, it increases the risk of false matches, mass surveillance, and data breaches.

Wherever possible, 1:1 verification using a short-lived passenger reference should be preferred at checkpoints. If 1:N is used, the purpose, duration, gallery scope, and deletion policy must be clearly defined.

Journey pseudonym approach

Instead of a passport number or permanent customer number, a random “journey pseudonym” can be generated for each trip. Checkpoints establish the necessary link within the same trip; no direct tracking key is created across different trips.

import secrets
from dataclasses import dataclass
from datetime import datetime, timedelta, timezone

@dataclass
class JourneyIdentity:
    journey_ref: str
    biometric_binding_ref: str
    expires_at: datetime

def create_journey_identity(binding_service):
    return JourneyIdentity(
        journey_ref="jrny_" + secrets.token_urlsafe(24),
        biometric_binding_ref=binding_service.create_one_time_reference(),
        expires_at=datetime.now(timezone.utc) + timedelta(hours=18),
    )

The journey reference alone should not be convertible to a passport number, first and last name, or a permanent biometric template. If such a match is required, it must be maintained in a separate, higher-security authority domain.

Data Minimization

In most cases, the boarding gate does not need to see the passenger’s date of birth or passport number. All the gate needs is the result: “Is this living person the person authorized for this flight?”

{
  "journeyRef": "jrny_r4nd0m...",
  "flight": "YY217",
  "touchpoint": "BOARDING_GATE_B12",
  "identityAssurance": "HIGH",
  "biometricBinding": "VERIFIED",
  "boardingAllowed": true,
  "expiresAt": "2026-07-13T18:30:00Z"
}

Biometric Data Lifecycle

1. Capture: The purpose, quality criteria, and user notification are defined.
2. Binding: The live image is matched 1:1 with a trusted identity reference.
3. Use: Used only for authorized touchpoints and the active journey.
4. Retention: Separate retention periods are applied for the raw image and the template.
5. Deletion: Automatic deletion or anonymization occurs upon completion of the journey.
6. Audit: The processing result and policy version are recorded instead of the raw biometric data.

RETENTION = {
    "raw_capture": "minutes",
    "protected_template": "journey_lifetime",
    "decision_log": "policy_defined",
    "security_incident_evidence": "legal_hold_only"
}

def on_journey_closed(journey_ref, stores):
    stores.raw_images.delete_by_journey(journey_ref)
    stores.biometric_templates.revoke_and_delete(journey_ref)
    stores.logs.detach_direct_identifiers(journey_ref)

Template Protection

A facial template is not a password; if it is compromised, the traveler’s face cannot be altered. Therefore, template encryption, hardware-supported key protection, segregated storage, and—where possible—a cancellable template approach are required. Different airports should not share the same persistent template.

Selective disclosure

When presenting a digital identity, only the necessary claim should be shared instead of the entire passport record. For example, an airline may receive the result “authorization required for arrival has been verified”; it is not required to obtain all personal fields from the supporting document. The IATA One ID approach emphasizes passenger verification, informed sharing, and an interoperable trust framework.

Consent and Alternative Channels

Passengers must be clearly informed about the biometric process, told which parties will process the data, and offered a manual alternative where feasible. When consent is made a condition of a mandatory service, it may not constitute a valid legal basis in every jurisdiction; the system design must be evaluated in light of local data protection laws.

How should audit logs be maintained?

{
  "event": "BIOMETRIC_VERIFICATION",
  "journeyRef": "rotating-pseudonym",
  "touchpoint": "TRANSFER_SECURITY",
  "modelVersion": "face-4.2",
  "policyVersion": "airport-policy-18",
  "result": "PASS",
  "reasonCodes": [],
  "rawImageStored": false
}

The log must include the model and policy versions; however, it should not contain unnecessary raw facial images, complete passport data, or reversible templates.

Conclusion

Privacy-protected airport biometrics employs travel-based pseudonyms, short-lived biometric bindings, selective data sharing, and automatic deletion, rather than creating a centralized, indefinite facial gallery. The goal is not merely to store less data, but to ensure that the checkpoint cannot technically access data it does not need.

References

• IATA One ID
• IATA Digital Identity and Biometrics Library
• IATA — Digital Identity and Biometrics