Hotel RFID Access Control

Whole-property zone matrix — guest room, BOH, elevator, parking, amenity, conference

A hospitality access programme is at least seven distinct zones with different reader-class, credential-factor and policy requirements. The matrix below maps each zone to its operational baseline; single-vendor lock-PR pages never publish this comprehensively because each vendor focuses on the zones they sell into.

Elevator destination dispatch integration — KONE, Otis, Schindler PORT, Mitsubishi, Hitachi

Modern tower hotels rely on destination-dispatch elevator control rather than traditional up/down call buttons. The guest presents a credential at a lobby terminal; the system assigns an elevator car and shows the destination floor before the guest enters. RFID lobby readers + in-car readers integrate with the elevator vendor's destination-dispatch back-end. The first commercial destination dispatch system was Schindler Miconic 10 (1992); current systems are functionally similar but with much deeper RFID integration.

• **KONE Destination** — RFID lobby reader writes destination request to KONE elevator back-end via TCP/IP integration. The reader can be HF 13.56 MHz contactless (most common for hospitality) or BLE mobile credential. Integration spec published by KONE; integration testing typically runs 2–3 weeks per property.
• **Otis Compass / Compass360** — Otis's destination dispatch family. Compass uses lobby touchscreen + RFID; Compass360 adds mobile-credential support via Otis's eView mobile platform.
• **Schindler PORT** — Schindler PORT (formerly Miconic 10) is the world's first destination-dispatch system (1992). Modern Schindler PORT terminals accept RFID hospitality credentials and Schindler's PORT 4D BLE mobile credential.
• **Mitsubishi DOAS (Destination Oriented Allocation System)** — common in Asian tower hotels. RFID lobby reader + in-car reader integration; Mitsubishi DOAS-Net protocol.
• **Hitachi DFRS / FIBEE** — Hitachi's destination-dispatch family; common in Japanese hospitality estates. Integration with MIWA hotel lock credentials is a common pairing in Japan-domestic deployments.
• **Architecture pattern** — most hotels run a single RFID credential type (e.g., MIFARE DESFire EV3) that opens both the guest room door (via the lock-vendor reader) and triggers elevator destination dispatch (via the elevator-vendor lobby reader). The credential authenticates to both vendors' back-ends through a shared PMS integration.
• **Test plan** — pilot the elevator destination dispatch credential round-trip end-to-end before scaling. Mismatch between the lock-vendor encoder writing the credential and the elevator-vendor lobby reader reading it is the #1 failure mode. Both vendors need to confirm credential format support.

Aliro 1.0 — unified Apple / Google / Samsung wallet digital key standard

Aliro 1.0 was published by the Connectivity Standards Alliance (CSA) in February 2026 as the unified standard for digital keys in mobile wallets across Apple, Google and Samsung. Before Aliro, every hotel-lock vendor implemented Apple Wallet, Google Wallet and BLE mobile keys via vendor-specific app integrations. Aliro standardises the credential format, the BLE / NFC / UWB transport, and the over-the-air credential delivery so that a single credential issued through the hotel's PMS can be delivered to any wallet platform without vendor-specific code.

• **Why Aliro matters in 2026** — eliminates vendor-specific BLE app sprawl. A hotel chain with mixed Vingcard / Saflok / SALTO / Onity lock estates can issue one Aliro-compliant digital key from the PMS that works on Apple Wallet, Google Wallet, Samsung Wallet, and any first-party lock-vendor app.
• **Transport layers** — Aliro supports NFC (existing physical-card tap experience), BLE (proximity unlock with no tap required), and UWB (Ultra-Wideband for precise proximity gating in high-end deployments).
• **Apple alignment** — Apple HCE NFC in apps (iOS 17.4 EEA-only feature, expected wider rollout) aligns with Aliro 1.0 transport.
• **Lock-vendor readiness** — Vingcard, Saflok, SALTO, Onity have all signalled Aliro support roadmap. Properties planning a 2026–2027 access refresh should specify Aliro-readiness in vendor RFPs.
• **Physical card co-existence** — Aliro mobile keys complement, not replace, physical cards. ADA accessibility, mobile-device failures, walk-in guests without the property app, and front-desk override scenarios still require the physical card baseline. Plan a parallel card programme that uses the same RFID chip family.
• **Procurement window** — 2026 is the vendor-selection and pilot year. 2027 is full-line rollout. 2028+ is the operational baseline with both Aliro mobile keys and physical cards in production.

Security update — four-vendor CVE timeline

Every major hotel-lock platform has had a public security disclosure of meaningful scale. Procurement teams running multi-vendor estates need to map remediation status across all four vendors, because the weakest-link CVE determines the property's actual access-control security posture. The table below is the comparative view that no single vendor will publish on their own product pages.

For multi-vendor estates: confirm remediation status with each vendor's service for every door in scope before scaling new card stock or running any access-control audit. A property with patched Saflok + unpatched Onity HT is only as secure as the unpatched Onity HT zone. Schedule cross-vendor remediation as a single workstream rather than per-vendor sequencing.

Separately, the **MIFARE Classic Crypto-1 cipher** is publicly broken across all hotel-lock vendors. New estates should standardise on MIFARE DESFire EV3 with AES-128 authenticated sessions; existing Classic estates should sequence DESFire EV3 migration windows. See `/solutions/hotel-key-cards/` for the card-stock procurement decision.

OSDP Secure Channel — replacing Wiegand on new builds

The 1970s Wiegand reader-to-controller protocol is plain text, unencrypted and easily cloneable by a tap-on-wire attack. OSDP (Open Supervised Device Protocol) v2 with Secure Channel adds AES-128 mutual authentication between reader and controller. On a 2026 access refresh, replacing Wiegand readers with OSDP-v2-capable readers closes the wire-side attack surface that even a remediated lock + DESFire EV3 card stack leaves open.

• **Wiegand vulnerability** — the reader sends card data to the controller in plain text over a two-wire interface. A tap-on-wire attack between reader and controller captures every credential without ever touching a card. Even when the chip is DESFire EV3 and the lock firmware is fully remediated, Wiegand on the back end is the weak link.
• **OSDP v2 Secure Channel** — adds AES-128 mutual authentication between reader and controller. The reader and controller exchange a session key at start-of-session; all subsequent traffic is encrypted. Tap-on-wire attacks become useless.
• **Migration strategy** — most properties on a Wiegand-based reader infrastructure can migrate to OSDP without changing the lock itself by replacing the reader head. New-construction hospitality projects should specify OSDP v2 + Secure Channel as the default; legacy estates should phase OSDP migration during the next access-control refresh cycle.
• **SIA standards body** — Security Industry Association maintains the OSDP standard. SIA has published "There Is a Hole in the Boat" (November 2021) calling Wiegand insecure and recommending OSDP migration across the access-control industry.
• **Dual-protocol readers** — many current readers support both Wiegand (legacy controller compatibility) and OSDP (forward-compatible). Procure these on a 2026 refresh so the property can migrate to OSDP back-ends without touching readers a second time.

PMS integration — Oracle OPERA Cloud, Mews, Apaleo, Cloudbeds, Sabre SynXis

The PMS connector decides whether an access-control programme operates as a single property-wide system or as a federation of vendor silos. Oracle OPERA Cloud's `roomKeysOutbound` action enum is the de-facto standard PMS integration interface across major hotel-lock vendors; each lock vendor exposes its own local encoding agent that bridges the cloud PMS to USB / Ethernet encoder hardware.

• **Oracle OPERA Cloud** — integrate via `roomKeysOutbound` configuration with GUESTKEY_GENERIC outbound type. Supported actions: New / Duplicate / One-shot / Read / Delete key. Same shape across major hotel-lock vendor connectors. OPERA 5 (on-premise) supported via legacy serial interface.
• **Mews** — Mews Open API integrates with Saflok, Vingcard, SALTO, Onity, Häfele Dialock and MIWA per published partner integrations. Requires vendor-specific connector (Saflok HMS, Dialock HMS, etc.) co-installed on front-desk PC.
• **Apaleo** — listed as integration partner across Vingcard VConnect, Häfele Dialock, SALTO and others. Common for cloud-native independent and small-chain operators.
• **Cloudbeds** — listed on Vingcard VConnect; documented integration with Saflok, SALTO and others.
• **Sabre SynXis** — integration with hotel-lock vendors typically runs through SynXis Property Hub or SynXis Central Reservations connector to the lock-vendor back-end.
• **Multi-property chain operations** — chains running multiple PMS deployments across properties standardise on the lock-vendor side (one connector per vendor) rather than the PMS side. Mixed PMS estates use the lock-vendor's back-end as the integration anchor.

CapEx + OpEx framing — 100-key vs 500-key vs 2,000-key property

Whole-property RFID access-control programmes have a well-understood cost shape. The table below gives indicative ranges for three property profiles; actual quotes vary by reader-class mix, encoder count, mobile-credential rollout scope and lock-vendor choice.

• **Density discount** — per-door hardware + install cost drops roughly $200–500 per door at 70+ door scale due to amortised mobilisation and installer-day economics.
• **Cloud-SaaS pricing** — typical $3.50–15 per door per month range covers Saflok Ambiance, Vingcard Vostio, SALTO KS at chain-negotiation tier. Property-by-property pricing tends higher.
• **Mobile-key Aliro CapEx** — one-time integration with the PMS + lock-vendor mobile-credential back-end. After rollout, ongoing cost is bundled in the SaaS subscription.
• **Annual maintenance** — typically 5–10% of per-door hardware cost for routine maintenance, battery replacement, firmware updates and warranty servicing.
• **ROI consideration** — modern access-control hardware has 7–10-year service life. Total cost of ownership over 7 years amortises to ~$300–400 per door per year all-in.

Compliance overlay — PCI DSS v4.0, GDPR, ADA, ISO/IEC 27001

Hospitality access control crosses four compliance regimes that intersect at specific control points. Treat the compliance layer as a procurement gate, not a post-hoc audit.

• **PCI DSS v4.0** — triggered when amenity / POS spend flows through the PMS that issues access credentials. Named control of relevance: 15-minute idle session timeout (the only PCI DSS control with a specific time value). Reader-to-controller traffic on OSDP Secure Channel satisfies the encryption-in-transit requirement.
• **GDPR (EU 2016/679)** — access logs are personal data when tied to guest identity. Article 32 mandates appropriate technical / organisational measures including retention limits; typical retention is 30–90 days for routine guest access, longer for staff and BOH zones. Document the retention policy in the privacy notice.
• **ADA / ICC ANSI A117.1** — §308–309 specify operable-parts reach range 34–48 inches AFF (Above Finished Floor) for forward-reach and side-reach scenarios. Reader-mount height needs to fall in this range on all guest-accessible doors. The U.S. Access Board Chapter 4 also covers maneuvering-clearance overlap rules for door hardware.
• **ISO/IEC 27001 / 27002** — Annex A controls A.7 (physical entry) and A.9 (access control) apply to the property's information-security management system. Hospitality chains pursuing ISO 27001 certification need documented procedures for credential issuance, revocation, periodic review and audit-log retention.
• **CCPA (California Consumer Privacy Act)** — applies to California-resident guest access data. Similar controller / processor framework to GDPR.
• **Industry-specific** — PCI DSS v4.0 is the only major framework with a specific named time-value (15-min idle timeout); ISO 27001 + GDPR are framework-level. Document the named PCI value in supplier RFP responses to distinguish from generic "compliance-friendly" claims.

Pilot validation checklist — whole-property test plan

A whole-property access-control pilot should exercise every zone, every reader class, every credential factor, every integration partner, and every compliance gate before scaling. Scaling without complete pilot validation produces predictable expensive retrofits.

• **Per-zone validation** — test the credential on at least one door / reader from every zone in the matrix above. Mismatch between zones (e.g., room-door reader accepts DESFire EV3 but pool-area reader is still Classic-only) is the #1 cross-zone failure mode.
• **Elevator destination dispatch end-to-end** — validate the round-trip from PMS → lock-vendor encoder → elevator-vendor lobby reader → car assignment → in-car reader (for club-floor gating). Both lock vendor and elevator vendor need to confirm credential format compatibility.
• **CVE remediation confirmation** — for every lock vendor in scope, confirm remediation status with vendor service. Saflok CVE-2024-29916, Vingcard Vision 2018, SALTO 2019 cluster, Onity HT 2012 each need explicit confirmation.
• **Aliro mobile credential** — pilot the Apple Wallet + Google Wallet + Samsung Wallet credential delivery flow if mobile keys are in scope. Confirm BLE proximity behaviour at expected reader sites.
• **OSDP v2 Secure Channel validation** — if migrating from Wiegand, confirm OSDP Secure Channel handshake on each reader-controller pairing.
• **PCI DSS / GDPR / ADA compliance** — exercise the 15-minute idle timeout; verify reader-mount height with tape measure (not eyeball); confirm access-log retention is set per policy.
• **100-200 credential pilot batch** — produce a pilot batch of 100–200 cards (or BLE credentials) and exercise full PMS round-trip (issue / extend / replace / cancel) on live reservations before scaling to full property.

FAQ