How a hotel key card works
A hotel key card is a passive 13.56 MHz contactless card, most commonly ISO/IEC 14443 Type A (MIFARE), with some brands using ISO/IEC 15693 or FeliCa reader heads. It has no battery; the lock's reader powers the chip through a 13.56 MHz field when the card is held within a few centimetres. At check-in the front-desk encoder writes the room number, the valid stay window and an access profile (guest, housekeeping, maintenance) into the card's memory, protected by keys that only the lock system knows.
Most hotel locks are offline. They do not talk to a server; they trust what the card carries because it was written with the right keys, and they keep their own clock to check the stay window. Online locks (wired or wireless) add remote cancellation and audit trails, but the card itself works the same way. The lock software, not the card, integrates with the property management system so that check-in and encoding are one step.
Because the memory layout and keys are defined by the lock vendor, a card is only useful if the chip and its configuration match what that vendor's encoder expects. That is why every question about hotel key cards comes back to the lock.
Choosing the chip: Classic, Plus, DESFire and Ultralight
Four NXP chip families cover almost every hotel installation. The table sets them side by side on the terms that decide an order: where the security stands, which lock generations expect them, how much work a migration is, and the relative cost tier of the chip itself.
The lock decides. A reader only opens the door for a chip its firmware is built to authenticate, and the firmware in your building matters more than any brand-level list. Confirm the accepted chip with the lock vendor for your exact model, and test a sample in your own encoder and in the lock before committing to a run. The cost tiers below describe the chip only; the card price for your specification and quantity is confirmed in the quotation.
- Classic 1K/4K only for an existing Classic-only estate with no upgrade planned; re-encode every stay to limit the exposure of any cloned card.
- MIFARE Plus when migrating off Classic or spanning a mixed estate with one SKU that works today in SL1 and moves to AES in SL3 as locks are upgraded.
- DESFire EV2/EV3 for new builds, brand or insurer security mandates, and any card that must also carry spa, lift, loyalty or cashless applications; specify EV3 where wallet keys are on the roadmap.
- Ultralight C/EV1 for high-volume disposable or single-stay cards where the lock already expects it and full AES is not required.
| Chip | Security status | Typical lock generations | Migration effort | Relative cost tier |
|---|---|---|---|---|
| MIFARE Classic 1K/4K | Crypto-1, publicly broken since 2008 and clonable with commodity tools | The widest installed base, from the late 1990s onward (older Saflok, Onity and VingCard readers) | None while staying put; this is the chip to move away from | Entry |
| MIFARE Plus (SL1/SL3) | AES-128 in SL3; SL1 presents to a reader as Classic for backwards compatibility | Upgraded firmware on estates leaving Classic; a drop-in on many post-2010 readers in SL1 | Low: one SKU can run SL1 on legacy readers and switch to SL3 as firmware is upgraded | Mid |
| MIFARE DESFire EV2/EV3 | AES-128 with mutual authentication and file-level keys; EV2 added the Proximity Check that defends against relay attacks; EV3 adds SUN secure-messaging and backward-compatible crypto agility | Current lock generations and new builds; not readable by Classic-only readers | Higher: needs reader and encoder support, confirmed per lock model | Upper |
| MIFARE Ultralight C / EV1 | Ultralight C adds 3DES; EV1 offers limited protection; both have small memory | Disposable single-stay cards; a documented Saflok default on some generations, plus some retrofits | Low where the lock already expects it | Entry (small memory) |
Lock compatibility by brand
The seven brands below account for most hotel estates. The matrix consolidates what each lock family accepts at the card level: the lock generations you are likely to meet, the card technologies their reader heads read, and the details to confirm before ordering. Every cell describes documented chip acceptance as published by the lock vendor — not partnership, authorisation or endorsement — and it does not override the firmware installed in your building. Where a chip is not listed as standard for a brand, treat it as unconfirmed until the vendor states otherwise in writing for your model. Read it with the verification steps in the next section: the reader head, encoder and back-end all have to agree before a card opens a door.
Magnetic-stripe coexistence. Several of these brands still run a magnetic stripe beside the RFID chip (Onity HT-series, Saflok MT and combo locks, VingCard Classic dual-track, Miwa AL5H), and a combi card bridges the two while lifts, car parks or a legacy wing keep older stripe readers. Coercivity matters: hotel stripes are high-coercivity (HiCo, around 2750 oersted) or low-coercivity (LoCo, around 300 oersted), and HiCo resists accidental erasure far better, so the stripe and encoder must be set to the same type. The belief that phones and magnets wipe key cards comes from the stripe, not the chip: an RFID chip stores data in silicon memory with no magnetic domain, so a phone or fridge magnet cannot erase it, though a strong magnet can weaken a LoCo stripe. Replacing an RFID-only card because "a phone demagnetised it" hides no defect — the cause is almost always a flat lock battery, a drifted clock or a mixed chip batch.
| Lock brand | Typical lock generations | Card technologies accepted (as documented by the lock vendor) | What to confirm with the vendor |
|---|---|---|---|
| Onity | HT-series (magstripe/hybrid), ADVANCE, integra, Trillium; DirectKey BLE overlay | Proprietary magstripe (HT-series); MIFARE Classic 1K (ADVANCE, integra, Trillium); MIFARE Plus SL1, and SL3 on newer integra/Trillium firmware; Ultralight C on some retrofits; DESFire not a standard credential; BLE (DirectKey) and Apple/Google Wallet on newer Trillium firmware | Reader generation and firmware; validate DESFire separately (not a default); the property's Onity front-desk encoder firmware for Plus SL3; HT-series security remediation before reordering |
| dormakaba Saflok | MT magstripe, Confidant, Quantum IV/RT, Messenger LENS, Quantum Plus (Series 8), Quantum Pixel | Magstripe (MT and combo); MIFARE Classic 1K (widest); MIFARE Plus SL1 (RT and later) and SL3 (LENS/Quantum Plus); DESFire EV1/EV2/EV3 on Messenger LENS, Quantum Plus and Pixel; Ultralight C on some generations; BLE and Apple/Google Wallet on Pixel; LEGIC as the mobile-provisioning backbone | Door-controller generation and firmware; encoder platform (System 6000 vs Ambiance; the Gen II encoder) firmware for DESFire; remediation of the 2024 Unsaflok disclosure before a bulk refresh |
| ASSA ABLOY VingCard | Classic RFID, Essence, Signature RFID (+BLE), Allure, Flex (marine); Senior/Solitaire legacy | Magstripe on Classic dual-track; MIFARE Classic 1K; MIFARE Plus EV1 4K; DESFire EV3 4K/8K on reader-type 3G or newer only (not E100/C100 heads); Ultralight EV1 and Ultralight AES; BLE with Apple/Google Wallet on Signature, Allure and Essence | Reader-type designation (3G or newer for DESFire); back-end (Vision/Visionline/Vostio) and the VingCard encoder firmware; Vision patch status if still on it |
| Salto | XS4 Original / Original+ / One / Mini / Locker, AElement Fusion, Neo cylinder, GEO | RFID only (no magstripe); MIFARE Classic 1K; MIFARE Plus EV1/EV2 (SL1/SL3); DESFire EV1/EV2/EV3; Ultralight C (paper guest cards); HID iCLASS Seos; BLE (JustIN) with Apple/Google Wallet on BLE heads | Reader-head firmware (older heads may enumerate EV2 only, not EV3); back-end (SALTO Space/KS; ProAccess SPACE 5.6+); Local IO Bridge and encoder (NCoder) |
| Miwa | ALV2 (Wide/Slim), ALV3M/ALV3MA, V3HTM/V3HTMA, AL5H hybrid; PiACK line; VERSA-II controller | Magstripe on the AL5H hybrid; MIFARE Classic 1K/4K; MIFARE Plus (ALV3); DESFire EV2/EV3 (ALV3, V3HTM); FeliCa IDm and Miwa's FKL FeliCa card on FeliCa-enabled hardware (PiACK, VERSA-II, and ALV2 firmware with the FeliCa antenna mode) — so Suica/PASMO transit cards can act as a credential; BLE (KEYMO) | Reader-head firmware, including whether the FeliCa antenna mode is enabled; Card Issuing System encoder firmware for DESFire; whether FeliCa or transit-card use is in scope |
| Häfele Dialock | DT 100–750 door terminals, WT wall terminals, FT furniture terminals, EFL/LL lockers; Software Generation 2 | RFID only (no magstripe); Tag-it HF-I (ISO/IEC 15693); MIFARE Classic EV1; DESFire EV2 on DT 510/700/710/750 (EV3 stock is wire-compatible); LEGIC (advant/prime) as a reader-head option common on DACH installs; BLE (Dialock Smartphone Key) | Terminal firmware (DESFire needs a post-2017 line); that one inlay covers door, furniture and locker terminals; whether each head is MIFARE or LEGIC, and the moisture environment for LEGIC |
| Be-Tech | BASE (9004/9248, RETRO/LEVER), SHADOW II, VISUAL/VISUAL II, GUARDIAN/GUARDIAN VALUE; BIS HOTEL back-end | MIFARE Classic 1K over ISO/IEC 14443A across the published catalogue; MIFARE Plus, DESFire and HID iCLASS not documented; no magstripe; BLE (Mobile Key, Android) on VISUAL II and newer GUARDIAN | Whether Plus or DESFire is supported for your model in writing (treat as Classic-only otherwise); mortise variant; encoder firmware against the BIS HOTEL build; the actual PMS connection method |
Verifying compatibility before you order
Lock vendors publish which chips each lock generation accepts, but the installed firmware in your building is what matters. Older readers may accept Classic only; upgraded firmware may accept Classic and Plus in compatibility mode; the newest generations expect DESFire. Mixed estates are common in properties that have been extended or refurbished in phases.
The reliable procedure is short:
- Identify the lock model and firmware on a sample of doors, including any older wing.
- Send a working card so the chip type and sector layout can be read.
- Order a small pilot batch and encode it on your own front-desk encoder.
- Test the pilot cards on every lock generation in the building, including staff and back-of-house doors.
- Only then place the production order with artwork.
Migrating from MIFARE Classic without locking guests out
MIFARE Classic's Crypto-1 cipher was reverse-engineered in 2008 and cheap cloning tools have been available since. A cloned guest card opens one room for one stay; a cloned master or housekeeping card is a much bigger problem. Insurers and chain security standards increasingly require an AES-based chip for new installations.
The migration order matters. Upgrade the lock firmware first so that the estate accepts both the old chip and the new one. Issue the new chip (Plus or DESFire) to arriving guests while cards already in circulation keep working through their stay. After a sunset window, disable Classic on the locks. Hold both card stocks during the transition and agree in advance who owns the AES keys, because the lock vendor's key management, not the card supplier, is what makes the new chip secure.
MIFARE Plus suits this path because SL1 runs during the transition and switches to AES afterwards; DESFire is the cleaner end state where the locks support it.
Card body, print and sustainability
The card body has no effect on the lock as long as the antenna is tuned for it, which we check per material. What it changes is the guest's first impression and the property's sustainability reporting.
Standard cards are ISO/IEC 7810 ID-1 (85.6 × 54 mm, 0.76 mm thick) laminated PVC with full-colour print, and they remain the workhorse for most properties. Wooden and bamboo cards use a real veneer over the inlay and print or laser-engrave the property's mark. Paper and PLA or recycled-PVC cards are the usual answers to a plastic-reduction policy; paper is best for single-stay use, PLA and recycled PVC for reuse.
Whatever the body, the print run needs the same inputs: artwork in CMYK with bleed, any spot colours or metallic foils, whether a signature panel or numbering is required, and the encoder's requirements for card orientation.
Where key card programmes actually fail
The complaint at the desk is always "my card stopped working". The causes are a short list, and the chip is rarely one of them.
- Mixed chip stock. A refill order with a different chip or memory configuration that the encoder writes but the older locks reject. Fix: one specification per property, verified before each reorder.
- Encoder settings. A software update that changes the sector layout or keys without the stock being re-verified. Fix: encode and test a card after any lock-software update.
- Lock batteries and clocks. Offline locks drift or run down and start rejecting valid stay windows. Fix: battery rotation and clock checks as part of maintenance, not as a card issue.
- Physical wear. Cards that live in pockets with keys and coins crack at the antenna weld. Fix: laminated PVC or a thicker veneer for reusable cards; disposables for single stays.
- Stock-outs. A seasonal peak with no buffer stock and a long print lead time. Fix: hold blank or pre-printed reserve stock per property.
- Phones and magnets. As the magstripe section explains, phones and magnets cannot erase an RFID chip; replacing a card for this reason hides no defect.
What Proud Tek manufactures
We make the card, not the lock. Our hotel key cards are produced in our Shenzhen factory, blank or printed, in PVC, wood, bamboo, paper or PLA, with the MIFARE chip your locks accept, and optionally with a magnetic stripe for properties still bridging two reader types. We verify the chip against your sample card before quoting, arrange a pilot batch for new lock generations, and hold artwork and specification per property so reorders match the first run. Cards are shipped unencoded; encoding happens on your own front-desk system with your own keys.
Published 2026-09-09 · Updated 2026-09-25