What ISO/IEC 7816-4 Covers
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
What ISO/IEC 7816-4 covers — and what it does not
Knowing the boundary of Part 4 saves a great deal of wasted effort. Engineers regularly go looking in it for things it was never intended to define, and just as regularly assume it does not cover something it does.
Inside the boundary
Part 4 specifies behaviour that is observable at the card–terminal interface. That includes:
- The structure of command and response messages exchanged between the terminal and the card.
- The organisation of files and data on the card as seen from outside, and the ways of referencing them.
- How data objects are retrieved and how the card describes its own capabilities.
- The structure and interpretation of the historical bytes returned at reset.
- A security architecture: access rules on files and data, and the security status a terminal must reach to satisfy them.
- Secure messaging, so that commands and responses can be authenticated and encrypted.
- Mechanisms for identifying and selecting applications on a multi-application card.
Outside the boundary
Three exclusions matter in practice:
- Internal implementation is out of scope. How the card stores a file, manages memory, or schedules its operations is the card platform’s business. Two cards can be equally conformant and behave completely differently inside.
- Cryptographic algorithms are not defined here. Part 4 provides the means to invoke security operations and to reference keys and algorithms, but the algorithms themselves come from elsewhere. ISO/IEC 7816-8 covers commands and mechanisms for security operations.
- It is not a product profile. Part 4 defines a toolkit, most of which is optional. No real card implements all of it, and a card that implements a command is not obliged to accept it under all conditions.
Why the last point causes the most trouble
Because so much of Part 4 is optional, “ISO 7816-4 compliant” on a datasheet tells you very little on its own. A card may support READ RECORD but only on linear fixed files; it may support extended length fields only over T=1; it may accept a SELECT by application identifier but not by path. The useful questions for a supplier are which commands are supported, under which access conditions, and with which parameter options — not whether the card is compliant.
This is also why interoperability profiles exist. A payment, identity or transit specification narrows Part 4 down to a mandatory subset with defined behaviour, and that narrowed profile is what an implementation is actually tested against.
How to use this in practice
When a behaviour looks wrong, first decide which side of the boundary it sits on. If it concerns message structure, file referencing, access conditions or selection, Part 4 has an answer. If it concerns timing, electrical behaviour or protocol framing, the answer is in Part 3. If it concerns an algorithm or a scheme-specific data element, the answer is in Part 8 or in the scheme specification, not here.
Authoritative source
For the normative statement of scope, refer to ISO/IEC 7816-4:2020, published by ISO. This page is Ambimat’s own explanation and does not reproduce or replace the standard.