A hotel rolling out phone-as-key needs three things proven before opening day: the key actually arrives on the guest's phone at or after check-in, it stops working the moment checkout is recorded in the PMS, and a physical card or staff credential still opens the door if Bluetooth, NFC, or the network fails. On Salto's platform this runs through JustIN Mobile, triggered by a PMS event (an Opera Cloud or Mews check-in), encoded by the property's Salto encoder/gateway, and delivered over the air to the guest's phone. None of that is automatic just because the hardware is installed — it has to be configured and then tested room by room before the property depends on it.
Which Salto platform actually supports phone-as-key?
Salto Space is the on-premise platform most full-service and larger properties run, and it supports JustIN Mobile check-in as a license-dependent feature — meaning the functionality has to be covered by the property's selected license options before it appears in the check-in screen at all, per Salto's check-in documentation. The same source notes that "Send key to guest's mobile" only displays during check-in if "Allow mobile guest's keys" has been enabled on that specific room's settings, so a property can accidentally leave individual rooms without mobile-key capability even after the system-wide license is active. Confirming both the license and the per-room setting is a configuration step the integrator or hotel's Salto administrator has to verify room by room, not something to assume from the sales literature.
What does the integrator configure versus what Salto or the PMS owns?
The division of labor is fairly clean. The PMS (Opera Cloud or Mews) owns the reservation record and fires the check-in or checkout event. Salto's Mews Connector or equivalent interface receives that event and generates a key-encoding command. The property's Salto Space system — specifically its Ethernet encoders — then creates the actual key data and pushes it over the air to the guest's phone; Salto's Mews integration page describes the encoder as acting "as a dongle" for this OTA encryption step, and notes the key creation can be triggered from the Mews Web app (a staff-only tool) or from the Mews Kiosk, which has both a guest self-service mode and a staff-assisted co-op mode.
What the integrator configures directly: the per-room "Allow mobile guest's keys" setting, the notification message guests see during check-in, optional-facility access tied to each key (spa, pool, elevator), the number of keys permitted per reservation, and the gateway/encoder network path that lets the OTA push actually reach the property's Wi-Fi-connected phones. What stays with Salto's cloud infrastructure or the PMS vendor: the underlying encryption of the OTA key package, the PMS's own check-in/checkout event logic, and the JustIN Mobile app itself on the guest's device. A hotel's Crestron-based guest-room automation and a Lutron myRoom XC package both sit downstream of this same PMS event, as covered on Cave Group's hospitality page, but the lock credential and the room-control occupancy trigger are separate integrations that each need their own acceptance test.
What acceptance tests prove a key issues and revokes correctly?
Before go-live, run the check-in and checkout paths as real transactions, not just configuration reviews:
- Issue test: Complete a check-in through the actual front-desk workflow (or Mews Kiosk guest/co-op mode) and confirm the key notification arrives on a test phone automatically via push, per the "Getting keys automatically" behavior documented in Salto's JustIN Mobile user guide. Also test the manual pull-to-refresh path, since that's the required fallback if push notifications are disabled on the guest's device.
- Timing test: Verify the key's start date/time matches the room's configured default start time (commonly 16:00) and that the key does not work before that time, confirming the "Start date time" and "Date of expiry time" fields are set as intended for that property.
- Revoke test: Process a checkout in the PMS and confirm the key disappears from the test phone's JustIN Mobile key list, consistent with Salto's description that a cancelled key leaves the app showing "No key assigned to you." Test this with the phone online; the guide notes that if the phone has no connection when the revoke notification is sent, the message won't arrive until the phone reconnects, so confirm the property's Wi-Fi reaches common exit points like the lobby and garage where a departing guest's phone would reconnect.
- Re-rooming test: If the property supports dynamic key delivery, test a room change mid-stay to confirm the old room's key is revoked and the new one issues without a front-desk visit, per the key delivery/room upgrade feature described in Salto's Mews integration documentation.
What fallback credentials need to work when a phone fails?
JustIN Mobile keys have real failure modes that aren't configuration errors — they're documented platform limitations the acceptance test plan has to account for. A dead or airplane-mode phone won't receive a new key or a revoke notification until it reconnects, and Bluetooth-based unlocking (the fallback used outside the EEA on iOS, and on non-NFC Android devices) requires the guest to open the app and hold the phone close to the lock, which some guests will find slower or less reliable than a card. Because of this, every mobile-key rollout should keep physical card issuance live at the front desk and in self-service kiosks as a parallel path, not a deprecated one. The acceptance plan should also confirm that a lost or swapped phone can get keys re-sent once the guest re-registers with the same phone number in the app, and that staff know the manual card-encoding workflow cold, since front-desk staff will be the ones handling it when a guest's Bluetooth or NFC path fails at the door.
Hotels weighing a full access-control rollout — not just the mobile-key piece — should also resolve staff credential separation and door hardware selection before locks go in; that scope sits alongside the PMS and mobile-key configuration described here. Cave Group designs guest-room automation and PMS-integrated access as part of its hospitality work, coordinating the PMS-side interface, lock/gateway configuration, and the acceptance testing that proves issue and revoke events actually fire before a property opens.
Frequently asked questions
Does every Salto lock support phone-as-key out of the box?
No. JustIN Mobile check-in is a license-dependent feature in Salto Space, and even with the license active, each room needs "Allow mobile guest's keys" enabled individually before the mobile-key option appears during check-in.
What happens if a guest's phone has no signal when checkout happens?
The revoke notification won't be delivered until the phone reconnects to the internet; Salto's documentation confirms the key update message queues until the device is back online, so properties should assume there's a delay window rather than an instant cutoff for any offline device.
Can a guest share their digital key with someone else?
No. Digital keys in JustIN Mobile are tied to a specific phone number and cannot be transferred or shared; anyone needing separate access must be issued their own key by hotel staff.
Is NFC or Bluetooth unlocking more reliable for guests?
Both work, but availability differs by device and region: NFC unlocking on iPhone is limited to iPhone XS or later, iOS 17.4+, and only within the European Economic Area, while Bluetooth unlocking works on all supported iOS and Android devices as the universal fallback.
Does mobile key replace physical key cards entirely?
No property should plan on that. Physical card issuance and staff-assisted encoding need to remain fully functional at the front desk, since phone battery failures, lost devices, or unsupported NFC regions all require a card-based fallback that works the same day as the mobile rollout.