AES-Secure HF Wristbands for Hotel Locks

A technology name is not a specification

High frequency at 13.56 MHz covers a wide range of credential types with different memory structures, different security models and different ways of being addressed. Two credentials can both be accurate to that description and be completely unusable in each other’s place.

So when an enquiry says a property needs secure high-frequency wristbands, that is the start of the question rather than the answer. What the locks are configured to accept, how credentials are currently issued, and whether the property or its integrator holds the keys are what actually determine what can be produced.

Start from what is already installed

The most reliable input is an existing credential that already works. It carries the answer physically: the technology, the memory layout and often the numbering convention. A property that can send one, or read one at the desk and share what the system reports, has removed most of the uncertainty in a single step.

The second most reliable input is the lock system’s own documentation about which credential types it is configured for. Not which types it supports in general — which types this installation is set up to accept, which is frequently a narrower list.

What resolves a credential question quickly:

• An existing working credential, or what the property’s system reports when it reads one
• The lock system’s configured credential type for this installation, not the product range
• Who currently encodes credentials — the property, an integrator, or the lock supplier
• Whether new credentials must join an existing numbering range or start a new one

Encoding is a separate question from supply

Supplying a credential and encoding it are different acts. Many properties encode on site as part of check-in, which means what they need from us is unencoded stock of the right type. Others need credentials delivered pre-encoded to a defined range, which requires the encoding input to be agreed and transferred securely before production.

Where security keys are involved, they belong to the property or its integrator and are handled under their process, not casually over email. A supplier that is relaxed about that is a supplier to be careful with.

Why we will not promise universal compatibility

It is possible to write a sentence that implies any credential will work with any lock. It is not possible to make it true. Installed systems differ by site, by configuration and by age, and a wristband that works at one property with the same lock brand can fail at another.

What we do instead is confirm before production and say so plainly on every page. That is slower to read than a promise and considerably faster than discovering the problem after 2,000 pieces have been made.

What a wearable adds to the question

A wristband is a credential in a physically awkward package: smaller antenna area than a card, worn against a body that detunes it slightly, presented at an angle a card never is. All of that is manageable, and none of it is visible in a specification document.

The consequence is that a wearable needs to be proven at the actual doors rather than approved on paper. The same credential type in card form may behave perfectly while a compact band is marginal at a recessed reader — which is a reason to test, not a reason to avoid wearables.