ISO/IEC 19823-13:2026

International
Standard
ISO/IEC 19823-13
Second edition
Information technology —
2026-03
Conformance test methods for
security service crypto suites —
Part 13:
Crypto suite Grain-128A
Technologies de l’information — Conformance test methods for
security service crypto suites —
Partie 13: Suite cryptographique Grain-128A
Reference number
© ISO/IEC 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 1
3.1 Terms and definitions .1
3.2 Symbols and abbreviated terms .1
4 Test methods . 2
4.1 General .2
4.2 By demonstration .2
4.3 By design .2
5 Test requirements for ISO/IEC 18000-62 Interrogators and Tags . 2
6 Test methods related to the ISO/IEC 29167-13 Interrogators and Tags . 2
6.1 Test map for optional features .2
6.2 Crypto suite requirements .3
6.2.1 General .3
6.2.2 Crypto suite requirements of ISO/IEC 29167-13:2026, Clauses 5 to 8 and
Annexes A to C .3
6.2.3 Crypto suite requirements of ISO/IEC 29167-13:2026, Clauses 9 to 12 and
Annex E .3
6.3 Test patterns . . 12
6.3.1 General . 12
6.3.2 Test pattern 1 . 12
6.3.3 Test pattern 2 . 12
6.3.4 Test pattern 3 . 13
6.3.5 Test pattern 4 . 13
6.3.6 Test pattern 5 . 13
6.3.7 Test pattern 6 . 13
6.3.8 Test pattern 7 . 13
6.3.9 Test pattern 8 .14
6.3.10 Test pattern 9 .14
6.3.11 Test pattern 10 .14
6.3.12 Test pattern 11 .14
6.3.13 Test pattern 12 . 15
6.3.14 Test pattern 13 . 15
6.3.15 Test pattern 14 . 15
6.3.16 Test pattern 15 . 15
6.3.17 Test pattern 16 .16
6.3.18 Test pattern 17 .16
6.3.19 Test pattern 18 .16
6.3.20 Test pattern 19 .16
6.3.21 Test pattern 20 .17
6.3.22 Test pattern 21 .17
6.3.23 Test pattern 22 .17
6.3.24 Test pattern 23 .17
6.3.25 Test pattern 24 .18
6.3.26 Test pattern 25 .18
Bibliography . 19

© ISO/IEC 2026 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 31, Automatic identification and data capture techniques.
This second edition cancels and replaces the first edition (ISO/IEC 19823-13:2018), which has been
technically revised.
The main change is as follows: test items have been updated to reflect changes to the over-the-air protocol.
A list of all parts in the ISO/IEC 19823 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2026 – All rights reserved
iv
Introduction
The ISO/IEC 29167 series describes security services that are applicable for the ISO/IEC 18000 series.
The various parts of the ISO/IEC 29167 series describe crypto suites that are optional extensions to the
ISO/IEC 18000 air interfaces.
The ISO/IEC 19823 series describes conformance test methods for security service crypto suites.
The ISO/IEC 19823 series is related to the ISO/IEC 18047 series, which describes the radio frequency
identification device conformance test methods, in the same way as the ISO/IEC 29167 series is related
to the ISO/IEC 18000 series. These relations mean that, for a product that is claimed to conform to a pair
ISO/IEC 18000-n and ISO/IEC 29167-m, the test methods of ISO/IEC 18047-n and ISO/IEC 19823-m apply. If
a product supports more than one part of the ISO/IEC 18000 series or the ISO/IEC 29167 series, all related
parts of the ISO/IEC 18047 series and the ISO/IEC 19823 series apply.
The conformance parameters are:
— parameters that apply directly affecting system functionality and inter-operability;
— protocol including commands and replies;
— nominal values and tolerances.
NOTE 1 ISO/IEC 18047-6 provides the conformance test requirements of ISO/IEC 18000-6, ISO/IEC 18000-61,
ISO/IEC 18000-62, ISO/IEC 18000-63 and ISO/IEC 18000-64.
NOTE 2 Test methods for interrogator and tag performance are covered by the multiple parts of the ISO/IEC 18046
series.
© ISO/IEC 2026 – All rights reserved
v
International Standard ISO/IEC 19823-13:2026(en)
Information technology — Conformance test methods for
security service crypto suites —
Part 13:
Crypto suite Grain-128A
1 Scope
This document describes the test methods for determining conformance for the security crypto suite Grain-
128A defined in ISO/IEC 29167-13.
This document contains conformance tests for all mandatory and optional functions.
Unless otherwise specified, the tests in this document are only applicable to radio frequency identification
(RFID) tags and interrogators defined in the ISO/IEC 18000 series using ISO/IEC 29167-13.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 17025, General requirements for the competence of testing and calibration laboratories
ISO/IEC 18000-62, Information technology — Radio frequency identification for item management — Part 62:
Parameters for air interface communications at 860 MHz to 960 MHz Type B
ISO/IEC 18047-6:2025, Information technology — Radio frequency identification device conformance test
methods — Part 6: Test methods for air interface communications at 860 MHz to 960 MHz
ISO/IEC 19762, Information technology — Automatic identification and data capture (AIDC) techniques —
Vocabulary
ISO/IEC 29167-13:2026, Information technology — Automatic identification and data capture techniques —
Part 13: Crypto suite Grain-128A security services for air interface communications
3 Terms, definitions, symbols and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19762 and ISO/IEC 29167-13
apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.2 Symbols and abbreviated terms
For the purposes of this document, the symbols and abbreviated terms given in ISO/IEC 19762 apply.

© ISO/IEC 2026 – All rights reserved
4 Test methods
4.1 General
This clause describes the test methods for ISO/IEC 29167-13. As parts of the ISO/IEC 19823 series are always
intended to be tested in conjunction with the ISO/IEC 18047 series, duplication of information, requirements
and specifications present in the ISO/IEC 18047 series has been avoided.
Clause 5 describes elements that are covered in the respective part of the ISO/IEC 18047 series.
Clause 6 describes elements that are not covered by the ISO/IEC 18047 series and that are therefore
addressed in this document.
4.2 By demonstration
"By demonstration" means that laboratory testing of one or (if required for statistical reasons) multiple
products, processes or services to ensure conformance.
A test laboratory meeting the requirements of ISO/IEC 17025 shall perform the indicated testing to ensure
conformance of the component or system.
For Protocol requirements that are verified by demonstration, the test conditions are specified by this
document. The detailed test plan is at the discretion of the test laboratory.
4.3 By design
"By design" means that either design parameters or theoretical analysis, or both, that ensure conformance.
A vendor submitting a component or system for conformance testing shall provide the necessary technical
information, in the form of a technical memorandum or similar. A test laboratory shall issue a test certificate
indicating whether the technical analysis was sufficient to ensure conformance of the component or system.
For protocol requirements that are verified by design, the method of technical analysis is at the discretion
of the submitting vendor and is not specified by this document. In general, the technical analysis shall have
sufficient rigor and technical depth to convince a test engineer knowledgeable of the Protocol that the
particular requirement has been met.
5 Test requirements for ISO/IEC 18000-62 Interrogators and Tags
The requirements and recommendations of ISO/IEC 18047-6:2025, Clauses 4 and 5 on default conditions
applicable to the test methods and on setup of test equipment, respectively, shall be fulfilled.
Before a device under test (DUT) is tested according to this document, it shall successfully pass
ISO/IEC 18047-6:2025, Clause 7 on conformance tests for ISO/IEC 18000-62.
6 Test methods related to the ISO/IEC 29167-13 Interrogators and Tags
6.1 Test map for optional features
Table 1 lists all optional features of this crypto suite and shall be used as template to report the test results.
Furthermore, it is used to refer to the test requirements in 6.2.

© ISO/IEC 2026 – All rights reserved
Table 1 — Test map for optional features
Item Feature Additional requirement Mark items to be Test
no. tested for result
supplied product
Shall be tested with the authenticate command of
1 Tag authentication (TA)
the relevant part of the ISO/IEC 18000 series.
Interrogator authentication Shall be tested with the authenticate command of
(IA) the relevant part of the ISO/IEC 18000 series.
Secure authenticated Shall be tested with the SecureComm command of
communication the relevant part of the ISO/IEC 18000 series.
Shall be tested with the SecureComm command of
4 Key update
the relevant part of the ISO/IEC 18000 series.
5 Number of keys supported
Table 2 lists all the crypto suite requirements that shall be tested in dependence of the features of Table 1 as
supported by the DUT. Items marked with M are mandatory and shall be tested for each DUT.
6.2 Crypto suite requirements
6.2.1 General
Subclause 6.2 refers to the requirements of ISO/IEC 29167-13.
6.2.2 Crypto suite requirements of ISO/IEC 29167-13:2026, Clauses 5 to 8 and Annexes A to C
All the requirements of ISO/IEC 29167-13:2026, Clauses 5 to 8 and Annexes A to C shall apply, inherently by
design only.
6.2.3 Crypto suite requirements of ISO/IEC 29167-13:2026, Clauses 9 to 12 and Annex E
Table 2 contains all the requirements of ISO/IEC 29167-13:2026, Clauses 9 to 12 and Annex E.
Table 2 — Crypto suite requirements of ISO/IEC 29167-13:2026, Clauses 9 to 12 and Annex E
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
The Tag’s air interface protocol logic shall provide an
external reset to the Tag crypto engine which shall set
1 9 M Tag By design
INIT=FALSE, TA=FALSE, IA=FALSE and ERROR=FALSE
before transition to the CS-Reset state.
The CS-Reset state shall process crypto commands from
the Tag’s air interface protocol logic only when ERROR=-
2 9 FALSE. If an error condition exists then the Tag crypto M Tag By design
engine shall set ERROR=TRUE and remain in the CS-Reset
state.
If an error condition exists then the Tag crypto engine
3 9 M Tag By design
shall set ERROR=TRUE and remain in the CS-Reset state.
The Tag shall report an error condition if it receives a
4 9 CryptoCommCmd, CryptoSecCommCmd or CryptoKeyUp- M Tag By design
date command in the CS-Reset state.
Key
M mandatory; items are mandatory and shall be tested for all devices
O optional; items are optional and shall be tested only for devices that support the feature that is indicated by the
requirement
a
All clauses, subclauses and tables referenced are from ISO/IEC 29167-13:2026.

© ISO/IEC 2026 – All rights reserved
TTaabbllee 22 ((ccoonnttiinnueuedd))
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
The Tag shall check a CryptoAuthCmd payload for any
5 9 M Tag By design
error conditions.
The Tag shall report an error condition if Step ≠ 00 in the By demonstration
b
6 9 M Tag
CS-Reset state. using test pattern 3
By demonstration
using test patterns 2
The Tag shall report an error condition if the KeyID value
7 9 M Tag (only if TA is support-
is not supported by the Tag.
ed), 10 (only if IA is
supported) and 16
The Tag shall report an error condition if Auth-
8 9 Method=00 and the Tag does not support Tag authenti- M Tag By design
b
cation.
The Tag shall report an error condition if Auth-
9 9 Method=00 and the Options selected are not supported O Tag By design
b
by the Tag CSFeatures.
The Tag shall report an error condition if Auth-
10 9 Method=01 and the Tag does not support Interrogator M Tag By design
b
authentication.
The Tag shall report an error condition if Auth- By demonstration
11 9 O Tag
Method=01 and Options ≠ 0000 using test pattern 9
b b.
The Tag shall report an error condition if Auth- By demonstration
12 9 M Tag
Method=10 and Options ≠ 0000 using test pattern 15
b b.
The Tag shall report an error condition if AuthMethod=11
b
13 9 and the Tag does not support a vendor defined authenti- M Tag By design
cation.
If no error condition exists, the Tag shall transition to the
14 9 M Tag By design
CS-Init state.
The authentication method to be performed shall be
Tag,
15 10.1 specified by the 2-bit value AuthMethod which is defined M By design
Interrogator
in Table 2.
If AuthMethod="00b", the Tag shall parse the Message for By demonstration
16 10.1 O Tag
Tag authentication as described in 10.2. using test pattern 1
If AuthMethod="01b", the Tag shall parse the Message By demonstration
17 10.1 O Tag
Interrogator authentication as described in 10.3. using test pattern 8
If AuthMethod="10b", the Tag shall parse the Message for By demonstration
18 10.1 M Tag
Mutual authentication as described in 10.4. using test pattern 14
Some of the authentication methods require multiple
steps to be performed in a specific sequence. The current Tag,
19 10.1 M By design
step in the sequence shall be specified by the 2-bit value Interrogator
Step as defined in Table 3.
During step 0 of an authentication method, the Tag
shall provide an 8-bit value CSFeatures which is used to
20 10.1 M Tag By design
indicate which of the optional Grain-128A CS features are
supported by the Tag.
During step 0 and 1 of an authentication method, the
21 10.1 M Interrogator By design
Interrogator shall provide a 4-bit value Options
The Tag authentication method uses a challenge-response
Interrogator,
22 10.2.1 protocol having one pair of message exchange (see Fig- O By design
Tag
ure 2).
Key
M mandatory; items are mandatory and shall be tested for all devices
O optional; items are optional and shall be tested only for devices that support the feature that is indicated by the
requirement
a
All clauses, subclauses and tables referenced are from ISO/IEC 29167-13:2026.

© ISO/IEC 2026 – All rights reserved
TTaabbllee 22 ((ccoonnttiinnueuedd))
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
For Tag authentication the Interrogator shall generate a
48-bit random number for use as IRandomNumber and
23 10.2.2 O Interrogator By design
issue the challenge to the Tag with the TA.1 Payload as
specified in Table 6.
The Tag shall generate a 48-bit random number for use
as TRandomNumber. The Tag crypto engine shall be
24 10.2.3 initialized for Tag authentication using TRandomNumber, O Tag By design
IRandomNumber and the crypto key specified by KeyID.
The crypto engine then shall generate the Tag keystream.
The Tag shall respond to the challenge from the Interroga-
25 10.2.3 O Tag By design
tor with the TA.1 Payload as specified in Table 7.
The Tag shall transition to the TA.1 state after the re-
26 10.2.3 O Tag By design
sponse to the Interrogator and shall set TA=TRUE.
The Interrogator shall be initialized for Tag authentica-
tion using TRandomNumber, IRandomNumber and the
27 10.2.4 O Interrogator By design
crypto key specified by KeyID. The crypto engine shall
then generate the Interrogator keystream.
The Interrogator shall compare the Tag keystream with
28 10.2.4 the Interrogator keystream to authenticate the Tag and O Interrogator By design
accepts it as valid if they are equal.
The Interrogator authentication method uses a chal-
Interrogator,
29 10.3.1 lenge-response protocol having two pairs of message O By design
Tag
exchange as shown in (see Figure 3).
In the first step of the Interrogator authentication pro-
cess, the Interrogator shall generate a 48-bit random
30 10.3.2 number for use as IRandomNumber and request a chal- O Interrogator By design
lenge from the Tag using the IA.1 Payload, as specified in
Table 8.
The Tag shall generate a 48-bit random number for use
as TRandomNumber. The Tag crypto engine shall be ini-
31 10.3.3 tialized for Interrogator authentication using TRandom- O Tag By design
Number, IRandomNumber and the crypto key specified by
KeyID.
The Tag shall respond with the challenge to the Interroga-
32 10.3.3 O Tag By design
tor with the IA.1 Payload as specified in Table 9.
The Tag shall transition to the IA.1 state after the re-
33 10.3.3 O Tag By design
sponse to the Interrogator.
In the second step, the Interrogator crypto engine shall
be initialized for Interrogator authentication using
34 10.3.4 TRandomNumber, IRandomNumber and the crypto key O Interrogator By design
specified by KeyID. The crypto engine shall then generate
the Interrogator keystream.
The Interrogator shall respond to the challenge from the
35 10.3.4 O Interrogator By design
Tag with the IA.2 Payload as specified in Table 10.
The Tag shall check the crypto command and payload for
any error conditions. If an error condition exists then the
36 10.3.5 O Tag By design
Tag crypto engine shall set ERROR=True and remain in
the IA.1 state.
The Tag shall report an error condition if it receives a
37 10.3.5 CryptoCommCmd, CryptoSecCommCmd or CryptoKeyUp- O Tag By design
date command in the IA.1 state.
Key
M mandatory; items are mandatory and shall be tested for all devices
O optional; items are optional and shall be tested only for devices that support the feature that is indicated by the
requirement
a
All clauses, subclauses and tables referenced are from ISO/IEC 29167-13:2026.

© ISO/IEC 2026 – All rights reserved
TTaabbllee 22 ((ccoonnttiinnueuedd))
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
The Tag shall report an error condition if AuthMethod ≠
38 10.3.5 O Tag By design
01 in the IA.2 payload.
b
The Tag shall report an error condition if Step ≠ 01 in the
b
39 10.3.5 O Tag By design
IA.2 payload.
The Tag shall report an error condition if the KeyID value
40 10.3.5 O Tag By design
is not the same as used for the IA.1 payload.
The Tag shall report an error condition if the selected
41 10.3.5 O Tag By design
Options are not supported by the Tag CSFeatures.
If no error condition exists, the Tag crypto engine shall
By demonstration
generate the Tag keystream and compare it with the
42 10.3.5 O Tag using test patterns 8
Interrogator keystream. It shall accept the Interrogator as
and 11
valid if the parameters are equal.
The Tag shall respond with the IA.2 Payload as specified
43 10.3.5 O Tag By design
in Table 11.
If the Interrogator authentication succeeded, the Tag shall
44 10.3.5 transition to the IA.2 state after the response to the Inter- O Tag By design
rogator and set IA=TRUE.
If the Interrogator authentication failed, the Tag shall
45 10.3.5 transition to the IA.2 state after the response to the Inter- O Tag By design
rogator and set ERROR=True.
The Mutual authentication method uses a challenge-re-
Interrogator,
46 10.4.1 sponse protocol having two pairs of message exchange M By design
Tag
(see Figure 4).
In the first step of the Mutual authentication process, the
Interrogator shall generate a 48-bit random number for
47 10.4.2 M Interrogator By design
use as IRandomNumber and request a challenge from the
Tag using the MA.1 Payload, as specified in Table 12.
The Tag shall generate a 48-bit random number for use as
TRandomNumber. The Tag crypto engine shall be initial-
48 10.4.3 M Tag By design
ized for Mutual authentication using the crypto key speci-
fied in KeyID, TRandomNumber and IRandomNumber.
The Tag shall respond with the challenge to the Interroga-
49 10.4.3 M Tag By design
tor with the MA.1 Payload as specified in Table 13.
The Tag shall transition to the MA.1 state after the re-
50 10.4.3 M Tag By design
sponse to the Interrogator.
In the second step, the Interrogator shall be initialized for
Mutual authentication using TRandomNumber, IRandom-
51 10.4.4 M Interrogator By design
Number and the crypto key specified by KeyID. The cryp-
to engine shall then generate the Interrogator keystream.
The Interrogator shall respond to the challenge from the
52 10.4.4 M Interrogator By design
Tag with the MA.2 Payload as specified in Table 14.
The Tag shall check the crypto command and payload for
any error conditions. If an error condition exists then the
53 10.4.5 M Tag By design
Tag crypto engine shall set ERROR=True and remain in
the MA.1 state.
The Tag shall report an error condition if it receives a
54 10.4.5 CryptoCommCmd, CryptoSecCommCmd or CryptoKeyUp- M Tag By design
date command in the MA.1 state.
The Tag shall report an error condition if AuthMethod ≠
55 10.4.5 M Tag By design
10 in the MA.2 payload.
b
Key
M mandatory; items are mandatory and shall be tested for all devices
O optional; items are optional and shall be tested only for devices that support the feature that is indicated by the
requirement
a
All clauses, subclauses and tables referenced are from ISO/IEC 29167-13:2026.

© ISO/IEC 2026 – All rights reserved
TTaabbllee 22 ((ccoonnttiinnueuedd))
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
The Tag shall report an error condition if Step ≠ 01 in the
b
56 10.4.5 M Tag By design
MA.2 payload.
The Tag shall report an error condition if the KeyID value
57 10.3.5 M Tag By design
is not the same as used for the MA.1 payload.
The Tag shall report an error condition if the selected
58 10.3.5 M Tag By design
Options are not supported by the Tag CSFeatures.
If no error condition exists, the Tag crypto engine shall
By demonstration
generate the Tag keystream and compare it with the
59 10.4.5 M Tag using test patterns 14
Interrogator keystream. It shall accept the Interrogator as
and 17
valid if the parameters are equal.
If the Interrogator is invalid, the Tag shall transition to
60 10.4.5 the MA.2 state after the response to the Interrogator and M Tag By design
set ERROR=True.
If the Interrogator is valid, the Tag crypto engine shall
61 10.4.5 M Tag By design
generate a new value for the Tag keystream.
The Tag shall transition to the MA.2 state after the re-
62 10.4.5 M Tag By design
sponse to the Interrogator and set TA=IA=TRUE.
The Tag shall respond with the MA.2 Payload as specified
63 10.4.5 M Tag By design
in Table 15.
The Interrogator shall check the authentication status
64 10.4.6 from the Tag and if it is OK, the Interrogator crypto engine M Interrogator By design
shall generate a new value for the Interrogator keystream.
The Interrogator shall use the updated keystreams to
65 10.4.6 authenticate the Tag. The Tag is accepted as valid the Tag M Interrogator By design
keystream and the Interrogator keystream are equal.
Authentication integrity shall be maintained for an Inter-
rogator authentication and a Mutual authentication, it is Interrogator,
66 11.1 M By design
optional to maintain the authentication integrity of a Tag Tag
authentication.
Authentication integrity shall be performed using either
Interrogator,
67 11.1 authenticated communication or secure authenticated M By design
Tag
communication, or both.
A Message Authentication Code (MAC) shall be used to Interrogator,
68 11.1 M By design
provide the integrity protection. Tag
The Interrogator shall select between using a MAC32 or a
69 11.1 MAC64 via the Options parameter during the authentica- M Interrogator By design
tion process.
If a Tag is authenticated as a result of Tag authentication, By demonstration
70 11.2 O Interrogator
the Interrogator may use authenticated communication. using test pattern 4
The TA.1 state shall process crypto responses from the
71 11.2 Tag’s air interface protocol logic only when ERROR=- O Tag By design
FALSE.
The Tag shall check the crypto responses for any error
conditions. If an error condition exists then the Tag cryp-
72 11.2 O Tag By design
to engine shall set ERROR=True and remain in the TA.1
state.
An error condition shall occur for any CryptoSecCom-
73 11.2 O Tag By design
mResp or CryptoAuthResp in the TA.1 state.
Key
M mandatory; items are mandatory and shall be tested for all devices
O optional; items are optional and shall be tested only for devices that support the feature that is indicated by the
requirement
a
All clauses, subclauses and tables referenced are from ISO/IEC 29167-13:2026.

© ISO/IEC 2026 – All rights reserved
TTaabbllee 22 ((ccoonnttiinnueuedd))
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
If no error condition exists, the Tag shall provide integrity
74 11.2 protection for the Tag response in the CryptoCommResp O Tag By design
payload (see Table 17).
Integrity of the Tag response shall be performed with the
75 11.2 O Tag By design
addition of an 8-bit value of 00 followed by a MAC.
h
The Tag shall remain in the TA.1 state after the response
76 11.2 O Tag By design
is sent to the Interrogator.
The Interrogator shall generate a MAC for the Tag re-
77 11.2 sponse within the CryptoCommResp payload to authenti- O Interrogator By design
cate the Tag response.
The Interrogator shall accept the response as valid if the
78 11.2 O Interrogator By design
MAC from the Tag equals the MAC from the Interrogator.
If an Interrogator is authenticated as a result of Interro-
By demonstration
gator authentication, it shall maintain the integrity of the
79 11.2 O Interrogator using test patterns 12
authentication during subsequent communications with
and 13
the singulated Tag.
The Interrogator shall provide integrity protection for the
80 11.2 O Interrogator By design
command in the CryptoCommCmd payload (see Table 16).
Integrity of the Interrogator command shall be performed
81 11.2 with the addition of an 8-bit value of 00 followed by a O Interrogator By design
h
MAC.
The IA.2 state shall process crypto commands from the
82 11.2 Tag’s air interface protocol logic only when ERROR=- O Tag By design
FALSE.
The Tag shall check the crypto commands for any error
conditions. If an error condition exists then the Tag cryp-
83 11.2 O Tag By design
to engine shall set ERROR=True and remain in the IA.2
state.
An error condition shall occur for any CryptoAuthCmd,
84 11.2 CryptoKeyUpdate or CryptoSecCommCmd in the IA.2 O Tag By design
state.
If no error condition exists, the Tag shall generate a MAC
85 11.2 for the Interrogator command within the CryptoCommC- O Tag By design
md payload to authenticate the Interrogator command.
The Tag shall accept the Interrogator command as valid if
86 11.2 the MAC from the Interrogator equals the MAC from the O Tag By design
Tag.
If the Interrogator command is invalid, the Tag crypto
87 11.2 engine shall set ERROR=TRUE and the Tag shall remain in O Tag By design
the IA.2 state.
If a Tag and Interrogator are both authenticated as a
By demonstration
result of Mutual authentication, then both shall maintain Interrogator,
88 11.2 M using test patterns 14
the integrity of the authentication during subsequent Tag
and 19
communications with the singulated Tag.
The Interrogator shall provide integrity protection for the
89 11.2 M Interrogator By design
command in the CryptoCommCmd payload (see Table 16).
Integrity of the Interrogator command shall be performed
90 11.2 with the addition of an 8-bit value of 00 followed by a M Interrogator By design
h
MAC.
Key
M mandatory; items are mandatory and shall be tested for all devices
O optional; items are optional and shall be tested only for devices that support the feature that is indicated by the
requirement
a
All clauses, subclauses and tables referenced are from ISO/IEC 29167-13:2026.

© ISO/IEC 2026 – All rights reserved
TTaabbllee 22 ((ccoonnttiinnueuedd))
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
The MA.2 state shall process crypto commands from
91 11.2 the Tag’s air interface protocol logic only when ERROR=- M Tag By design
FALSE.
The Tag shall check the crypto command for any error
conditions. If an error condition exists then the Tag crypto
92 11.2 M Tag By design
engine shall set ERROR=True and remain in the MA.2
state.
If secure authenticated communication is not enabled, an
93 11.2 error condition shall occur for any CryptoAuthCmd, Cryp- M Tag By design
toKeyUpdate or CryptoSecCommCmd in the MA.2 state.
If no error condition exists, the Tag shall generate a MAC
94 11.2 for the Interrogator command within the CryptoCommC- M Tag By design
md payload to authenticate the Interrogator command.
The Tag accepts the Interrogator command as valid if the
95 11.2 M Tag By design
MAC from the Interrogator equals the MAC from the Tag.
If the Interrogator command is invalid, the Tag crypto
96 11.2 engine shall set ERROR=TRUE and the Tag shall remain in M Tag By design
the MA.2 state.
The MA.2 state shall also process crypto responses from
97 11.2 the Tag’s air interface protocol logic only when ERROR=- M Tag By design
FALSE.
The Tag shall check the crypto command for any error
conditions. If an error condition exists then the Tag crypto
98 11.2 M Tag By design
engine shall set ERROR=True and remain in the MA.2
state.
If the Tag responds to CryptoCommCmd, an error condi-
99 11.2 tion shall occur for any CryptoSecCommResp or Crypto- M Tag By design
AuthResp in the MA.2 state.
If the no error condition exists, the Tag shall provide
100 11.2 integrity protection for the Tag response in the Crypto- M Tag By design
CommResp payload (see Table 17).
Integrity of the Tag response shall be performed with the
101 11.2 M Tag By design
addition of an 8-bit value of 00 followed by a MAC.
h
The Tag shall remain in the MA.2 state after the response
102 11.2 O Tag By design
is sent to the Interrogator.
The Interrogator shall generate a MAC for the Tag re-
103 11.2 sponse within the CryptoCommResp payload to authenti- O Interrogator By design
cate the Tag response.
The Interrogator accepts the response as valid if the MAC
104 11.2 O Interrogator By design
from the Tag equals the MAC from the Interrogator.
If a Tag and Interrogator are both authenticated as a
result of Mutual authentication, then the Interrogator has
Interrogator, By demonstration
105 11.3 the option to enable the use of encrypted commands and O
Tag using test pattern 20
responses when secure authenticated communication is
supported by the Tag.
Secure authenticated communication shall be enabled via
106 11.3 the Options parameter during the Mutual authentication O Interrogator By design
process.
The Interrogator shall encrypt the encapsulated Interro-
107 11.3 O Interrogator By design
gator command in the CryptoSecCommCmd payload.
Key
M mandatory; items are mandatory and shall be tested for all devices
O optional; items are optional and shall be tested only for devices that support the feature that is indicated by the
requirement
a
All clauses, subclauses and tables referenced are from ISO/IEC 29167-13:2026.

© ISO/IEC 2026 – All rights reserved
TTaabbllee 22 ((ccoonnttiinnueuedd))
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
The Interrogator shall provide integrity protection for the
108 11.3 encrypted command in the CryptoSecCommCmd payload O Interrogator By design
(see Table 18).
Integrity of the Interrogator command shall be performed
109 11.3 with the addition of an 8-bit value of 00 followed by a O Interrogator By design
h
MAC.
The MA.2 state shall process crypto commands and
110 11.3 responses from the Tag’s air interface protocol logic only O Tag By design
when ERROR=FALSE.
The Tag shall check the crypto responses for any error
conditions. If an error condition exists then the Tag crypto
111 11.3 O Tag By design
engine shall set ERROR=True and remain in the MA.2
state.
An error condition shall occur for any CryptoAuthCmd or
By demonstration
112 11.3 for any CrypteSecCommCmd when secure authenticated O Tag
using test pattern 21
communication is not enabled.
If no error condition, the Tag shall decrypt the Interroga-
113 11.3 O Tag By design
tor command within the CryptoSecCommCmd payload.
The Tag shall gen
...