ACCESS CONTROL
9 DECEMBER 2025
Every RFID wristband carries a chip, but a chip on its own does not open a gate. What makes it work is the link between that chip and your access control or cashless system: how the system recognises the band, what it reads, and what it does with the answer. That link is the encoding, and it is the part of a wristband order that most often gets agreed too late, usually by email, in the final week before the event.
This guide explains what encoding means in practice, from the unique ID every chip already has to the data a system can write into its memory, the printed numbers and codes that match the chip, and the security keys some systems use. It ends with the short list of information your supplier needs so that the wristbands arrive ready to read on the first day, not after a round of fixes.
What encoding actually means
Encoding is a broad word for everything that is done to a chip, or recorded about it, before the wristband reaches your gate. In the simplest case nothing is written at all: the system only reads the chip's serial number and checks it against a list. In more complex cases, data is written into the chip's memory, some of that memory is locked, and the printed side of the band carries numbers or codes that match what is stored inside. Knowing which of these cases applies to your event is the first step, because each one changes what has to be agreed before production starts.
Which approach you need is decided by your system, not by the wristband. Two access control providers can use the same chip in completely different ways, and a band encoded for one may be unreadable, or simply meaningless, to the other. That is why the first question we ask about encoding is not technical at all. It is the name of your system provider and the person on their side who can confirm what their readers expect. If you are working with an agency or a ticketing partner, they may already have this contact, so ask them before anything is ordered.
It also helps to separate encoding from the choice of chip. The chip decides what is possible: its frequency, how much memory it has and what security it supports. The encoding decides how that capacity is used for your event. Getting the chip right and the encoding wrong is a common way to end up with bands that read perfectly on a test reader and then fail on the real gates. Treat them as two separate approvals: one for the chip reference and one for the way it is encoded, each confirmed by the system provider.
The UID: the number every chip already has
Every chip leaves the factory with a unique identifier, usually called the UID. On standard chips it is fixed and cannot be changed, which makes it a reliable way to tell one wristband from another. Many access systems work only with the UID: they import a list of the UIDs in your order, link each one to a ticket type or a person, and check that list whenever a band is presented at a reader. Because the check happens in the system, a band can be blocked or reassigned at any time without touching the chip itself.
Because the UID is set before the band is made, nothing needs to be written to make this approach work. What matters is the list. The system needs every UID in the order, in a format it can import, and often linked to something printed on the band, such as a sequential number. Without that link, finding a specific wristband on site means scanning it, which is slow when you are trying to replace a lost band at a busy desk. Ask your provider how many UIDs their system can import at once and whether it expects one file per access level or a single list.
This is where UID mapping comes in. We can supply the UIDs of your wristbands matched to the numbering printed on each one, so your team can look up a band by the number they can see, and your system can import the full list before the event. Agree the file format with your provider first. A spreadsheet with the wrong column order or byte format is a small problem that becomes a large one at midnight before opening day. Agreeing a short example of the file layout with your provider before the full list is prepared avoids surprises at import.
Writing data to the chip
Some systems need more than the UID. They write data into the chip's memory, such as a ticket number, an access level, a validity period or a customer reference, and the reader checks that data at the gate. Cashless systems may also store information that changes during the event. Whether this is needed, and exactly what is written where, is defined by the system provider, who should give you a written specification. Ask for that specification before you confirm the chip, because the amount of data and the security it needs can rule some chips out.
Data can be written before the wristbands leave production or by the organiser's team on site, for example at accreditation desks. Writing in advance saves time at the event and means the bands arrive ready to use, but it requires the data to be final earlier. Writing on site is more flexible but needs equipment, staff and time. Many events combine both: general admission bands arrive pre-encoded, while staff and guest bands are completed at a desk. If you plan to write on site, test the desk process with real staff and real bands before the doors open, not only with a demo kit.
If data is written in advance, parts of the memory can usually be locked so they cannot be changed afterwards. Locking protects the data from accidental or deliberate rewriting, but it is permanent on most chips, so it has to match the system's needs exactly. Before anything is locked, the encoding should be confirmed on a sample, read on the system's own hardware and signed off by the provider. A mistake in a locked field cannot be fixed later, so the sign off deserves a careful second look from your provider.
Chip families and what they can hold
Chips differ in how much they can store and how they protect it. At HF 13.56 MHz, NTAG 213, 215 and 216 offer 144, 504 and 888 bytes of user memory and can be read by most NFC phones. MIFARE Classic and Ultralight are long established in access control, while DESFire EV1, EV2 and EV3 add stronger, key-based security for systems that need it. ICODE SLIX and SLIX2 also work at this frequency. The right choice depends on what your system reads and writes, so the chip is best confirmed by your provider rather than chosen from a list.
At LF 125 kHz, chips such as EM4200 and TK4100 carry a read-only ID, which suits simple access systems that only check the number. T5577 can be written, and some systems use it to emulate other LF formats. At UHF 860 to 960 MHz, chips such as Impinj Monza and U-CODE GEN2 follow the EPC Gen2 standard and can be read at greater distances, which suits flow counting and gates where people should not have to stop. Readers built for one frequency will not read chips from another, which is why the frequency is the first thing to confirm with your system provider.
The chip families available for each wristband are listed on its product page, and not every chip is offered in every format. Silicone watch-strap bands, for example, are available with LF and HF chips. If your provider names a specific chip reference, send it to us exactly as written. Small differences in the reference can mean a different memory size or security level, and the right answer is always the one your readers have been tested with. When in doubt, forwarding the relevant page of your provider's documentation is often the quickest way to avoid a mix up.
Printed data that matches the chip
Much of what is called encoding happens on the outside of the band. Sequential numbering, barcodes and QR codes are printed so that staff and systems can identify a wristband without a reader, or so that a second system, such as a scanner app, can work alongside RFID. When printed data and chip data refer to the same record, they need to be produced together, from one list, so that each band carries the right pair. Mixing lists from different sources is one of the most common reasons a printed number and a chip end up describing different people.
A common setup prints a short sequential number on each band and supplies a file linking every number to its chip UID. Another prints a QR code that encodes a ticket reference, while the chip carries the same reference or the UID linked to it. Either way, the source list needs to be agreed and frozen before production. Changing it afterwards means reprinting, and the bands already produced cannot be corrected one by one. Keep a copy of the final list with a clear version name, so everyone refers to the same file when questions come up during the event.
Think about legibility as much as data. A number printed in a tiny font on a curved band is hard to read under poor light, and a QR code that is too small or printed on a reflective surface will scan slowly. Each material has its own printable area, so check the space early. If a code has to be scanned at the gate, ask for it to be tested on a sample with the scanners you will actually use. Contrast matters too: dark codes on a light background usually scan more reliably than light codes on a dark band.
Security and keys
Some chips protect their memory with keys. MIFARE Classic uses keys per sector, and DESFire uses keys per application and file. Systems that rely on them will ask for data to be written with their keys, or will write it themselves after delivery. Keys are your provider's responsibility and should be shared only as they instruct, through a secure channel, and only with the people who need them for production. Never send keys in the same email as the artwork or the order details, and agree in advance who will hold them after production.
If your system uses only the UID, keys are not involved, but security still matters. A UID can be read by anyone with a compatible reader, so the protection comes from the system: the list of valid UIDs, the rules at each gate and the way duplicates are flagged. That is a perfectly sound approach for most events, as long as everyone understands where the security sits and does not assume the chip alone provides it. Gate rules such as one entry per band, or an alert when the same UID appears twice, do most of the work in this model.
Whatever the model, plan what happens when a band is lost or damaged. The system should be able to deactivate the original and issue a replacement with a new UID or new data, and your team needs a clear process for doing that quickly. Keeping a small stock of spare bands for each access level, prepared in the same way as the rest of the order, makes replacements far faster on the day. Write the replacement steps on a single page for the desk team, including who can approve a replacement and how it is recorded.
Test the encoding before production
No specification replaces a real test. Once the chip is confirmed, we send a physical sample of the actual wristband within 24 hours by express courier, so your provider can read it on their own hardware. If data is to be written in advance, the sample should carry the same encoding as the final order. If the system writes data itself, the test should show that it can do so reliably on that chip and format. Keep the approved sample after the test, because it becomes the reference if anyone needs to check the production later.
Test the band as it will be worn, not only flat on a desk. Readers mounted on turnstiles or handheld devices behave differently from a desktop reader, and a band on a wrist sits at a different angle and distance. For UHF, the read zone and the number of people passing at once matter as much as the chip. Your provider will know how their hardware should be checked; ask them to confirm the result in writing. Include a few bands fitted on different wrist sizes, because a loose band and a tight band do not always read the same way.
Once the sample is approved, the encoding specification becomes part of the order and is used for every band. Production takes 10 to 12 days after artwork and specifications are approved, plus shipping, so leaving the encoding until the last week compresses everything after it. Confirming it in parallel with the artwork, rather than after, is the simplest way to protect your delivery date. If several parties are involved, such as a ticketing company and a system provider, share the same deadline with all of them from the start.
What to send your supplier
Before production, your supplier needs five things: the chip reference confirmed by your system provider, the encoding method, the data or list to be used if anything is written or printed, the file format for any UID mapping, and the contact at your provider who can approve the sample. With those in hand, the encoding stops being a risk and becomes one more line in the order. Sending them in one message, with your provider in copy, saves several rounds of questions and keeps everyone working from the same information.
You can see the wristband, badge and lanyard options in our catalogue.
If you are still choosing a system, tell us that too. We do not sell access control or cashless systems, so our advice is about the wristband, and we can explain how each option affects the chip and the encoding. Everything is produced white label and pre-encoded to the specification you approve. Knowing your shortlist early lets us point out any chip or format that would limit your options later.
Write to us at hello@accesioid.com, or book a call with Marco using the link at the bottom of this page.
YOU MAY ALSO LIKE