Read an RFID reader datasheet before specifying cards

A reader datasheet narrows the credential options. It does not confirm that a card will work, because supported radio technology and a working application are two different things.

That distinction is where most credential orders go wrong. A datasheet describes what a reader model can do in its best possible configuration. The installation in front of you is one particular unit, running one firmware version, configured for one credential scheme, by somebody who may no longer work there.

This guide is for whoever has to turn a datasheet into a purchase order: an access control integrator, a distributor quoting against a reader model a client has named, or a facilities team replacing credentials on an estate nobody documented.

01. What a datasheet decides, and what it leaves open

A datasheet reliably decides three things: the frequency the reader transmits on, the standards it implements, and the chip families it has been tested against. Everything else about the credential is open.

What it leaves open is the part that fails in the field. A datasheet does not state which of its optional features were licensed on this site, which firmware is loaded on the units already on the doors, how the credential data is laid out, or who holds the keys that protect it. None of that is a flaw in the document: a reader manufacturer cannot know how an integrator configured a building four years ago.

The practical consequence is one rule. A datasheet is enough to produce a shortlist, and never enough to approve a specification.

02. Separate the card interface from the controller interface

Two interfaces appear on the same page, and only one of them describes the card. The card interface faces the credential. The controller interface faces the access panel.

The card interface is the block to order against: frequency, standard, named chip families and read distance. The controller interface carries Wiegand, OSDP or RS-485, the supply voltage, the cable length and the tamper and LED lines. It describes wiring between the reader and the panel behind it, and says nothing about the credential a buyer is about to pay for.

An order placed against OSDP support is an order placed against nothing at all, as far as the card is concerned, and it happens because the controller section is longer and more numerical, so a purchasing team scanning for specifications finds it first.

03. Read the radio line properly

Frequency alone never identifies a credential. 13.56 MHz covers two unrelated standards and several chip families that cannot substitute for each other.

ISO/IEC 14443 and ISO/IEC 15693 both operate at 13.56 MHz and are different protocols. A reader built for ISO/IEC 14443 Type A will not necessarily read an ICODE card running ISO/IEC 15693, so a datasheet line that says only 13.56 MHz has not answered the question. The radio interface itself is defined in part 2 of ISO/IEC 14443, currently the 2020 edition.

At 125 kHz there is no equivalent single standard. EM4200, TK4100 and HITAG are proprietary schemes that present a number and offer no key management, which is why an estate migrating away from them is migrating for security reasons rather than for range. The physical consequences of antenna size and mounting surface are a separate subject, covered in the guide to antennas and read range.

04. Named chip families are a shortlist, not a guarantee

A list of chip names on a datasheet is a shortlist of what the reader can talk to. It is not a list of what the installation will accept.

NXP groups its contactless families as MIFARE Classic, MIFARE Plus, MIFARE DESFire, MIFARE Ultralight, MIFARE DUOX, NTAG and ICODE, and most access control datasheets name several of them. A reader that lists MIFARE Classic and MIFARE DESFire can physically communicate with both. Whether the site will admit a DESFire card depends on how the system was set up, not on the reader.

Choosing between the families is a decision about security level, memory and migration path, covered on its own in the guide to choosing between MIFARE Classic, Ultralight, Plus and DESFire. For reading a datasheet, one point is enough: a chip family in the supported list is a candidate, and it becomes a specification only after the application gap is closed.

05. The application gap

The gap between a supported chip and a working card is the application: the data layout, the keys, the licence and the firmware. This is the single largest source of rejected credential orders.

Four questions close it, and all four are answered by the system owner rather than by the datasheet. Which firmware version is loaded on the readers already installed, because an optional feature may require a version the site has not taken. Which credential application is active, because a reader able to run several will be running one. Which keys protect the data, and whether the platform will release them. And whether the feature named in the datasheet was actually licensed, since several platforms gate protocol support behind a paid option.

A hotel estate shows how far apart the two documents can sit. A datasheet may confirm ISO/IEC 14443 Type A support while the property runs AES protected keys, which is handled in the guide to AES encryption and hotel key card compatibility. Which of the three encoding routes applies, blank stock, factory encoded or site encoded, follows from the key answer and is set out in the encoding guide. For properties, what actually decides whether the door opens starts from the lock rather than from the reader.

06. The Kaway reader extract

The Kaway reader extract is a five line summary of the installed state, approved in writing by the integrator, that a quotation can be written against. It exists because a purchasing team cannot act on a forty page datasheet, or infer a configuration from a list of optional features.

The five lines are the reader model, the firmware version, the card protocol in use, the active credential application, and the document version with its date. The full datasheet is attached as evidence behind it. The version number is what makes it possible to say later which state was approved, the same discipline that governs a card order generally, as described in the guide to specifying an order.

Having the integrator sign it changes who carries the risk. An unsigned extract is a buyer's interpretation of a manufacturer's document; a signed one is a statement by the person who configured the system.

The extract is then tested rather than trusted. A sample credential goes through enrolment, an access attempt at a real door, and revocation, in that order. Revocation is the test most often skipped and the one that matters most, because a credential that opens a door but cannot be withdrawn is a security problem rather than a procurement problem.

07. Buyer checklist

Before approval

• Reader model, exactly as it appears on the unit rather than on the quotation.
• Firmware version, read from an installed reader, not from the latest release notes.
• Card protocol in use, naming the standard and not only the frequency.
• Active credential application, and who holds the keys that protect it.
• Licensed options, confirmed separately from supported options.
• End to end sample test: enrolment, access at a door, revocation.
• Document version and date on the extract the order is placed against.

Six of the seven can be answered in one email to the integrator. The sample test is the one that cannot be shortened, because it is the only step that converts a document into evidence.

08. Worked example

Illustrative scenario, not a Kaway case study. Two buildings on the same campus use the same reader housing, bought in the same year from the same supplier, with the same datasheet in the file.

The first building was commissioned with a firmware version that enables a protected credential application, and the integrator encoded the cards under keys the client holds. The second was commissioned eighteen months later by a different installer, who left the readers on the shipped firmware and used the card serial number alone.

A credential approved at the first building is therefore a candidate at the second, not a proven compatible card. The datasheet is identical in both cases and tells nobody that. Ordering one batch for both sites on the strength of the shared datasheet produces cards that work at one door and are rejected at the other, after delivery.

09. Technical references

• ISO/IEC 14443-2, the radio frequency power and signal interface for contactless proximity objects, which is the standard behind the 13.56 MHz line on a reader datasheet and the reason frequency alone does not identify a card: iso.org/standard/73597.html.
• NXP, the MIFARE product families, which is where the chip names that appear in a reader's supported list are defined by their manufacturer: nxp.com/products/rfid-nfc/mifare-hf:MC_53422.

10. Where Kaway fits

Kaway manufactures for the trade and does not sell to a client an integrator or distributor has introduced. RFID and NFC cards in 125 kHz, 13.56 MHz and UHF are printed, laminated, personalised and encoded in one place: Kaway manufactures at the plant in Dongguan, China.

Kaway asks for the reader or lock model and confirms the chip in writing before anything goes into production, which is the same extract described above seen from the supply side. Where a site cannot answer the application questions, a sample is faster than another round of datasheets.

Minimum order is 500 units. Standard production is 13 calendar days, 8 calendar days on express and 12 calendar days for wooden cards. Quote requests are answered the same working day. A free sample is available where the request is qualified, which is the sample that should be run through enrolment, access and revocation before any quantity is committed.

Share your reader and application requirements with Kaway Group for a project specific discussion.

11. Frequently asked questions

Is a reader datasheet enough to order cards?

No. It produces a shortlist of chip families and confirms the frequency and standard. It cannot confirm the firmware, the licensed options, the active credential application or the keys, and those four decide whether a card is accepted.

The datasheet says 13.56 MHz. Is that enough?

No. ISO/IEC 14443 and ISO/IEC 15693 both run at 13.56 MHz and are different protocols. The standard has to be named, and then the chip family within it.

What does the controller interface section tell me about the card?

Nothing. Wiegand, OSDP and RS-485 describe how the reader talks to the access panel. That section matters to the installer and is irrelevant to the credential specification.

Can we skip the sample test if the chip is on the supported list?

It is the step that catches the failures a datasheet cannot show. The supported list proves the reader can communicate with the chip. Only a sample run through enrolment, access and revocation proves this site will accept it.

What if nobody knows the firmware version on the installed readers?

Then that is the finding, and it belongs in the extract as an open item rather than as an assumption. An undocumented estate is specified from a sample tested at the doors, not from the datasheet of the reader model.