Verified identity moves from booking to check-in through a bound record that links the traveller’s wallet credential, booking reference, and check-in session. The receiving system should re-verify freshness, match key attributes, and enforce step-up checks when the data has expired, changed, or been revoked. A one-time token or signed assertion is usually safer than copying raw identity data.
How the booking record becomes the check-in proof point
The handoff works when the booking is treated as the anchor record, not as the proof of who is standing at the desk or on the app. The check-in system needs a durable link between the original booking reference, the traveller’s presented wallet credential, and the live session so it can recognise the same person or device again without retyping identity data.
That link is usually built from a signed assertion or a one-time token tied to the booking context. The important design point is that the receiving system should trust the binding, then re-check freshness and match the specific attributes it actually needs, rather than copying the full identity payload into every downstream system.
What has to be re-verified at check-in
Check-in is the point where previously verified identity becomes operational. The system should confirm that the credential is still valid, that the booking data has not changed in a way that affects eligibility, and that the claim presented now still matches the traveller and trip context captured at booking.
This is where step-up checks matter. If the credential is stale, revoked, or presented from a context that no longer matches the booking, the safest response is to require a fresh verification step instead of assuming the earlier booking proof still holds. That is especially important when the check-in flow can unlock boarding, bag drop, premium access, or reissue of travel documents.
Why bound assertions are safer than copying identity data
Keeping the handoff tokenised or signed reduces unnecessary exposure of personal data and makes it easier to limit replay. It also narrows the trust boundary: the check-in service validates a proof of identity relationship, rather than inheriting a replicated identity record that may drift, be cached too long, or be reused outside its original purpose.
For airport and travel environments, this pattern lines up with the operational reality covered in NHIMG’s Airport Cybersecurity Guide, where common use passenger processing and manual fallback need to survive outages without weakening verification. It also reflects the need to handle identity verification at service boundaries, which is why the Help Desk Identity Verification Policy Template is useful as a model for attribute checks, escalation, and stronger checks when a request is exceptional.
Risk and Threat Considerations
The main risk is that the booking-to-check-in link is treated as proof of identity long after the original verification has aged out. If a token is replayed, a booking is modified, or a credential is revoked but the downstream system does not re-check it, an attacker can ride an earlier trust decision into a later stage of the journey.
Failure mechanism: Weak binding, overlong validity, or copied identity data lets an old verification artefact be reused after the underlying identity state has changed.
Impact: The wrong person may be checked in, access may be granted on stale evidence, and the organisation may lose control over who can progress through the travel flow.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers token validity, rotation, and revocation for the booking-to-check-in proof. |
| IA-2 — Identification and Authentication (Organizational Users) | Applies where staff or agents verify travellers at check-in and must authenticate reliably. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Fits traveller-facing check-in where external users present an identity proof. | |
| Recommendation — Set short lifetimes and revocation checks for check-in assertions. Require strong authentication for staff who approve exceptional check-ins. Use verified traveller authentication and reauthentication at check-in. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Directly informs identity proofing, binding, and step-up decisions across the booking-to-check-in journey. |
| Recommendation — Apply identity proofing and verifier guidance to the booking and check-in handoff. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Management | Supports identity verification and access decisions at the check-in boundary. |
| Recommendation — Enforce verified identity before check-in access is granted. | ||
Practitioner Guidance
What to verify: Confirm that the check-in service validates the assertion against the live booking, not just against a cached passenger profile. The validation should include expiry, revocation status, and a match on the minimum set of attributes needed for that specific journey.
Decision rule: If the presented proof cannot be checked back to the booking in real time, treat it as a fresh identity event and require step-up verification. If the booking changed materially, do not let a previously issued token bypass the new risk state.
What good looks like: The traveller can move from booking to check-in without re-entering full identity data, but every handoff remains bounded, time-limited, and auditable. The check-in team can explain exactly which attribute match or freshness check allowed the transaction to proceed.
Practitioner takeaway: The safest design is not continuous reuse of identity data, it is controlled re-use of a short-lived proof that can be revalidated against the current booking state.
Related resources from NHI Mgmt Group
- What is the difference between a verified identity check and relying on a live video or voice call?
- What is the difference between a one-time identity check and a portable verified rental profile?
- How should identity teams move from ticket queues to product ownership?
- When should teams move from code scanning to identity governance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org