Encoding a credential: blank stock, pre encoded, and who holds the keys

Printing a card is a printing problem. Encoding one is a security problem, and the two get quoted together as though they were the same kind of work.

The question underneath almost every encoding conversation is not technical. It is who writes the data, and therefore who has to hold the keys. The file formats, the UID lists and the carton order all follow from that one answer.

Getting it wrong is expensive in a particular way. A printing error is visible, and it is caught in a proof. An encoding error is invisible: the cards look perfect, they read at the encoder, and they fail on a door three weeks later when the first guest tries one. By then the whole batch is in the building.

This guide sets out the three routes, what a factory legitimately needs in order to take the middle one, and what a factory should never be asking for. It is written for whoever signs off the arrangement: an integrator, a distributor or a programme owner.

01. What encoding actually is

A chip arrives from its own manufacturer with a factory programmed UID and, beyond that, either an empty memory or a default structure. Encoding is the step that turns that into a credential your system recognises. It covers three separate jobs, and confusing them is where most of the trouble starts.

Writing the data

Putting bytes in the right place. A room number, a member identifier, a URL, a stored value. On a sector based chip that means specific blocks. On a file based chip such as DESFire it means creating an application and files inside it. Which chip you are working with decides the shape of this entirely.

Setting the keys

Replacing factory default keys with yours, and setting the access conditions that say which key is needed to read or write each part of the memory. This is the part that makes a credential a credential rather than a number.

Locking it down

Setting one time programmable bits, disabling write access, or moving a chip into a secure mode. Some of this is irreversible, which is exactly why it is worth being precise before a full run.

The three are often quoted as one line on a purchase order, and that is where ambiguity creeps in. A supplier who says a card is encoded may mean only the first, which leaves the chip on default keys and, from a security point of view, effectively open. Ask which of the three a quote covers.

Encoding is not a finish

Lamination, print and die cutting are finishes: they happen to the card. Encoding happens to the credential, and it can be wrong in ways that a visual inspection will never catch.

02. The three routes

Every card gets its data in one of three places, and the choice is really a choice about where your keys are allowed to exist.

Blank stock, encoded on site

The factory supplies cards with the correct chip, printed and finished, and writes nothing. Your own encoder does the rest at issuance. This is what most access control estates do, and for a guest room system it is almost always right. Keys never leave the property.

Factory encoded

The factory writes the data and ships cards that are ready to issue, with a list matching each card to its UID. This saves real labour on a large rollout, and it moves the key question onto the table: the factory now has to be able to authenticate to the chip, which means holding key material you supplied.

Hybrid

The factory writes the part that never changes, a serial, an NDEF record pointing at a URL, a manufacturer block, and your system adds the access rights on top. This is the usual answer for membership and loyalty programmes, where the card has a fixed identity and a mutable balance.

One practical note on choosing between them. The labour saved by route 02 scales with quantity and the risk does not, so it is worth doing on a fifty thousand unit rollout and rarely worth doing on two thousand. If the cards are going to be issued one at a time at a desk anyway, the encoder is already there and route 01 costs nothing extra.

03. Keys belong to whoever carries the risk

A key is not a setting. It is the thing that decides whether a copied card opens a door, and it is the only part of the whole chain that cannot be regenerated after the fact.

The operator of the system carries the consequence of a compromise, so the operator should hold the keys. A manufacturer that pushes to hold them permanently, or that wants a copy of a working card to read them out, is asking for a shortcut that costs you the thing you are paying for.

Where keys do have to be transmitted for a pre encoded run, three things make it survivable. Use a channel your own security people are comfortable with rather than an email attachment. Use keys diversified per card from a master you keep, so that what the factory holds is not the master itself. And rotate afterwards where the system allows it.

Diversification is the one worth insisting on and the one most often skipped. With diversified keys, each card's key is derived from a master and that card's UID, so a key recovered from one card unlocks exactly one card. Without it, a single key opens every credential in the estate, and it is sitting in an email somewhere. Most modern platforms support diversification; the question is whether it was switched on.

The question to ask

Not can you encode this, but what will you hold after the order ships, and for how long. A supplier with a clear answer has thought about it. A supplier who has never been asked has not.

04. What a factory needs, and what it should never ask for

There is a short list of things that make pre encoding possible, and a shorter list of things that should end the conversation.

On the data itself, send a file with a stated schema rather than a description. One row per card, a header line, the fields named, the encoding stated. A spreadsheet that a human can read and a script cannot parse is the single most common reason an encoding job slips a week.

The right hand column deserves one more sentence, because a request from that list is not always bad faith. Sometimes a factory asks for a working card because nobody has given it a memory map and it is trying to be helpful. The answer is the same either way: get the map from whoever owns the system. A specification reverse engineered from one sample card is a guess that will hold until the first card that differs.

05. The UID list, and why carton order matters

Every pre encoded order should come back with a list that maps each card to its chip UID. That part is standard. What is not standard, and what you should insist on, is that the list is in the physical order the cards were packed.

A list in carton order lets your team check a box by reading the first and last card in it. A list in an arbitrary order turns activation into a card by card search, which on twenty thousand units is a week of somebody's life.

State the format too. A CSV with the UID in hexadecimal, uppercase, no separators, plus your own serial and the carton number, will be read correctly by every system we have ever seen. Anything else needs agreeing in advance.

06. The magnetic stripe case

Stripe encoding is the same conversation with older vocabulary. What matters is which of the three tracks is written, in what format, and at what coercivity. Getting the track and the coercivity right matters as much as the chip does on a system that still runs stripes, and the two can sit on the same card.

One difference is worth knowing: a stripe has no keys and no authentication at all. Anything written to it can be read and rewritten by any encoder, which is why a stripe is an identifier rather than a credential. Where a card carries both, the security lives in the chip and the stripe is there for the older half of the estate.

07. What should arrive with the order

Four documents, and all four should be agreed at the quote rather than chased after delivery.

08. What goes wrong

The data file and the card order do not agree

Almost always a sorting problem rather than an encoding problem. Fixed by agreeing that the file is written in production sequence and the cartons are labelled with ranges.

The chip was right and the memory map was not

The cards read at the encoder and fail on the doors. This is the same failure mode as an AES upgrade on a Visionline estate, and it is caught the same way, by testing an encoded card on real doors before the full run.

Batch two behaves differently from batch one

The encoding parameters were not written down. Keeping the second order identical to the first is a documentation problem more than a manufacturing one.

The cards were locked further than anybody intended

Irreversible settings applied because a default was left in place. There is no recovery from this: a chip put into a locked state cannot be put back, and the batch is scrap. It is the reason a pre encoded run should always be preceded by a small sample that is tested and, where possible, deliberately re read after a week in service.

09. How we handle it

We manufacture for the trade and do not sell to your customers. Most of what leaves our line is blank stock of the correct type, because most partners encode with their own system and their own keys, and that is usually the better arrangement.

Where a partner wants a pre encoded run, we ask for the five things in the list above and nothing else, we return a UID list in carton order with an encoding record naming the chip and the parameters, and encoding happens on the same floor as the printing and the lamination. Minimum order is 500 units, standard production thirteen calendar days from artwork approval to dispatch, and quotes come back the same working day. The rest of the commercial detail sits on the FAQ.

10. Frequently asked questions

Can you encode without holding our keys?

For anything that only writes to freely accessible memory, yes. For anything that authenticates, no: writing into a protected area requires the key for that area. That is not a policy, it is how the chip works.

Is a UID enough to identify a card?

To identify it, yes. To authenticate it, no. UIDs are readable by anyone and cards with writable UIDs exist, so a system that grants access on UID alone is effectively unencrypted whatever chip it uses.

Can you encode cards we already have?

Sometimes, but it is rarely worth the freight. If the chip is right and the memory is still writable it is possible. If the chip was locked at the last encoding, it is not.

What happens to the key material after the order?

Ask every supplier this and get the answer in writing. Ours is that key material supplied for a run is used for that run and is not retained afterwards, and that is written into the order rather than implied.

Do wooden and PET cards encode the same way?

Yes. The body material changes the lamination and the artwork, not the chip or the encoding. What each card body does and does not change is covered separately.

Can fobs and wristbands be pre encoded too?

Yes, and the same three routes apply unchanged. The body makes no difference to the decision; fobs and wristbands carry the same chips as cards.

Can a card be encoded with a URL that a phone reads?

Yes, as an NDEF record on an NFC chip such as NTAG or DESFire. That is freely readable data and needs no key material, which makes it one of the few things a factory can write with nothing sensitive changing hands.

How do we test a pre encoded batch without opening every carton?

Read the first and last card of each carton and check them against the UID list, then present a handful to real doors. That catches a sorting error, a carton mislabelled and a memory map problem, which between them account for almost every failure worth catching.