Industries
Industries
By Dusaw Team
How hotel electronic door locks identify a key card or phone and decide whether to open, why front-desk encoded cards and networked locks behave so differently, and what to check before you buy.
Every hotel electronic door lock, whether it reads a key card, a wristband, or a phone, is doing the same three jobs: it identifies a credential, decides whether that credential is allowed to open this door right now, and records what happened. What differs between systems is where the "allowed" decision lives. In a traditional encoded-card system the permission is written onto the card itself at the front desk. In a networked access-control system the permission lives on the lock and in the software, and the card is just an identifier. That single difference decides whether you can extend a stay, move a guest, or kill a lost card from a screen, or whether the card has to come back to the desk. This guide explains how hotel electronic door locks work under both models, how RFID and mobile keys read at the door, and what to check before you buy.
A hotel key card system is more than the hardware on the door. In practice you are managing four interlocking components:
The lock: a battery-powered unit with a reader (RFID and, on many models, Bluetooth), a small processor, a motor that releases the latch or deadbolt, and memory that stores the door's configuration, its access list or rules, and an audit log.
The credential: an RFID key card, a wristband or fob, or a digital key stored on a guest's phone.
The encoder or the gateway: in an encoded-card system, a desk-side USB encoder writes room and validity data onto the card; in a networked system, hubs or gateways installed in the building carry instructions from the software to each lock.
The management software: the system that defines which doors exist, which guest and staff credentials can open them and when, and which connects to your property management system (PMS) so that access follows reservations.
Hotel locks run on batteries, so they are designed to make the access decision locally in well under a second, without asking a server at the moment a guest taps the door. Networked systems do not change that; they change how and when the lock's permissions get updated.
An RFID hotel lock reads a passive contactless card. The card has no battery; the reader in the lock generates a short-range radio field, the card's antenna harvests enough energy from that field to power a tiny chip, and the two exchange data over a few centimetres. The dominant standard for these proximity cards is ISO/IEC 14443, published by the International Organization for Standardization, which defines the physical characteristics, the 13.56 MHz radio interface, and the anti-collision and transmission protocols for contactless proximity cards (see ISO/IEC 14443-1:2018). The MIFARE family of chips used in most hospitality cards is built on that standard, and every chip carries a factory unique identifier that a lock can read in a fraction of a second.
What the lock does with that read depends on which of the two models the property runs.
This is the classic hotel key card system, and it is how Dusaw's hotel lock software works when a property runs it standalone. At check-in the agent selects the room and dates in the software, places a blank card on the USB encoder, and the encoder writes an encrypted payload onto the card containing:
the property and lock-system identifier, so a card from another hotel is rejected instantly;
the room number and any common-area doors (pool, gym, floor access) the guest may use;
a validity window: the check-in time and a check-out expiry;
a cryptographic signature, so the data cannot be edited with a consumer card writer.
When the guest presents the card, the lock authenticates the payload, checks that this door is on the card, compares the validity window against its own clock, and releases the latch. Because the permission lives on the card, the lock needs no wiring and no network: the door is fully offline, which keeps hardware and installation costs low and makes this model the default for many properties.
The same design means that any change to a guest's access requires re-encoding. If a guest extends their stay, moves rooms, or wants access to an additional area, the card has to be brought back to the front desk (or a new card issued) so the encoder can write the new data. Staff cannot extend or change a card that is in the guest's pocket. Lost cards are handled by encoding a replacement; the lock software and the card's expiry time limit the risk from the missing one. For a property with a staffed desk and standard stays this is a perfectly workable routine, but it is worth understanding before you buy, because it is the main reason operators move to the second model.
The second approach is how Dusaw Access software works. Instead of writing the permission onto the card, the software registers the card's unique signature on the specific locks it should open, together with the validity rules. The card itself is never encoded; it is simply an identifier, and the lock holds the list of identifiers it will accept. Instructions travel from the software to the locks over the property's network through Dusaw hubs and gateways, so a change made on a screen reaches the door within moments.
That architecture unlocks the operations the encoded-card model cannot do remotely:
Reassign a card to a different room for a room move, without the guest coming to the desk.
Extend or shorten validity for a late check-out or an extended stay from the PMS or the software.
Disable a card instantly when a guest reports it lost or a contractor's job ends, wherever the card happens to be.
Add or remove doors from a credential, such as granting a conference-room or fitness-centre door for the length of an event.
Because the software exposes a full API designed for external property management systems, these actions can be driven by the PMS directly: check-in registers the card on the room lock, an extension in the PMS updates the validity, and check-out revokes it, with no separate lock screen for the agent to operate. The requirement is that the property has the hubs and gateways installed so the locks are reachable; the locks still decide locally at the door, so a brief network outage does not stop a registered card from working, it only delays new changes until connectivity returns.
A small inn with a staffed desk may never need networked locks; a larger hotel, an aparthotel with contactless arrival, or a multifamily building with staff and vendor turnover usually wants the remote control. Our hotel access control system overview describes how the two are packaged, and the integrations page lists the PMS platforms and building systems Dusaw connects to.
A hotel mobile key replaces the card with a digital key tied to the guest's account in the Dusaw app. The key is issued from the software (or from the PMS through the API) for a specific lock with a start and end time, and it can be changed, frozen, or deleted from the same place, so a late check-out or a lost phone is handled without anyone visiting the door. Issuing a new key for the same guest and lock replaces the previous one.
At the door the phone talks to the lock over Bluetooth Low Energy (BLE). The guest opens the Dusaw app, which must be open and signed in for the unlock to happen, selects the door, and the app and lock exchange an encrypted, time-limited token over the short-range Bluetooth link; the lock validates the token against its own clock and releases the latch. There is no tap-to-open from a locked phone or from a wallet app, and the phone does not need a mobile signal at the door because the key is already stored in the app. The Bluetooth Special Interest Group's technology overview explains why BLE suits battery-powered devices such as locks. Where a property has gateways installed, the software can also unlock a door remotely for a guest or a contractor without a phone at the door.
Security of the phone-to-lock link matters. The National Institute of Standards and Technology's Guide to Bluetooth Security (SP 800-121 Rev. 2) catalogues Bluetooth's security capabilities and the threats to Bluetooth-enabled devices, and recommends using the strongest available pairing and encryption modes. When evaluating a mobile key hotel solution, ask which BLE security mode the lock uses, whether keys are bound to a specific device, and how a key is revoked if a guest reports a lost phone.
The property management system is the source of truth for who is staying where and when. Dusaw integrates with platforms such as Choice Advantage, Seam and RemoteLock (the current list is on our integrations page) so that the lock system is driven by reservation events rather than by staff retyping room numbers. In an encoded-card deployment the PMS interface tells the encoder what to write when the agent presses "make key". In a networked deployment the PMS talks to the access software's API and the software talks to the locks, which is what makes extensions, room moves, and revocations possible without the card present. Either way, integration removes the most common source of guest complaints, a key issued with the wrong room or dates.
Because the locks run on batteries, three operational features matter more than any brochure specification:
Low-battery warning. The lock reports its battery level and a low-battery warning is sent to the property administrator, so batteries can be replaced on a schedule rather than after a lockout.
Mechanical or emergency override. Hotel locks keep a concealed key cylinder or an external power contact so a dead lock can still be opened.
Fail-secure behaviour. A guest room lock should remain locked from outside when power is lost while always allowing free egress from inside. Local fire code and the lock's listing determine the exact requirements, so check them for corridor and stairwell doors in particular.
Every electronic hotel lock stores a log of recent events: which credential opened the door and when, failed attempts, deadbolt use, and battery or tamper events. In an offline encoded-card system, staff retrieve the log by connecting a programmer or authorised device to the lock; in a networked system the log flows back through the hubs to the software automatically and can be searched from any device. That record is what you reach for when a guest reports a missing item or a staff member disputes a room entry. Ask how many events each lock stores and how long the software retains them.
Decide which model you need. If you want to extend, reassign, or disable cards remotely, budget for hubs and gateways and choose software with a PMS-ready API. If a staffed desk and re-encoding is acceptable, offline encoded locks cost less.
Confirm the card technology. If you are keeping existing cards or wristbands, make sure the new locks read the same ISO/IEC 14443 chip family.
Plan for mobile key from day one, even if you launch with cards. Locks with BLE built in avoid a second hardware swap later.
Get the PMS interface in writing, including who supports it when something breaks.
Check battery life claims against your door traffic and confirm who receives the low-battery warnings.
Plan the audit-log workflow: who reviews logs, how often, and where they are stored.
For a walkthrough of weighing these against your budget and building, see our guide to choosing a hotel door lock system and the comparison of hotel card key systems. If you are planning a new build or renovation, the hospitality solutions page shows how Dusaw locks are deployed across guest-room, common-area, and staff doors, and you can request a quote with your door count and PMS to get a system design rather than a price list.
The lock's RFID reader powers the passive card, and either checks the encrypted room and validity data written on the card at check-in or matches the card's unique signature against the access list stored on the lock, then releases the latch if the card is allowed on that door at that time.
Only with a networked system. With front-desk encoded cards the permission is written on the card, so the card must return to the desk to be re-encoded; with networked locks connected through hubs or gateways the card's signature is registered on the lock and can be reassigned, extended, or disabled from the software or PMS.
Magstripe cards are read by swiping a magnetic stripe and are easy to erase or copy. RFID cards are read contactlessly, carry encrypted data, and wear out far less because nothing touches the reader.
No. Locks make the access decision locally using the card or phone and their own clock. Hubs or gateways are needed only if you want remote changes such as extending, reassigning, or disabling credentials and live event reporting.
Yes. A mobile key is issued to the guest's account in the Dusaw app for a specific lock and time window; with the app open, the phone unlocks the door over Bluetooth Low Energy. The key can be extended, frozen, or deleted from the software at any time.
The lock sends a low-battery warning to the administrator well in advance and stays locked from outside while allowing egress from inside. Staff can open a dead lock with a concealed mechanical override or an external power contact and then replace the batteries.
