VingCard AES Guest Card Lifecycle: Issue, Revoke & Re-Issue

A VingCard AES guest card is issued at check-in when a front-desk or mobile encoder writes the guest's dated access rights onto the card under its AES keys. The encoding names which doors the card may open — the guest room, plus any common areas such as the pool, gym, or elevator floor — and the exact check-in and checkout window during which those rights are valid. The Signature RFID lock then validates that data cryptographically at the door.

This is the AES-secured 13.56 MHz guest credential VingCard adopted in 2024. For the full security model behind the card — 128-bit AES mutual authentication, the message authentication code on every command, and Common Criteria EAL3+ certification — see the VingCard AES memory card explainer. This page focuses on how that credential behaves operationally across its lifecycle.

At checkout a VingCard AES guest card simply stops working: its access rights were written with a fixed expiry, so once the checkout time passes the Signature lock no longer honours them. The property does not need to physically collect and wipe every card for it to become useless at the door — the dated rights and the lock's own clock enforce expiry. Guests can therefore keep, discard, or return the card.

Where a card must be cancelled early — an unexpected early departure or a security concern — the property re-issues the room, which invalidates the prior key. Because issuance and revocation are handled centrally in Visionline or Vostio, cancelling a key does not require a visit to the lock.

VingCard AES guest cards are re-encodable, so a returned card can be written with a new guest's rights for the next stay rather than discarded. Properties that collect cards at checkout run them back through the encoder, which overwrites the previous access data under fresh keys. This reuse is central to why VingCard framed its 2024 AES announcement around sustainability alongside security and scalability.

If a guest loses a VingCard AES card, the property re-issues the room key, and the act of issuing a new key invalidates the lost one. Because the credential carries dated, cryptographically validated rights rather than a static number, the replacement supersedes the previous card at the lock — the lost card no longer opens the door once the new key is presented or the room is re-encoded, depending on the system's setting.

This central revocation is a core advantage over legacy hotel keys. A lost 125 kHz proximity card broadcasts a fixed number that cannot be selectively disabled without re-keying, whereas a VingCard AES key is managed by Visionline or Vostio and can be replaced in seconds at the front desk.

Key rotation on VingCard AES cards is managed by the property's back end, which holds the site-specific AES keys used to diversify each card's own keys. Because every card is encoded with keys derived per credential, the security of the estate depends on protecting those site keys — not on any single card. When keys are rotated or a property is re-keyed, newly issued cards use the updated keys while the software governs the transition.

The practical takeaway for operators is that credential security lives in key management, not in the plastic. A VingCard AES deployment stays strong when the site keys are held securely in Visionline or Vostio and locks are kept current; the AES card is simply the carrier that presents diversified, cryptographically authenticated rights at the door.

Across its lifecycle a VingCard AES guest card protects its access rights with 128-bit AES mutual authentication and a CMAC on every exchange, so the rights are not exposed as a plain readable serial at any normal read — check-in, unlock, or return. Reproducing the credential would require the site-specific diversified keys held in the property's system, not merely a blank card and a reader.

The honest framing is that clone-resistance depends on key management throughout the card's life. Where a property still circulates legacy, unencrypted guest cards on unconverted doors, those specific keys carry the older, readable-serial risk. Moving the guest-card lifecycle onto the AES credential — issued, expired, and re-issued centrally — is what closes that gap operationally.