What Hotel IT Directors Need to Know About Native Mobile Wallet Room Keys
If you’ve evaluated mobile keys before, you’re familiar with the BLE (Bluetooth Low Energy) model: the guest downloads the hotel’s app, the app receives a digital credential, and the phone communicates with the lock via Bluetooth to open the door.
Native mobile wallet room keys work differently. The key lives in the guest’s native mobile wallet — the same wallet used for boarding passes and payment cards — not in a hotel-specific app. The provisioning mechanism is NFC, not Bluetooth. And the key is a wallet pass, not a proprietary credential.
These architectural differences have practical implications for hotel IT.
How wallet keys are provisioned
The wallet key provisioning flow is NFC-based and occurs at the check-in interaction point — the KeyShare Puck:
- Guest taps their phone on the Puck.
- The Puck establishes an NFC session (under 500ms including the cryptographic key exchange).
- The Guest Experience Platform (GEP) matches the guest’s verified identity to their reservation.
- A wallet key is generated and transmitted to the guest’s phone through the NFC session.
- The key appears in the guest’s native mobile wallet.
The entire interaction takes seconds. The guest doesn’t download anything, create an account, or navigate an app — solving the adoption barrier that held back BLE-based mobile keys. The NFC session is the same kind of interaction they use when paying for coffee — familiar and fast.
What this means for your lock infrastructure
Wallet keys interact with locks differently than BLE mobile keys. With BLE, the phone communicates directly with the lock at the door. With wallet-native keys, the key is a credential stored in the wallet — the lock reads it via NFC when the guest taps their phone on the lock.
The implication: your locks must support NFC reader mode — not just BLE mobile key mode. Most modern electronic hotel locks from major vendors support this (Assa Abloy Vostio and SALTO are integrated today; dormakaba and Onity support is in progress or planned), but older BLE-only locks may need firmware updates or reader hardware additions.
The GEP platform handles lock vendor integration on the backend. It translates between the wallet key credential and each lock vendor’s platform API. The IT team doesn’t manage lock vendor protocols — that’s orchestrated by the GEP.
Security architecture
Wallet keys inherit the security properties of the native mobile wallet platform. The key is stored in the phone’s secure element or Trusted Execution Environment (TEE). It’s protected by the phone’s biometric authentication (face, fingerprint, or PIN). It cannot be extracted, copied, or shared to another device.
This is a stronger security posture than physical keycards, which can be cloned, and many BLE mobile keys, which depend on the security of the hotel’s proprietary app rather than the phone’s hardware security module.
What about guests without NFC phones?
Not every phone has NFC capability, and not every guest will be comfortable with a wallet key. The Puck supports a dual-interface fallback: NFC for wallet key provisioning, and QR code for guests who can’t or don’t want to use NFC. The QR path leads to a web-based key delivery flow — no app download required, but a slightly longer interaction than the tap.
Physical keycards remain available as a fallback for any guest who prefers them. The wallet-native approach is the default, not the only option.
PMS integration impact
From the PMS perspective, a wallet key check-in looks identical to a keycard check-in. The GEP communicates with the PMS through the adapter layer — the same reservation lookup, check-in status update, and room assignment flow. The PMS doesn’t need to know whether the key was delivered as a wallet pass, a keycard, or via a brand app.
For IT directors concerned about PMS integration complexity: if your PMS is already on the supported adapter list (Opera, Mews, Apaleo, BookingCenter, Shiji, Cloudbeds), the integration is configuration — not custom development.
