Hotel teams often compare these cards by color or by the name shown in a software menu. That is the common mistake. A guest card normally grants assignment-based access for a stay; a staff card grants role- and area-based access; a master card is a broad or exception-level credential that should be tightly controlled. The exact scope, expiry, privacy behavior and revocation method depend on the selected lock system.
This comparison is about door credentials—not a hotel payment “master account.” It gives you a permission matrix, a lifecycle control sequence and the questions to verify before you sample an electronic hotel lock system.
The three cards solve different access problems
Start with the person and the access task. A guest needs a temporary path to an assigned room. A housekeeper, engineer or supervisor needs a controlled set of rooms or back-of-house areas. A manager or emergency operator may need wider authority, but that wider authority should be treated as an exception, not a convenience shortcut.
Vendor documentation illustrates the pattern without making the labels universal. OpenKey’s HIMS reference describes guest cards for assigned rooms or areas and master cards for property-wide staff access. In the documented TTLock hotel workflow, a master card is issued to a staff record rather than to an anonymous user. That distinction matters for accountability.
| Certificat | Typical holder | Typical scope | Validity | Control question |
|---|---|---|---|---|
| Guest card | Checked-in guest | Assigned room plus explicitly allowed areas | Check-in to checkout, or a configured stay window | Does checkout or reissue actually stop the old credential? |
| Staff card | Housekeeping, maintenance, supervisor or contractor | Role-based rooms, floors, common areas or restricted doors | Shift, date range or limited-use rule | Can the access shrink when the role, shift or employment changes? |
| Master card | Authorized manager, security or emergency operator | Broad property or configured exception scope | Shortest practical window, with named holder and audit | Does it override privacy, deadbolt, lockout or emergency modes? |
Compare authority on five dimensions
1. Scope. Room, floor, building, public-area and staff-area permissions should be explicit. Dormakaba’s access-management documentation shows that staff keys may include different access-point types depending on the selected credential class, while guest access is formed from the room and areas selected during registration. Treat that as a useful model for specification, not a promise about every platform.
2. Validity. Guest access is usually tied to stay dates. Staff access may use a shift, an end date or a limited number of uses. A master credential should have an identified holder and the shortest validity that still supports the job. A card that is “always valid” is an operational risk even if the lock is working correctly.
3. Override behavior. Never assume “master” means “opens through every privacy or deadbolt state.” Some hotel-lock systems define separate emergency, master, floor or lockout functions. Ask the vendor to demonstrate the exact behavior on the selected lock and document whether the event is logged.
4. Revocation. The trigger differs by class: checkout for a guest, loss or role change for a staff member, and loss, exposure or policy breach for a master credential. In TTLock’s documented hotel workflow, a lost card can be marked and disabled, and the page says a disabled card cannot be enabled again. Other offline systems may require a replacement or stop-access card to be presented to each affected lock.
5. Auditability. Ask whether the system records card type, holder, issuer, encoder, creation time, validity, status, room/floor access and the door events associated with the credential. Dormakaba documentation exposes these fields as examples of what can be read from a key and used in access reports. The field names and retention limits still need model-specific confirmation.
The real security test is the card lifecycle
Initial issue is the easy part. The stronger test is whether a front desk or security team can handle the five events below without guessing which locks need an update.
- Issue: record holder, card ID, access points, validity and issuing operator. For a staff card, record the role and the reason for multi-room access.
- Operate: use the card only within its scope. Review access reports for room entries that do not match a shift, assignment or incident.
- Déclencheur : checkout, lost card, room move, role change, contractor end date or suspected master-card exposure.
- Revoke: disable, replace, cancel or re-key according to the system’s documented workflow. Do not treat “we issued a new card” as proof that the old one stopped working.
- Verify and review: test an affected door, confirm the old credential’s status, preserve the relevant audit record and escalate unresolved access to the responsible security or system owner.
Hotel key-control guidance also recommends tracking issued credentials, reviewing access when an employee changes role, terminating staff access promptly and using audit trails during investigations. These are operational controls; local privacy, employment, life-safety and data-retention requirements still need separate review.
Use this checklist before choosing hotel lock software
Send the following questions to the lock vendor or integrator before sampling. If an answer is “not supported,” you have found a system boundary—not a detail to solve after installation.
- Permission map: list guest rooms, staff rooms, floors, buildings, elevators, public areas and restricted doors; mark which role needs each one.
- Time rules: define guest check-in/out, housekeeping shifts, contractor end dates, limited-use staff access and master-card expiry.
- Privacy and emergency: test privacy latch, deadbolt, lockout and emergency behavior on the exact lock model; record which credentials can override each state.
- Lost-card response: document the action for a guest card, staff card and master card separately, including offline locks and doors that must be updated individually.
- Audit fields: confirm whether the system can export card ID, holder, issuer, encoder, timestamp, validity, door and access result; ask how long the record is retained.
- System boundary: confirm what the hotel PMS does, what the hotel-lock software does, and whether an encoder, gateway or local update step is required.
- Project fit: provide door material, thickness, mortise/cutout data, room count, staff/common-area door count and renovation status before the hardware recommendation.
For the component-level view that follows this permission decision, see the hotel door lock system components and card workflow. For replacement projects, use the separate hotel door lock project compatibility checks to organize door and software questions.
Foire aux questions
Can a front-desk employee use a master card?
Only if the hotel’s policy and selected system explicitly assign that authority. A front-desk role usually needs to issue guest cards, not carry property-wide access. If a system requires a master credential for card issuance, separate the encoder authorization role from a card that opens every guest-room lock.
Does issuing a new guest card automatically cancel the old one?
Not universally. Some systems invalidate or disable an old card through software or a replacement-card workflow; offline systems may require the affected lock to read new cancellation data. Ask for a live demonstration of the lost-card and reissue path, including a room whose lock is temporarily offline.
Should a staff card show the rooms it can open?
It should be identifiable to the operator, but printing a room number on a credential can expose its target if the card is lost. A safer record is a unique card identifier linked in the management system to the holder, role, validity and access scope. The exact card-printing policy belongs in the hotel’s security procedure.
Conclusion
In a hotel lock system, the practical difference is the permission boundary: guest cards are assignment-based, staff cards are role- and area-based, and master cards are broad exception credentials. The winning configuration is not the one with the most card types; it is the one that makes scope, time, override, revocation and audit behavior testable.
Before sampling, prepare the role map, door groups, validity rules, privacy/deadbolt policy, lost-card response and audit fields. Then request a model-specific permission review that returns a documented credential matrix and a list of unresolved software, encoder, PMS and door-compatibility checks.