Your team has finally signed off on the chip. Then the factory replies with one line: “Please confirm the key set — or shall we encode with ours?” A purchasing decision has just become a security decision, and nobody wants to own it. Get it wrong in one direction and you hand an outside supplier the permanent ability to produce cards that open your doors; get it wrong in the other and you take delivery of 50,000 cards your readers cannot authenticate. This guide covers the part of smart card key management that buyers actually have to decide: who generates the keys, how they are diversified, where they are stored, how they reach the factory safely, and what belongs in the contract before the purchase order goes out.
Why Key Management, Not Chip Choice, Decides Whether Your Card Program Is Secure
Buying an AES-capable chip does not buy you security. It buys you the capability to be secure. Chips such as MIFARE DESFire arrive from the silicon vendor with factory default keys — frequently all zeros — and remain in that state until someone deliberately personalises them. A card that still holds default keys offers no more protection than an unencrypted card, because any commodity reader or phone app can authenticate against a key everyone knows.
The mirror-image failure is even more common in the field, and it is usually invisible on the invoice: readers configured to accept the card serial number only. If your access system authorises people by UID or CSN, the cryptography on the card is never invoked, and you have paid a premium for a credential that behaves like a 1990s proximity card. Cloning it takes a cheap emulator. Before you argue about key custody, confirm what your reader and controller actually verify — the same discipline we cover in the MIFARE Classic to DESFire migration playbook. For facility access programmes, NIST’s SP 800-116 Rev. 1 guidance on using credentials for physical access is the clearest statement of why authentication — not identifier reading — is the control that matters.
Who Generates the Keys? Three Custody Models and Their Real Trade-offs
There are only three practical answers, and each one moves risk to a different place. Choosing consciously is what separates a defensible programme from one that simply happened.
Model 1 — Supplier-generated keys. The factory creates the key set and encodes your cards. Fastest to launch and the least work for your team, but it means a third party holds material capable of producing valid credentials for your buildings. It also creates commercial lock-in: your next order has to come from whoever holds the keys. Before accepting this model, ask one direct question: is this key set unique to us, or shared across your other customers? A supplier who cannot answer in writing has answered.
Model 2 — Customer-generated keys, transferred to the supplier. You generate keys in your own environment and deliver them under controlled conditions so the factory can encode production cards. You keep ownership and can re-source later; in exchange you must run a real key transfer process (see below) and keep a secure backup.
Model 3 — Transport key, then in-house re-keying. The factory ships cards personalised with a temporary transport key; your issuance station replaces it with production keys as each card is issued. This gives the strongest separation — no production key ever leaves your premises — but it requires encoding capability, trained staff and a card that is useless to anyone who intercepts the shipment. It is the model most often chosen by government and large enterprise programmes, and it pairs naturally with the workflow in our guide to building an ID card issuance programme.
| Model | Who holds production keys | Buyer effort | Main risk | Best fit |
|---|---|---|---|---|
| Supplier-generated | Factory (and possibly you) | Lowest | Third-party can produce valid cards; vendor lock-in | Small pilots, low-consequence sites |
| Customer-generated, transferred | You, copy at factory for the run | Medium | Transfer and storage mistakes | Most enterprise programmes |
| Transport key + in-house re-key | You only | Highest | Needs issuance hardware and process discipline | Government, banking, critical infrastructure |
Key Diversification: One Master Key Across the Fleet Is a Single Point of Failure
If every card in your programme carries the same application key, then extracting that key from one lost card compromises every card you have ever issued. Key diversification removes that failure mode by giving each card its own key, mathematically derived from a master key plus a card-unique value such as the chip UID. Readers or secure access modules perform the same derivation at transaction time, so the system still works with a single master secret while no two cards share a key.
Two practical points buyers miss. First, “diversified keys” in a quotation is not a specification — the derivation method must be named and documented, because your readers must reproduce it exactly. A card diversified one way and a reader expecting another will fail authentication in the field, not in the lab. Second, diversification does not remove the need for a key lifecycle: crypto periods, planned rotation and retirement all still apply, and NIST’s SP 800-57 Part 1 Rev. 5, Recommendation for Key Management remains the reference most auditors recognise. Write the derivation method into the encoding specification alongside the rest of your card encoding requirements, and keep the physical and RF requirements of ISO/IEC 14443-1:2018 in the same document so nothing is negotiated verbally.
Where Master Keys Should Live: SAM Modules, HSMs, and Places They Never Should
A key is only as protected as its worst copy. Two pieces of hardware do the heavy lifting in card programmes. A secure access module (SAM) sits inside the reader or encoder and performs authentication internally, so master keys are never present in host software, configuration files or integrator laptops. A hardware security module (HSM) is where central key generation, wrapping and backup belong; when a tender requires evidence, ask for a module validated under the NIST Cryptographic Module Validation Program rather than a vendor claim of “bank-grade encryption”.
If your cards carry more than one application — access plus payment plus logical logon — key ownership has to be separated per application, not pooled. GlobalPlatform specifications define the security domains and key sets that make this separation enforceable on the card itself, which is the mechanism behind the isolation described in our guide to multi-application smart cards.
The list of places keys must never appear is short and routinely violated: spreadsheets, email attachments, ticketing systems, chat messages, shared drives, and a single unencrypted USB stick in a project manager’s drawer. Equally important is the failure nobody plans for — if you lose your master keys, cards already locked to them cannot be re-authenticated or re-keyed, and the only remedy is replacing the fleet. Keep an offline backup under dual control, held by two named custodians who cannot access it alone.
How to Transfer Keys to Your Card Supplier Without Emailing Them
If you choose Model 2, the transfer itself becomes the weakest link, so treat it as a controlled procedure rather than a file hand-off. A workable process for a commercial programme looks like this:
- Split the key into components. Two or three components, each held by a different custodian and sent through a different channel, so no single person or interception yields the key.
- Use dual control and witness the ceremony. Two authorised people present, an entry in a log, and a signed record of who handled what and when — this is the evidence your auditor will ask for.
- Verify with a key check value (KCV). Both sides compute a short check value from the loaded key and compare it. A matching KCV proves you and the factory hold the identical key without either party revealing it.
- Or wrap the key cryptographically. Key encryption keys and asymmetric key transport mechanisms — the mechanisms standardised in ISO/IEC 11770-3:2021, Key management using asymmetric techniques — let you deliver key material over ordinary channels safely.
- Keep pilot keys separate from production keys. Samples, engineering builds and trade-show demos get their own throwaway key set. Never send production keys for a sample run, because sample cards travel loosely and rarely come back.
- Require destruction after the run. A written key destruction confirmation from the supplier once the batch ships, with a stated deadline, closes the loop.
What to Put in the RFQ and the Contract
Most key management incidents in card programmes are contractual gaps, not cryptographic breaks. Copy the following into your enquiry and you will get comparable answers from every supplier — and quietly filter out the ones improvising:
- Custody model required: supplier-generated, customer-supplied, or transport key with in-house re-keying.
- Named derivation method for diversified keys, documented and reproducible by our readers.
- Written confirmation that no key set is shared with any other customer.
- Named key custodians on both sides, with dual control for loading and backup.
- KCV exchange and verification before the production run, repeated on first-article samples.
- Key storage limited to SAM or validated HSM; no key material in general-purpose IT systems.
- Encoding must not be subcontracted without prior written approval.
- Read-back verification report for 100% of encoded cards, delivered with each batch.
- Key destruction certificate within a defined number of days after final shipment.
- Crypto period and re-key path agreed at the start, not after the first incident.
One more commercial note. Key custody is a legitimate reason to care whether you are buying from the manufacturer or from an intermediary, because every additional party in the chain is another place your key material can be copied — a point we examine in factory-direct versus reseller sourcing. If you are still deciding which interface your credential should use, settle that first with our comparison of RFID, NFC and BLE interfaces for cards; key strategy follows the technology choice, not the other way round.
Frequently Asked Questions
Should we let the card factory generate our keys?
For a small pilot or a low-consequence site, it is a reasonable trade for speed. For anything protecting people, cash or regulated data, generate your own keys or use a transport key and re-key in house. If you do accept supplier-generated keys, insist in writing that the key set is unique to your organisation and that it will be destroyed on request.
What exactly is key diversification, and do we need it?
It is the derivation of a unique per-card key from a master key plus a card-specific value such as the UID. You need it whenever losing a single card must not endanger the rest of the fleet — which is nearly always. The cost at production is negligible; the cost of retrofitting it later is a full card reissue.
Can we change keys after cards are already issued?
Yes, provided you still hold the current keys — a card will only accept a key change from a party that can authenticate first. Practically, that means each card must pass an encoder or a suitably configured reader, so plan a rotation campaign with staffing and a deadline rather than assuming it can be done over the air.
What happens if we lose our master keys?
Cards locked to those keys can no longer be authenticated or re-keyed, and replacement is usually the only route. This is why an offline backup under dual custody is not optional, and why key custodians should be named roles rather than a single individual who may change jobs.
Do we still need key management if our readers only read the card serial number?
In that configuration you have no cryptographic protection at all, so key management is not your first problem — reader configuration is. Fix the reader and controller settings so that mutual authentication is actually performed, then apply the key model above. Buying secure cards for a system that ignores their security is the most expensive way to stay vulnerable.
Your Next Step
Decide the custody model before you request pricing — it changes lead time, unit cost and the amount of process your team has to run. If you want a second opinion on the model that fits your programme, or a sample set encoded with throwaway pilot keys so your readers can be tested before you commit, send us your reader model and volume and we will come back with an encoding specification you can put straight into an RFQ.
