SALTO Hotel Key Cards

SALTO XS4 lock generations and what they accept

SALTO Systems is an independent Spanish manufacturer founded in 2001 whose XS4 platform now spans escutcheons, mortise locks, cylinders, lockers and access-control wall readers. The lock generation and the specific reader head determine which chip families drop in without further configuration. Identifying both is the first diagnostic step before any card specification discussion.

A mature SALTO estate rarely runs a single XS4 model. Renovations, room-category refits and locker integrations leave most properties with two or three reader generations coexisting. The card SKU that ships to the property must be the lowest common denominator across the active reader heads, which usually pushes the early-migration decision towards MIFARE Classic 1K and later towards MIFARE DESFire EV2 or EV3 once SVN-Flex or BLUEnet has propagated the updated site keys.

The table below maps the most common XS4 generations and SALTO Neo cylinder variants to their default credential technology, the encoder family that typically ships alongside, and the door-thickness range. Verify the reader-head firmware with SALTO service before locking in a chip — XS4 platform updates have introduced or extended chip support without a model-name change.

Chip-family compatibility per generation

The practical consequence of the XS4 reader-head split is that a single card SKU does not cover every SALTO estate. This section summarises which chip families drop in cleanly and which require a site-key refresh or a reader-head firmware update.

• MIFARE Classic 1K — the historical default across XS4 Original installs and many international XS4 One properties. Crypto-1 is broken at the protocol level; new estates should not standardise on Classic. SALTO documents Crypto-1 as a known weakness and routes new properties towards DESFire.
• MIFARE Plus (EV1 / EV2) — accepted by XS4 Original+, XS4 One, XS4 Mini and Locker as a Classic-compatible migration step. SL1 mode preserves backwards compatibility with Classic card readers; SL3 mode brings AES-128 authenticated sessions.
• MIFARE DESFire EV1 / EV2 / EV3 — the recommended target for new SALTO estates. EV3 ships in a factory default that is wire-compatible with EV2 and EV1, per the NXP datasheet, so EV3 stock can serve an estate originally specified for EV2.
• MIFARE Ultralight C — supported on the XS4 reader heads above. The Ultralight C inlay is the standard choice for hotel paper guest-key cards (low-cost disposable) and is referenced by SALTO's own paper-card SKU.
• HID iCLASS Seos — supported on XS4 One, Mini, AElement Fusion and Neo. Useful for properties that want to issue one credential across SALTO hotel locks and a HID-based corporate access system (offices, parking).
• Magstripe (Track 2 / Track 3) — not native on XS4 reader heads. SALTO is RFID-only in its current generation; estates migrating from magstripe should not expect a fallback card option on SALTO hardware.

ProAccess SPACE, SALTO Space, SALTO KS and Homelok — the back-end stack

SALTO has run three concurrent back-end product lines. The card programme depends on the back-end, not just on the reader head, because the site keys, sector layout and issuance flow live in the back-end software. Ordering DESFire stock for a property still on a pre-5.6 ProAccess SPACE produces silent encoding failures even when the reader heads themselves accept DESFire.

• ProAccess SPACE (now branded SALTO Space) — the on-premise platform. Windows-based, SVN data-on-card architecture, manages site keys and operator permissions. ProAccess SPACE was the historical name; SALTO has folded it into the SALTO Space brand on newer documentation while keeping the same software family.
• SALTO KS — the cloud-native SaaS back-end. Requires continuous internet connectivity from the property. Best for boutique and multi-site operators that prefer SALTO to handle the server. Card-encoding workflow runs through a Local IO Bridge on each front-desk PC that bridges to the USB encoder.
• SALTO Homelok — the residential / multi-family variant. Listed here for completeness; rare on commercial hotel estates but appears in extended-stay / aparthotel deployments.
• BLUEnet wireless — SALTO's real-time online layer. When a property is on BLUEnet, lock-side site-key updates and card revocations propagate without an SVN data-on-card round trip; if a property is off BLUEnet, card revocations rely on the next card touching an online wall reader.
• Local IO Bridge — required on every front-desk PC that drives an encoder. SALTO KS specifically documents the Local IO Bridge dependency; some older PPDs connect via legacy COM ports that need a serial-to-USB adapter.

Mobile Access — JustIN Mobile, Apple Wallet, Google Wallet, partner mobile-key platforms

Modern XS4 generations (One, AElement Fusion, Mini with BLE option, Neo BLE) issue mobile credentials alongside physical cards. The mobile track is a separate procurement decision from card stock; this section exists so card buyers can flag mobile-track dependencies before they become surprises.

• JustIN Mobile — SALTO's first-party BLE mobile-key product. Keys are issued over the air from SALTO Space or SALTO KS and delivered to the JustIN Mobile app on iOS and Android. JustIN works without internet at the lock side (BLE local handshake), which is the operational advantage over NFC-only mobile keys.
• Apple Wallet and Google Wallet — supported on XS4 One, AElement Fusion and Neo BLE through SALTO's wallet keys integration. The property must run SALTO as the active credential provider in ProAccess SPACE wallet settings; this is a back-end toggle, not a card-stock dependency.
• FLEXIPASS — SALTO's hotel-industry mobile-key platform partnership; commonly deployed for chains that want one mobile-key vendor across multi-brand portfolios.
• OpenKey × SALTO — the long-running third-party mobile-key integration; useful for properties already on OpenKey from an earlier dormakaba or VingCard relationship.
• HID Origo via Avigilon Unity Access — relevant for mixed-vendor estates where corporate access uses HID Mobile Access; SALTO Neo and XS4 One with iCLASS Seos can issue one credential across both.
• Mobile-only operating models still need a card-stack baseline: ADA accessibility, mobile-device failures, walk-in guests without the property app, and front-desk operational overrides all require a backup physical card.

PMS integration — OPERA, Mews, Apaleo, Protel, SiteMinder

SALTO integrates with major hospitality PMS platforms through certified interface drivers. Compatibility is usually a question of driver version and a Local IO Bridge install on the front-desk PC, not card chip. But the driver still dictates the payload structure written to the card.

• Oracle OPERA — validated integration with both OPERA 5 (on-premise) and OPERA Cloud. The interface runs over TCP/IP or RS232 serial depending on the PMS deployment and the encoder generation.
• Mews — first-class integration via the Mews Connector; staff cut keys directly from Mews Operations once the SALTO connector is installed.
• Apaleo — listed on the Apaleo Store as a SALTO-certified integration partner; common pairing for cloud-native independents and small chains.
• Protel — supported via protel.I/O on SALTO Space and SALTO KS deployments.
• SiteMinder, Alliants and other distribution-layer partners — typically used when a property runs Apple Wallet keys, since Alliants is SALTO's named Apple Wallet integration partner.

Security update — ProAccess SPACE 2019 CVE cluster and the MIFARE Classic Crypto-1 issue

Two security topics need to be on the table for any 2026 SALTO procurement conversation: the 2019 CVE cluster against ProAccess SPACE ≤ 5.5, and the industry-wide MIFARE Classic Crypto-1 break that affects any SALTO estate still issuing Classic stock.

On 2 December 2019 SEC Consult published an advisory (SA-20191202-0) disclosing four critical vulnerabilities in SALTO ProAccess SPACE ≤ 5.5: stored cross-site scripting (CVE-2019-19457), path traversal with database export (CVE-2019-19458), arbitrary file write enabling remote code execution (CVE-2019-19459), and the underlying web server running as SYSTEM. SALTO addressed the cluster in ProAccess SPACE 5.6. Any property still on a pre-5.6 build should be remediated before adjusting card stock; the fix is a back-end software update, not a card swap.

Separately, the MIFARE Classic Crypto-1 cipher used to authenticate Classic 1K / 4K cards has been publicly broken for over a decade. Reader-equipped attackers can recover sector keys in under a second on consumer hardware. SALTO does not document this as a SALTO-specific vulnerability — it affects every MIFARE Classic deployment regardless of vendor — but the practical procurement consequence is the same: new estates should standardise on MIFARE DESFire EV2 or EV3 with AES-128 authenticated sessions, and existing Classic estates should sequence a DESFire migration window. SALTO's own product literature and its responsible-disclosure policy steer new deployments to DESFire.

Common field failure modes

Field failures on SALTO estates follow a predictable pattern. Understanding where the break usually happens shortens the troubleshooting cycle and prevents unnecessary card replacements.

• Local IO Bridge missing or stale on the front-desk PC. The encoder enumerates but the PMS cannot drive it; reinstall the bridge from current SALTO support downloads.
• Site-key mismatch on Classic or Plus stock. A ProAccess SPACE site-key refresh after a workstation image rebuild was not propagated to the encoder; re-initialise the encoder and re-issue a test card before reordering stock.
• DESFire EV3 cards rejected on a reader head running pre-2022 firmware that only enumerates EV2. Reader-head firmware update via SVN-Flex or BLUEnet rather than a card change is the fix.
• Card removed too quickly from the reader. SALTO documents this UX failure mode explicitly: "if a card is removed too fast before the reading process is completed, place the card on the reader until the LED stops flashing."
• Encoder error E01 (encoder not detected) or E03 (comms error) on the EC90ENUS / NCoder. Both usually trace back to the Local IO Bridge service rather than to encoder hardware.
• Sector-key collision when a third-party loyalty or access application writes to the SVN-managed Classic sectors; document SALTO's reserved sectors in the property's card-data map before approving a shared-card programme.

Card material and thickness constraints

SALTO reader heads are tolerant of card material variation but there are real limits that surface only at scale. These are the constraints that most often appear in a pilot-to-production transition.

• Standard ISO/IEC 7810 ID-1 thickness (0.76 mm ± 0.08 mm) is the safe default across XS4 reader heads, Neo cylinders and Locker.
• Thicker cards (1.0–1.2 mm) — common for premium PVC, recycled-content or wood-effect cards — read reliably on XS4 One, AElement Fusion, XS4 Mini and Neo BLE. Older XS4 Original reader heads can be marginal above 0.9 mm.
• Bamboo and wood cards with an Ultralight C or DESFire EV3 inlay read well on the BLE-equipped reader heads. Pilot a production-thickness sample on the real door estate before ordering a full batch.
• Metal-edge or anti-metal cards are not recommended for SALTO XS4. The shielding detunes the antenna and produces intermittent reads on Classic-era reader heads in particular.
• Paper hotel guest cards — SALTO publishes a dedicated paper guest-key product based on an embedded Ultralight C inlay; recyclable paper stock is a common low-cost choice for high-throughput properties.
• BLE add-on modules (where retrofitted to XS4 reader heads) do not affect card-stack tolerance; the BLE antenna is independent of the RFID antenna.

What to validate before scaling

A SALTO pilot should exercise both the hardware path (chip, antenna, reader) and the operational path (encoder, Local IO Bridge, PMS, front-desk workflow). Scaling before both paths are proven is the most common source of pilot regret.

• Test one baseline MIFARE Plus or DESFire EV2 card on at least two XS4 reader-head generations before approving DESFire EV3 for the full estate.
• Run a full check-in, extend, re-encode and cancel cycle on a live PMS reservation (not a test reservation) to surface Local IO Bridge and connector edge cases.
• Log the reader-head firmware and the ProAccess SPACE / SALTO KS build for every tested door; these are the first two numbers SALTO support will ask for.
• Confirm the Crypto-1 / Classic migration plan if any of the property still ships Classic stock; otherwise, the security posture of the new card batch will lag the upgrade path SALTO is recommending.
• Plan a small (100–200 card) first production batch before scaling to the full property order. Most field failures show up in the first 30 days of live issuance.

FAQ