Historical Bytes and the ATR
ISO 7816 Part 4: Interindustry Commands for Interchange
ISO 7816 part 4, section..1 2 3 4 5 6 7 8 9 annex.. A B C D E F
Historical bytes: the card’s business card
The Answer to Reset ends with up to fifteen historical bytes. They are the card’s opportunity to describe itself before any command is sent, and for a terminal they are often the fastest route to knowing what it is holding.
Where they sit
The ATR is a structured byte string: an initial character establishing bit convention, a format byte, a variable run of interface bytes describing timing and protocols, then the historical bytes, then a check byte where required. The format byte states how many historical bytes follow, so a parser knows exactly where they begin and end.
Their content is not mandated in the same way the interface bytes are. Part 4 defines an optional structure for them; a card may use it, use a proprietary layout, or return none at all.
The category indicator
Where the structure is used, the first historical byte is a category indicator that tells the terminal how to read the rest:
00— a status indicator is present at the end of the historical bytes, with the bytes between carrying proprietary content.80— the remaining bytes are a sequence of COMPACT-TLV data objects, optionally ending with a status indicator.81–8F— reserved for future use.- Any other value — proprietary. Interpret only with vendor documentation.
COMPACT-TLV
Space in the ATR is scarce, so the structured form uses a condensed encoding rather than full BER-TLV: a single byte carries a four-bit tag and a four-bit length, followed by the value. It is not interchangeable with BER-TLV and a parser written for one will not read the other.
The objects that appear in practice describe things such as the country or issuer, the application identifier of a default application, initial access data telling a terminal how to read the first file without prior knowledge, issuer-specific data, pre-issuing data identifying the chip and mask, and card capabilities.
Card capabilities is the one worth extracting deliberately. It indicates which file referencing methods the card supports, which data coding conventions apply, and whether features such as extended length or logical channels are available. It answers questions that would otherwise require trial-and-error command probing.
Status indicator
The optional status indicator conveys the card’s life-cycle state and, where present, a status word. Life-cycle state distinguishes a card in production from one in operational use from one that has been terminated, and a terminal that ignores it can spend a long time debugging a card that is simply not in a usable state.
Practical notes
- Log the full ATR, always. It is cheap, it identifies the card, and it is the first thing anyone diagnosing an integration will ask for.
- Do not use the ATR as a security control. It is unauthenticated and trivially replayable. Use it to configure behaviour, never to grant trust.
- Do not hard-code a full ATR match. ATRs vary across production batches and mask revisions of the same product. Match on the specific fields you care about.
- Absence is normal. Plenty of perfectly good cards return no historical bytes. Treat that as a case to handle, not an error.
- Contactless differs. On an ISO/IEC 14443 interface the equivalent information arrives in the answer-to-select rather than an ATR, though the historical byte concepts carry across.
Authoritative source
For the normative structure of the historical bytes, refer to ISO/IEC 7816-4:2020, published by ISO; the ATR itself is specified in ISO/IEC 7816-3. This page is Ambimat’s own explanation and does not reproduce or replace the standard.