Hotel Mobile Keys in Apple Wallet and Google Wallet

By the COTT.TV Hospitality Technology Research Desk | Updated 18 August 2026

A hotel mobile key can remove a small but persistent source of friction: the guest no longer has to queue for a plastic card, return to reception when it demagnetises, or search for it at the room door. The phone becomes the credential. That sounds simple, but the secure system behind it involves the lock manufacturer, a credential service, the hotel PMS, the guest journey and, in some deployments, Apple Wallet or Google Wallet.

The most important procurement lesson is this: a mobile room key is not merely a QR code, a Bluetooth button or a feature that any hotel app can create on its own. The door must have compatible hardware, and the credential must be issued and revoked through an approved access-control platform.

What is a hotel mobile key?

A mobile key is a time-limited digital credential assigned to a specific guest, stay and room. The guest presents a compatible phone or watch at the door, and the lock verifies whether the credential is valid.

The credential should reflect the same operational events that govern a physical keycard:

• 1it becomes valid only after the hotel authorises check-in;
• 2it grants access only to the assigned room and approved common areas;
• 3it changes if the guest moves to another room;
• 4it can be suspended if the device is lost or the stay is disputed;
• 5it expires or is revoked at checkout.

This lifecycle is more important than the graphic the guest sees on the phone. A polished wallet pass connected to an unreliable room-assignment process will create more front-desk work, not less.

Three common delivery models

1. The lock provider's own app

The guest downloads an application supplied by the access-control vendor or its certified partner. The app receives the credential and communicates with the lock, often through Bluetooth Low Energy.

This can be the fastest technical route because the vendor controls the credential logic. The trade-off is another app for the guest to discover, install and trust.

2. The hotel's app with a certified SDK

Some access-control suppliers provide a software development kit that allows their mobile key to sit inside the hotel's branded application. SALTO JustIN Mobile, for example, describes integration through an SDK for third-party applications and hotel systems.

This gives the hotel a more coherent digital journey, but it still relies on the lock provider's certified credential technology. The hotel application is the interface; it is not inventing its own door-key protocol.

3. Apple Wallet or Google Wallet

Wallet-based access removes much of the app friction after provisioning. Apple identifies hotel room keys as a supported Wallet use case, while Google's Hotel Key documentation describes NFC credentials for compatible Android devices and hotel readers.

The guest can keep a room key beside payment cards, travel passes and other credentials. Depending on the approved implementation, provisioning may begin in the hotel app, a service-provider flow or a web journey. Vingcard's Google Wallet announcement is one useful example of a flow designed to avoid forcing an unfamiliar application download.

Wallet support is not a generic switch. Apple restricts access to its NFC and Secure Element platform to authorised developers that meet security and privacy requirements. Google similarly expects the hotel to work through an approved service provider and compatible access hardware.

NFC or Bluetooth: what is the difference?

Neither technology is automatically superior for every property. Wallet-based NFC can be the cleanest guest experience. BLE may be more practical where the installed lock estate already supports it. Some modern access platforms support more than one route.

Hotels should test the exact phone, watch, lock firmware and reader combination they intend to deploy. A specification sheet is not a substitute for opening a real room door repeatedly under hotel conditions.

Can existing locks be upgraded?

Sometimes. It depends on the manufacturer, model, reader generation, firmware and how the property encodes its current cards.

A recent RFID lock may accept a certified NFC or BLE module, reader replacement or firmware upgrade. An older magnetic-stripe or early RFID estate may require a larger replacement project. The only reliable answer comes from an inventory that records:

• 1lock manufacturer and exact model;
• 2reader and firmware version;
• 3current keycard technology;
• 4online, offline or gateway-connected architecture;
• 5lift, spa, parking and common-area readers;
• 6battery condition and maintenance history;
• 7supported mobile-access upgrade path.

Do not survey only the guest-room doors. A mobile key that opens the bedroom but not the lift to that floor is an incomplete journey.

The PMS and credential lifecycle

The PMS does not usually perform the cryptographic work of opening the door. It supplies trusted stay events to the orchestration or access-control layer.

A sensible workflow looks like this:

1. The reservation is confirmed and the guest completes the required identity and payment steps. 2. The hotel assigns a room and authorises check-in. 3. The integration sends the minimum required stay and room context to the approved lock provider. 4. The lock provider issues a device-bound, time-limited credential. 5. The guest adds or activates the key through the approved app or wallet flow. 6. A room move updates or replaces the credential. 7. Checkout, cancellation or manual suspension revokes access.

Every step needs a defined owner. If a room is changed in the PMS but the old key remains active, the integration has failed even if the new key works.

The operational design should also cover early arrival, late checkout, shared rooms, multiple guest devices, adjoining rooms, lost phones, dead batteries, device replacement and manual front-desk override.

Can a web app open the door?

A browser can be an excellent place to start check-in, verify a booking or request a key. It should not be treated as a universal replacement for a certified wallet or native mobile-access stack.

Browser access to Bluetooth, NFC and secure device storage varies by operating system and is deliberately restricted. A progressive web app may coordinate the journey, but the door credential should still be created and protected by the approved access-control and wallet technology.

That distinction matters. Hotels should avoid proposals that promise to reproduce a certified key system with an ordinary web token and a custom reader. Door access is a security system, not a marketing widget.

Security and privacy controls

Mobile access can improve control because credentials can be device-bound, time-limited and centrally revoked. It also creates a connected identity and access process that must be governed carefully.

At minimum, the hotel should require:

• 1encrypted communication between the PMS, orchestration layer and access provider;
• 2strict separation between properties and staff roles;
• 3credentials limited by room, stay and permitted common areas;
• 4immediate revocation and a visible audit trail;
• 5no storage of reusable master-key material in the hotel app;
• 6vendor processes for compromised devices and platform incidents;
• 7documented retention periods for access and provisioning logs;
• 8an emergency method that works if an integration or network service is unavailable.

Personal data should be limited to what is needed to issue and manage access. The European Commission's GDPR principles emphasise purpose limitation, data minimisation, accuracy, storage limitation and appropriate security. A lock event should not become an unlimited source of guest-behaviour data simply because the system can record it.

Does mobile key mean keyless-only?

Usually, no. During rollout, hotels should keep a physical-key path for guests whose phones are unsupported, discharged, lost or shared with another traveller. Accessibility, group travel and operational resilience also argue for a hybrid policy.

The commercial goal should be to reduce avoidable front-desk work, not to force every guest into one digital route. A well-designed mobile key is an option that becomes the easiest choice.

A practical pilot plan

Start with one floor or a representative group of rooms. Include at least one lift or common-area reader if those are part of the intended journey.

The pilot should test:

• 1iPhone, Apple Watch and representative Android devices supported by the provider;
• 2key provisioning before arrival and after front-desk check-in;
• 3first entry, repeated entry and entry after a device restart;
• 4room moves, stay extensions and early checkout;
• 5two guests sharing one room;
• 6lost-device suspension and physical-key fallback;
• 7operation during weak hotel Wi-Fi or mobile coverage;
• 8audit logs and staff recovery procedures;
• 9battery impact and lock-maintenance workflow;
• 10guest instructions in the property's principal languages.

Measure more than successful openings. Record provisioning failures, time to recover, support calls, fallback keycards and front-desk handling time. The pilot should prove that the operation becomes simpler.

Questions to ask vendors

Where COTT.TV fits

COTT.TV is evaluating certified mobile-access integrations as a future extension of the guest journey. The logical role for a hospitality platform is orchestration: use authorised PMS stay state, guide the guest through provisioning, show the right instructions on the in-room screen or mobile interface, and ensure that checkout and room changes reach the approved lock provider.

Mobile access is not currently included in the standard COTT.TV package. Any future implementation would use certified lock-provider APIs and approved Apple Wallet, Google Wallet or vendor SDK flows. COTT.TV would not create proprietary door credentials or replace the security functions of the access-control manufacturer.

That approach is consistent with the broader COTT.TV guest experience: one clear journey for hotel information and services, while specialist systems remain responsible for the functions they are certified to perform.

Frequently asked questions

Can every hotel lock use Apple Wallet or Google Wallet?

No. The lock or reader must be supported by an approved access-control provider, and the deployment must meet that provider's hardware, firmware and service requirements.

Does the phone need internet access at the door?

Not necessarily for every tap or unlock, but provisioning, updates and revocation can depend on connectivity. The exact offline behaviour must be confirmed with the chosen wallet and lock provider.

Can a hotel issue a mobile key before the room is assigned?

The guest journey can begin earlier, but a usable room credential should follow the hotel's room-assignment and check-in rules. Vendors differ in how they stage and activate the key.

What happens when the guest changes rooms?

The old entitlement should be revoked and the new one issued through an automated, auditable workflow. This is a core pilot test, not an edge case.

Will mobile keys eliminate plastic cards?

They can reduce card use substantially, but most hotels should retain a fallback for unsupported devices, accessibility needs, groups, lost phones and service disruption.

Sources and further reading

• 1Apple Developer: Wallet
• 2Apple Developer: NFC and Secure Element Platform
• 3Google for Developers: Hotel Key overview
• 4Google for Developers: Wallet access
• 5Vingcard: Mobile Access solution brochure
• 6Vingcard: Google Wallet hotel key announcement
• 7SALTO: JustIN Mobile
• 8European Commission: GDPR processing principles

This article provides technical and operational guidance, not a compatibility guarantee or legal advice. Exact functionality depends on the lock model, firmware, service provider, wallet approval, country, device and integration scope.