ISO/IEC 24759:2025

Information security, cybersecurity and privacy protection - Test requirements for cryptographic modules

This document specifies the methods to be used by testing laboratories to test whether the cryptographic module conforms to the requirements specified in ISO/IEC 19790:2025. The methods are developed to provide a high degree of objectivity during the testing process and to ensure consistency across the testing laboratories. This document also specifies the information that vendors are required to provide testing laboratories as supporting evidence to demonstrate their cryptographic modules’ conformity to the requirements specified in ISO/IEC 19790:2025. Vendors can also use this document to verify whether their cryptographic modules satisfy the requirements specified in ISO/IEC 19790:2025 before applying to a testing laboratory for testing.

Sécurité de l’information, cybersécurité et protection de la vie privée — Exigences d'essai pour modules cryptographiques

General Information

• Status: Published
• Publication Date: 25-Feb-2025
• ICS: 35.030 - IT Security
• Technical Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Drafting Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Current Stage: 6060 - International Standard published
• Start Date: 26-Feb-2025
• Due Date: 18-Oct-2024
• Completion Date: 26-Feb-2025

Relations

• Revises: ISO/IEC 24759:2017 - Information technology - Security techniques - Test requirements for cryptographic modules
• Effective Date: 06-Jun-2022

Overview

ISO/IEC 24759:2025 - Information security, cybersecurity and privacy protection - Test requirements for cryptographic modules (ISO, 2025) defines the test methods that independent testing laboratories must use to verify that a cryptographic module conforms to the security requirements in ISO/IEC 19790:2025. The standard is designed to increase objectivity and consistency across laboratories, and it also specifies the supporting evidence vendors must supply. Vendors can use the document to self‑check their products before formal testing.

Key Topics and Requirements

ISO/IEC 24759:2025 organizes test requirements across the full lifecycle and internal structure of cryptographic modules. Major technical topics include:

• Cryptographic module specification and boundary - tests to confirm the defined module, its type, and physical/logical boundary.
• Interfaces and data paths - test cases for module interfaces, plaintext trusted paths, and protected internal paths.
• Roles, services, and authentication - verification of role separation, services provided, and authentication mechanisms.
• Software/firmware security and security levels - tests for modifiable/non‑modifiable firmware, and requirements mapped to security levels.
• Operational environment - evaluation of host OS and modifiable environments where applicable.
• Physical security and environmental failure protection - tests covering physical embodiments and resistance to tampering and environmental attacks.
• Non‑invasive and side‑channel resistance - test methods addressing power, timing and other non‑invasive attack vectors.
• Sensitive Security Parameter (SSP) management - verification of key generation, RNGs, storage, zeroization, and secure entry/output.
• Self‑tests and lifecycle assurance - procedures for pre‑operational and conditional self‑tests, configuration management, design/development and vendor testing.
• Documentation and cryptographic module security policy - required evidence, user and administrative documentation, and the module security policy content.

Applications and Who Uses It

ISO/IEC 24759:2025 is practical for organizations involved in the design, testing, certification and procurement of cryptographic modules:

• Testing laboratories and certification bodies - to apply consistent, objective test methods for product evaluation.
• Vendors and product engineers - to prepare evidence packages and perform pre‑testing against ISO/IEC 19790:2025.
• Security architects and compliance teams - to ensure deployed HSMs, TPMs, smart cards, encryption appliances and IoT cryptographic modules meet validated requirements.
• Procurement and risk officers - to specify testable security requirements in acquisition contracts.

Use this standard to streamline certification, reduce testing variability, and demonstrate conformity of cryptographic modules in regulated and high‑security environments.

Related Standards

• ISO/IEC 19790:2025 - cryptographic module security requirements (normative reference).
• Comparable standards and references often considered: NIST FIPS 140‑3 (US cryptographic module validation).

Standards Content (Sample)

International
Standard
ISO/IEC 24759
Fourth edition
Information security,
2025-02
cybersecurity and privacy
protection — Test requirements
for cryptographic modules
Sécurité de l’information, cybersécurité et protection de la vie
privée — Exigences d'essai pour modules cryptographiques
Reference number
© ISO/IEC 2025
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: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2025 – All rights reserved
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms. 2
5 Document organization . 2
5.1 General .2
5.2 Assertions and security requirements .3
5.3 Assertions with cross references .3
6 Security requirements . 4
6.1 General .4
6.2 Cryptographic module specification .5
6.2.1 Cryptographic module specification general requirements .5
6.2.2 Types of cryptographic modules .5
6.2.3 Cryptographic boundary .6
6.2.4 Module operations .16
6.3 Cryptographic module interfaces . 23
6.3.1 Cryptographic module interfaces general requirements . 23
6.3.2 Categories of interfaces . 26
6.3.3 Plaintext trusted path . 35
6.3.4 Protected internal paths . 38
6.4 Roles, services, and authentication . 39
6.4.1 Roles, services, and authentication general requirements . 39
6.4.2 Roles . 40
6.4.3 Services .41
6.4.4 Authentication . 49
6.5 Software/firmware security .59
6.5.1 Software/firmware security general requirements .59
6.5.2 Security level 1 .62
6.5.3 Security level 2 .67
6.5.4 Security levels 3 and 4. 68
6.6 Operational environment. 69
6.6.1 Operational environment general requirements . 69
6.6.2 Clause applicability .70
6.6.3 Operating system requirements for modifiable operational environments .71
6.7 Physical security . 83
6.7.1 Physical security embodiments . 83
6.7.2 Physical security general requirements . 84
6.7.3 Physical security requirements for each physical security embodiment . 95
6.7.4 Environmental failure protection/testing . 100
6.7.5 Environmental failure protection features . 100
6.7.6 Environmental failure testing procedures . 101
6.8 Non-invasive security . . 104
6.8.1 Non-invasive security general requirements . 104
6.8.2 Security levels 1 and 2. 104
6.8.3 Security level 3 . 105
6.8.4 Security level 4 . 105
6.9 Sensitive security parameter management . 106
6.9.1 Sensitive security parameter management general requirements . 106
6.9.2 Random bit generators . 108
6.9.3 Sensitive security parameter generation .110
6.9.4 Automated sensitive security parameter establishment .110

© ISO/IEC 2025 – All rights reserved
iii
6.9.5 Sensitive security parameter entry and output . 111
6.9.6 Sensitive security parameter storage .117
6.9.7 Sensitive security parameter zeroization . 118
6.10 Self-tests . 122
6.10.1 Self-test general requirements . 122
6.10.2 Security levels 3 and 4. 126
6.10.3 Pre-operational self-tests . 127
6.10.4 Conditional self-tests . 130
6.11 Life-cycle assurance .143
6.11.1 Life-cycle assurance general requirements .143
6.11.2 Configuration management .143
6.11.3 Design .145
6.11.4 Finite state model .145
6.11.5 Development . 149
6.11.6 Vendor testing . 155
6.11.7 Delivery and operation . 157
6.11.8 Guidance documents . 160
6.12 Mitigation of other attacks .161
6.12.1 Mitigation of other attacks general requirements .161
6.12.2 Security levels 1, 2 and 3 .161
6.12.3 Security level 4 .161
7 Documentation requirements .162
7.1 Purpose . 162
7.2 Items . 163
7.2.1 Cryptographic module specification . 163
7.2.2 Cryptographic module interfaces . 164
7.2.3 Roles, services, and authentication . 164
7.2.4 Software/Firmware security . 165
7.2.5 Operational environment . 165
7.2.6 Physical security . 166
7.2.7 Non-invasive security .167
7.2.8 Sensitive security parameter management .167
7.2.9 Self-tests . . . 169
7.2.10 Life-cycle assurance . 169
7.2.11 Mitigation of other attacks .171
8 Cryptographic module security policy .172
8.1 General . 172
8.2 Items . 173
8.2.1 General . 173
8.2.2 Cryptographic module specification .174
8.2.3 Cryptographic module interfaces . 175
8.2.4 Roles, services, and authentication . 175
8.2.5 Software/Firmware security .176
8.2.6 Operational environment . 177
8.2.7 Physical security . 178
8.2.8 Non-invasive security . 179
8.2.9 Sensitive security parameters management. 179
8.2.10 Self-tests . . . 180
8.2.11 Life-cycle assurance . 180
8.2.12 Mitigation of other attacks . 181
Bibliography .182

© ISO/IEC 2025 – All rights reserved
iv
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 27, Information security, cybersecurity and privacy protection.
This fourth edition cancels and replaces the third edition (ISO/IEC 24759:2017), which has been technically
revised.
The main changes are as follows:
— new terminology has been added;
— ASs, VEs and TEs have been updated according to ISO/IEC 19790:2025; and
— VEs and TEs have been corrected or updated to improve efficiency.
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 2025 – All rights reserved
v
Introduction
In information technology there is an ever-increasing need to use cryptographic mechanisms, such as for the
protection of data against unauthorized disclosure or manipulation, for entity authentication, and for non-
repudiation. The security and reliability of such mechanisms are directly dependent on the cryptographic
modules in which they are implemented.
ISO/IEC 19790 provides four increasing, qualitative levels of security requirements intended to cover a wide
range of potential applications and environments. The cryptographic techniques are identical over the four
security levels defined in this document. The security requirements cover areas relative to the design and
implementation of a cryptographic module. These areas include:
— cryptographic module specification;
— cryptographic module interfaces;
— roles, services and authentication;
— software/firmware security;
— operational environment;
— physical security;
— non-invasive security;
— sensitive security parameter management;
— self-tests;
— life-cycle assurance; and
— mitigation of other attacks.
This document specifies the test requirements for cryptographic modules conforming to ISO/IEC 19790:2025.

© ISO/IEC 2025 – All rights reserved
vi
International Standard ISO/IEC 24759:2025(en)
Information security, cybersecurity and privacy protection —
Test requirements for cryptographic modules
1 Scope
This document specifies the methods to be used by testing laboratories to test whether the cryptographic
module conforms to the requirements specified in ISO/IEC 19790:2025. The methods are developed to
provide a high degree of objectivity during the testing process and to ensure consistency across the testing
laboratories.
This document also specifies the information that vendors are required to provide testing laboratories as
supporting evidence to demonstrate their cryptographic modules’ conformity to the requirements specified
in ISO/IEC 19790:2025.
Vendors can also use this document to verify whether their cryptographic modules satisfy the requirements
specified in ISO/IEC 19790:2025 before applying to a testing laboratory for testing.
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 19790:2025, Information security, cybersecurity and privacy protection — Security requirements for
cryptographic modules
ISO/IEC 20085-1, IT Security techniques — Test tool requirements and test tool calibration methods for use in
testing non-invasive attack mitigation techniques in cryptographic modules — Part 1: Test tools and techniques
ISO/IEC 20085-2, IT Security techniques — Test tool requirements and test tool calibration methods for use in
testing non-invasive attack mitigation techniques in cryptographic modules — Part 2: Test calibration methods
and apparatus
ISO/IEC 20543, Information technology — Security techniques — Test and analysis methods for random bit
generators within ISO/IEC 19790 and ISO/IEC 15408
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19790 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at www .iso .org/ obp;
— IEC Electropedia: available at www .electropedia .org.
3.1
validation certificate
assertion by a certification body that a cryptographic function has been tested and found to be a correct
implementation of the target cryptographic function

© ISO/IEC 2025 – All rights reserved
3.2
vendor affirmation
statement from a vendor that a given implementation of a security function is correct and meets all relevant
requirements from related standards, based on their own internal assurance activities
Note 1 to entry: Rules on acceptable vendor affirmations are set by individual certification bodies who independently
define evidence requirements for a given vendor affirmation and can require review by an independent testing
laboratory.
4 Symbols and abbreviated terms
For the purposes of this document, the symbols and abbreviated terms apply.
ACL access control list
API application programming interface
CBC cipher block chaining
CPLD complex programmable logic device
CSP critical security parameter
ECB electronic codebook
EDC error detection code
EFP environmental failure protection
EFT environmental failure testing
FPGA field programmable gate array
FSM finite state model
HDL hardware description language
IC integrated circuit
PC personal computer
PIN personal identification number
PSP public security parameter
RBG random bit generator
SSP sensitive security parameter
5 Document organization
5.1 General
Clause 6 specifies the methods that shall be used by testing laboratories and the requirements for
documentation that vendors shall provide to testing laboratories.
6.2 to 6.12 includes eleven subclauses corresponding to the eleven areas of security requirements from
ISO/IEC 19790:2025. Clause 7 corresponds to ISO/IEC 19790:2025, Annex A, and Clause 8 corresponds to
ISO/IEC 19790:2025, Annex B.
© ISO/IEC 2025 – All rights reserved
ISO/IEC 19790:2025, Annexes C, D, E, F and G do not currently include any assertions and are not covered by
this document.
5.2 Assertions and security requirements
In Clauses 6, 7 and 8, the corresponding security requirements from ISO/IEC 19790:2025 are presented in
Table 1 to 429, each dedicated to an individual assertion (i.e. statements that shall be true for the module to
satisfy the requirement of a given area at a given level).
All of the assertions are direct quotations from ISO/IEC 19790:2025, however what is quoted in each table
can be part of a longer sentence or list that is not replicated in this document. For this reason, it is important
that the entire text of ISO/IEC 19790:2025 be used to fully understand every assertion’s definition, context
and conditions.
The assertions are denoted by the form:
AS〈requirement_number〉.〈requirement_number〉
where “requirement_number” is the number of the corresponding area specified in ISO/IEC 19790:2025
(i.e. 1 to 11 and A to G), and “sequence_number” is a sequential identifier for assertions within a subclause.
After the statement of each assertion, the security levels to which the assertion applies (i.e. levels 1 to 4) are
listed in parentheses.
Following each assertion in its corresponding table is a set of requirements levied on the vendor. These
requirements describe the types of documentation or explicit information that the vendor shall provide in
order for the tester to verify conformity to the given assertion. These requirements are denoted by the form:
VE〈requirement_number〉.〈assertion_sequence_number〉.〈sequence_number〉
where “requirement_number” and “assertion_sequence_number” are identical to the corresponding
assertion requirement number and sequence number, and “sequence_number” is a sequential identifier for
vendor requirements within the assertion requirement.
Following each assertion and the requirements levied on the vendor in the table, there are a set of
requirements levied on the tester of the cryptographic module. These requirements instruct the tester as to
what he or she shall do in order to test the cryptographic module with respect to the given assertion. These
requirements are denoted by the form:
TE〈requirement_number〉.〈assertion_sequence_number〉.〈sequence_number〉
where “requirement_number” and “assertion_sequence_number” are identical to the corresponding
assertion requirement number and sequence number, and “sequence_number” is a sequential identifier for
tester requirements within the assertion requirement.
Tables give the assertions ASs, the requirements levied on the vendor VEs, the requirements levied on the
tester TEs, notes if applicable and examples if applicable.
A certification body may modify, add, or delete either VEs or TEs, or both, in this document.
5.3 Assertions with cross references
For clarity, some assertions have been provided and cross references to other assertions and related text
have been put between curly brackets “{” and “}”.

© ISO/IEC 2025 – All rights reserved
6 Security requirements
6.1 General
Table 1 — VE and TE of AS01.01
General — levels 1, 2, 3 and 4
AS01.01 This clause specifies the security requirements that cryptographic modules shall follow.
ISO/IEC
19790:2025,
7.1
Required test procedures
This assertion is not separately tested.
Table 2 — VE and TE of AS01.02
General — levels 1, 2, 3 and 4
AS01.02 A cryptographic module shall be tested against the requirements of each area addressed in
this clause.
ISO/IEC 19790:2025,
7.1
Required test procedures
This assertion is not separately tested.
NOTE 1 The tests can be performed in one or more of the following manners.
a) The tester performs tests at the tester’s facility.
b) The tester performs tests at the vendor’s facility.
c) The tester supervises vendor performing tests at the vendor’s facility.
1) Rationale is included that explains why the tester could not perform the tests.
2) The tester develops the required test plan and required tests.
3) The tester directly observes the tests being performed.
d) The tester can reference existing evidence of compliance (e.g. third party certificate or test report) where
permitted by a given certification body or accreditation body for the testing laboratory.
NOTE 2 An assertion fails if any of its subsequent tests fail.
NOTE 3 The accreditation body for testing laboratory refers to ISO/IEC TS 23532-2.
Table 3 — VE and TE of AS01.03
General — levels 1, 2, 3 and 4
AS01.03 The cryptographic module level shall be independently determined in each area.
ISO/IEC
19790:2025, 7.1
Required test procedures
This assertion is not separately tested.

© ISO/IEC 2025 – All rights reserved
Table 4 — VE and TE of AS01.04
General — levels 1, 2, 3 and 4
AS01.04 All documentation, including copies of the user and installation manuals, design specifications and
life cycle documentation shall be provided for a cryptographic module that undergoes independent
ISO/IEC
testing.
19790:2025, 7.1
Required test procedures
This assertion is not separately tested.
6.2 Cryptographic module specification
6.2.1 Cryptographic module specification general requirements
Table 5 — VE and TE of AS02.01
Cryptographic module specification general requirements — levels 1, 2, 3 and 4
AS02.01 A cryptographic module shall be a set of hardware, software, firmware, or some combina-
tion thereof, which at a minimum, implements a defined cryptographic service employing an
ISO/IEC
approved security function as specified in ISO/IEC 19790:2025, Annex C, or process, and is con-
19790:2025, 7.2.1
tained within a defined cryptographic boundary.
Required test procedures
This assertion is not separately tested.
Table 6 — VE and TE of AS02.02
Cryptographic module specification general requirements — levels 1, 2, 3 and 4
AS02.02 The documentation for cryptographic module specification specified in ISO/IEC 19790:2025,
A.2.1 shall be provided.
ISO/IEC
19790:2025, 7.2.1
Required test procedures
This assertion is tested as part of ASA.01.
6.2.2 Types of cryptographic modules
Table 7 — VE and TE of AS02.03
Types of cryptographic modules — levels 1, 2, 3 and 4
AS02.03 A cryptographic module shall be defined as either a hardware module, firmware module, hybrid
firmware module, software module, or hybrid software module.
ISO/IEC
19790:2025, 7.2.2
Required vendor information
VE02.03.01 The vendor shall provide a description of the cryptographic module describing the type of cryp-
tographic module. It will explain the rationale of the module type selection.
VE02.03.02 The vendor shall provide a specification of the cryptographic module identifying all hardware
and either software and firmware components of the cryptographic module as applicable.
Required test procedures
TE02.03.01 The tester shall verify that the documentation provided by the vendor identifies one of the mod-
ule types listed in AS02.03.
TE02.03.02 The tester shall review the specific documentation provided by the vendor, by identifying all
hardware and either software or firmware components (AS02.13 to AS02.16), to verify that the
cryptographic module is consistent with the type of the cryptographic module.

© ISO/IEC 2025 – All rights reserved
Table 8 — VE and TE of AS02.04
Types of cryptographic modules — levels 1, 2, 3 and 4
AS02.04 For hardware, firmware or hybrid firmware modules, the applicable physical security
and non-invasive security requirements specified in ISO/IEC 19790:2025, 7.7 and ISO/IEC
ISO/IEC
19790:2025, 7.8 shall apply.
19790:2025, 7.2.2
Required test procedures
This assertion is not separately tested.
6.2.3 Cryptographic boundary
6.2.3.1 Cryptographic boundary general requirements
Table 9 — VE and TE of AS02.05
Cryptographic boundary — levels 1, 2, 3 and 4
AS02.05 A cryptographic boundary shall consist of an explicitly defined perimeter (i.e. set of hardware,
software or firmware components) that establishes the boundary of all components of the
ISO/IEC
cryptographic module.
19790:2025, 7.2.3.1
Required vendor information
VE02.05.01 The vendor-provided documentation shall specify all components within the cryptographic
boundary.
Required test procedures
TE02.05.01 The tester shall review the vendor-provided documentation and inspect the cryptographic
module to verify that all the components specified in AS02.13 to AS02.16 are within the cryp-
tographic boundary.
TE02.05.02 The tester shall review the vendor-provided documentation and inspect the cryptographic
module to verify that there are no unidentified components which are not specified in AS02.13
to AS02.16 within the cryptographic boundary.
Table 10 — VE and TE of AS02.06
Cryptographic boundary — levels 1, 2, 3 and 4
AS02.06 The requirements of this document shall apply to all security functions, processes and compo-
nents within the module’s cryptographic boundary.
ISO/IEC
19790:2025, 7.2.3.1
Required test procedures
This assertion is not separately tested.
Table 11 — VE and TE of AS02.07
Cryptographic boundary — levels 1, 2, 3 and 4
AS02.07 The cryptographic boundary shall, at a minimum, encompass all security relevant securi-
ty functions, processes and components of a cryptographic module as defined in ISO/IEC
ISO/IEC
19790:2025, Clause 7.
19790:2025, 7.2.3.1
Required vendor information
VE02.07.01 The vendor shall provide a list of all the security relevant security functions, processes, and
components within the cryptographic boundary.
Required test procedures
TE02.07.01 The tester shall verify that the documentation provided by the vendor clearly identifies and
lists all the security relevant security functions, processes, and components of the module
within the cryptographic boundary.

© ISO/IEC 2025 – All rights reserved
Table 12 — VE and TE of AS02.08
Cryptographic boundary — levels 1, 2, 3 and 4
AS02.08 Non-security relevant security functions, processes or components which are used in ap-
proved services shall be implemented in a manner so as to not interfere or compromise the
ISO/IEC
approved operation of the cryptographic module.
19790:2025, 7.2.3.1
Required vendor information
VE02.08.01 The vendor-provided documentation shall list the non-security relevant functions used in an
approved service and justify that they are not interfering with the approved service of the
module.
Required test procedures
TE02.08.01 The tester shall review documentation and inspect the module to verify that the non-security
relevant functions do not interfere or compromise the approved service of the module.
TE02.08.02 The tester shall verify the correctness of any rationale provided by the vendor for not inter-
fering nor compromising the service. The burden of proof is on the vendor; if there is any
uncertainty or ambiguity, the tester shall ask the vendor to produce additional information as
needed.
Table 13 — VE and TE of AS02.09
Cryptographic boundary — levels 1, 2, 3 and 4
AS02.09 The defined name of a cryptographic module shall be representative of the composition of the
components within the cryptographic boundary and not representative of a larger composi-
ISO/IEC
tion or product.
19790:2025, 7.2.3.1
Required vendor information
VE02.09.01 The vendor shall provide the defined name of the module.
Required test procedures
TE02.09.01 The tester shall verify that the module name provided by the vendor is consistent with the
composition of the components within the cryptographic boundary.
TE02.09.02 The tester shall verify that the module name does not represent a composition of components
or functions that are not consistent with the composition of the components within the cryp-
tographic boundary.
Table 14 — VE and TE of AS02.10
Cryptographic boundary — levels 1, 2, 3 and 4
AS02.10 The cryptographic module shall have, at minimum, specific versioning information represent-
ing the distinct individual hardware and software or firmware components as applicable.
ISO/IEC
19790:2025, 7.2.3.1
Required vendor information
VE02.10.01 The vendor shall provide the versioning information of the module’s distinct individual hard-
ware and either software or firmware components.
Required test procedures
TE02.10.01 The tester shall verify that the versioning information represents the modules distinct individ-
ual hardware and either software or firmware components.

© ISO/IEC 2025 – All rights reserved
Table 15 — VE and TE of AS02.11
Cryptographic boundary — levels 1, 2, 3 and 4
AS02.11 The excluded hardware, software or firmware components shall be implemented in such a
manner to not interfere or compromise the approved secure operation of the cryptographic
ISO/IEC 19790:2025,
module.
7.2.3.1
Required vendor information
VE02.11.01 The vendor shall describe the excluded components of the module and justify that these com-
ponents will not interfere with the approved secure operation of the module.
VE02.11.02 The vendor-provided documentation shall provide the rationale for excluding each of the
components. The rationale shall describe how each excluded component, when working prop-
erly or when it malfunctions, shall not interfere with the approved secure operation of the
module. Rationale that can be acceptable, if adequately supported by documentation, includes
the following.
a) The component is not connected with security relevant components of the module
that would allow inappropriate transfer of SSPs, plaintext data, or other information
that could interfere with the approved secure operation of the module.
b) All information processed by the component is strictly for internal use of the module,
and does not in any way impact the correctness of control, status or data outputs.
Required test procedures
TE02.11.01 The tester shall review the documentation provided by the vendor to inspect that the ex-
cluded components within the cryptographic boundary will not interfere with the approved
secure operation of the module.
TE02.11.02 The tester shall verify the correctness of any rationale for exclusion provided by the vendor.
The burden of proof is on the vendor; if there is any uncertainty or ambiguity, the tester shall
ask the vendor to produce additional information as needed.
TE02.11.03 The tester shall manipulate (e.g. to cause the component to operate not as designed) the ex-
cluded components in a manner to cause incorrect operation of the excluded component. The
tester shall verify that the incorrect operation of the excluded component shall not interfere
with the approved secure operation of the module.
NOTE 1 Testing can rely on either code review, documentation, or both, if behavioural or
physical methods which cause the incorrect operation of the excluded component are in-
feasible or impractical for a given module. Behavioural methods include using a debugger,
code manipulator/injector, simulator, or another tool to manipulate data that can impact the
behaviour of an excluded component; physical methods include shorting/removing pins and
voltage manipulations. Testing is considered infeasible or impractical when such manip-
ulations are unders
...