ISO/IEC TS 20540:2025

Technical
Specification
ISO/IEC TS 20540
Second edition
Information security, cybersecurity
2025-05
and privacy protection — Testing
cryptographic modules in their field
Sécurité de l'information, cybersécurité et protection de la vie
privée — Test de modules cryptographiques dans leur domaine
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: +41 22 749 01 11
Email: copyright@iso.org
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 Abbreviated terms . 5
5 Document organization . 5
6 Developing, validating and field testing . 6
7 Cryptographic modules . 7
7.1 General .7
7.2 Types of cryptographic modules .7
7.2.1 General .7
7.2.2 Software module .8
7.2.3 Firmware module .8
7.2.4 Hardware module .8
7.2.5 Hybrid software module .8
7.2.6 Hybrid firmware module .8
7.3 Security requirements for cryptographic modules .9
7.3.1 General .9
7.3.2 Security level 1 .9
7.3.3 Security level 2 .10
7.3.4 Security level 3 .10
7.3.5 Security level 4 .11
7.4 Life-cycle assurance of cryptographic modules .11
7.5 Security policy of the module . . 12
7.5.1 General . 12
7.5.2 Cryptographic module specification . 12
7.5.3 Cryptographic module interfaces . 12
7.5.4 Roles, services, and authentication . 12
7.5.5 Software/firmware security . 13
7.5.6 Operational environment . 13
7.5.7 Physical security . 13
7.5.8 Non-invasive security . 13
7.5.9 Sensitive security parameters management.14
7.5.10 Self-tests . . .14
7.5.11 Life-cycle assurance .14
7.5.12 Mitigation of other attacks .14
7.6 Intended purpose or use of the validated cryptographic modules . 15
8 Application environment .15
8.1 Organizational security . 15
8.2 Architecture of the application environment .16
8.3 Application environments for the cryptographic modules .16
8.4 Security products with cryptographic modules .17
9 Field .18
9.1 Security requirements related to cryptographic modules for their field .18
9.1.1 General .18
9.1.2 Entropy sources .19
9.1.3 Audit mechanism .19
9.1.4 Physically unclonable function .19
9.2 Security assumptions for the field .19
9.2.1 General .19

© ISO/IEC 2025 – All rights reserved
iii
9.2.2 Security level 1 .19
9.2.3 Security level 2 . 20
9.2.4 Security level 3 .21
9.2.5 Security level 4 .21
10 How to select cryptographic modules .22
10.1 General . 22
10.2 Use policy. 23
10.3 Cryptographic module assurance .24
10.4 Interoperability.24
10.5 Selection of security rating for SSP protection.24
11 Principles for field testing .25
11.1 General . 25
11.2 Assumptions . 26
11.3 Field testing activities . 26
11.4 Competence for field testers .27
11.5 Use of validated evidence .27
11.6 Documentations .27
11.7 Field testing procedure .27
12 Recommendations for field testing .28
12.1 General . 28
12.2 Installation, configuration, and operation of the cryptographic module . 28
12.2.1 General . 28
12.2.2 Assessing installation of the cryptographic module . . 28
12.2.3 Assessing the configuration of the cryptographic module . 29
12.2.4 Assessing the correct operation of the cryptographic module . 30
12.3 Key management system . 30
12.4 Security requirements of authentication credentials .31
12.5 Availability of cryptographic modules .32
12.6 Potential residual vulnerabilities of cryptographic modules .32
12.7 Security toolkit for the application system of cryptographic modules . 33
12.8 Organization’s security policies . 33
13 Reporting the results of field testing .34
Annex A (informative) Examples of validated cryptographic modules lists .35
Annex B (informative) Security toolkit for application system of cryptographic modules in
their field .36
Annex C (informative) Checklist for field testing of cryptographic modules .40
Bibliography .44

© 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 second edition cancels and replaces the first edition (ISO/IEC TS 20540:2018), which has been
technically revised.
The main changes are as follows:
— the document has been restructured:
— 7.3 and 7.4 have been moved to 8.2;
— new Annex B has been created;
— technical changes have been introduced:
— reviewed and added terminology;
— aligned terminology with ISO/IEC 19790:2025;
— introduced security requirements for attestation, backdoor of the components and supply chain in
the field;
— introduced metaverse, IoT, big data and AI for the application environment.
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 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. Cryptographic modules are utilized within a security system to
protect sensitive information in their application environment.
The purpose of this document is to describe the recommendations, requirements and checklists which
help in the selection of cryptographic modules for deployment in a diversity of application environments.
This document is helpful for the user and the field tester to verify correct deployment in the application
environment.
Field testers determine the suitability and proper usage of a cryptographic module in its application
environment.
Cryptographic modules and their application environments are generally complex and complicated. When
cryptographic modules are deployed in an application environment and a field, a minor error or mistake
can affect the security of the whole field and application environment. It is important to perform the field
testing to ensure the proper usage of a cryptographic module in their field. This document identifies the
field testing by providing:
— a secure assessment of the cryptographic module installation, configuration and operation;
— inspecting the key management system, protection of authentication credentials, and public and critical
security parameters in the field;
— identifying cryptographic module vulnerabilities;
— checklists for the cryptographic algorithm policy, security guidance and regulation, security manager
requirements, security level for each of the 11 requirement areas, the strength of the security function, etc.;
— inspecting that the cryptographic module’s deployment satisfies the security requirements; and
— inspecting security toolkit for application system to help the user select security service in the field.
When using this document for field testing, it can be necessary to consult ISO/IEC 19790:2025; and
ISO/IEC 24759:2025.
© ISO/IEC 2025 – All rights reserved
vi
Technical Specification ISO/IEC TS 20540:2025(en)
Information security, cybersecurity and privacy protection —
Testing cryptographic modules in their field
1 Scope
This document provides recommendations, requirements and checklists which can be used to support the
specification and field testing of cryptographic modules in their field within an organization’s security
system. The cryptographic modules have an overall security rating commensurate with the four security
levels defined in ISO/IEC 19790:2025, to provide for:
— a wide spectrum of data sensitivity (e.g. low-value administrative data, million-dollar funds transfers,
life-protecting data, personal identity information, and sensitive information used by government), and
— a diversity of application environments (e.g. a guarded facility, an office, removable media, and a
completely unprotected location).
This document is limited to the security related to the cryptographic module. It does not include assessing
the security of the field or application environment. It does not define techniques for the identification,
assessment and acceptance of the organization’s operational risk.
This document applies to the field testers who perform the field testing for the cryptographic modules in
their field and the authorizing officials of cryptographic modules.
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 24759:2025, Information security, cybersecurity and privacy protection — Test requirements for
cryptographic modules
3 Terms and definitions
For the purposes of this document, the following terms and definitions 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.1
accreditation
administrative process whereby authority is granted for the operation of the cryptographic module in its
full field including all its non-IT parts
Note 1 to entry: The results of the field testing (3.13) process may be an input to the accreditation process.

© ISO/IEC 2025 – All rights reserved
3.2
administrator guidance
written material that is used by the crypto officer or any other administrative role for the correct
configuration, maintenance, and administration of the cryptographic module
[SOURCE: ISO/IEC 19790:2025, 3.2]
3.3
application environment
set of all software and hardware consisting of an operating system and hardware platform required for an
application, which will call a cryptographic module for services, to operate securely
Note 1 to entry: The application environment may be identical to the field (e.g. both the cryptographic module and
application are executing in the same environment).
3.4
assurance maintenance
certification body (3.5) management of validation listing (e.g., additions, modifications or removal)
following changes
3.5
certification body
third-party conformity assessment body operating a certification scheme
Note 1 to entry: A certification body can be non-governmental or governmental (with or without regulatory authority).
Note 2 to entry: A certification body that assesses conformance to ISO/IEC 19790:2025 is known as a validation
authority.
Note 3 to entry: A certification scheme is a system related to specified products, to which the same specified
requirements, specific rules and procedures apply.
[SOURCE: ISO/IEC 19790:2025, 3.18, modified — note 2 to entry has been modified for contextual reasons.]
3.6
competence
ability to apply knowledge and skills to achieve intended results
Note 1 to entry: It represents the set of knowledge and skills needed to carry out the job activities associated with one
or more roles in an employment position.
[SOURCE: ISO/IEC 17024:2012, 3.6, modified — note to entry has been added.]
3.7
critical security parameter
CSP
security related information whose unauthorized access, use, disclosure, modification and substitution can
cause a compromise of the security of a cryptographic module (3.9)
EXAMPLE Secret and private cryptographic key, authentication data or verifier data such as a password or
personal identification number.
Note 1 to entry: A CSP can be plaintext or encrypted.
[SOURCE: ISO/IEC 19790:2025, 3.29]
3.8
cryptographic algorithm
well-defined computational procedure that takes variable inputs, which may include cryptographic keys,
and produces an output
[SOURCE: ISO/IEC 19790:2025, 3.31, modified — note 1 to entry has been removed]

© ISO/IEC 2025 – All rights reserved
3.9
cryptographic module
CM
module
set of hardware, software, and/or firmware that implements security functions and are contained within
the cryptographic boundary
[SOURCE: ISO/IEC 19790:2025, 3.35, modified — CM has been added as a preferred term.]
3.10
cryptographic module security policy
precise specification of the security rules under which a cryptographic module (3.9) will operate, including
the rules derived from the requirements specified in ISO/IEC 19790:2025, Annex B and additional rules
imposed by the module or certification body (3.5)
[SOURCE: ISO/IEC 19790:2025, 3.36, modified — reference to ISO/IEC 19790 added in a contextual manner;
note 1 to entry removed.]
3.11
field
environment in which the cryptographic modules are installed, configured, operated and managed
3.12
field tester
individual assigned by an organization (3.18) to perform the field testing in accordance with the field testing
process (3.14)
3.13
field testing
activities to verify the correct installation, configuration and operation of a module and that it operates
securely in the field (3.11)
3.14
field testing process
set of procedures or activities to support determining the correct installation, configuration and operation
of a module and that it operates securely in the field (3.11)
3.15
non-administrator guidance
written material that is used by either the user (3.25), or any other non-administrative role for operating the
cryptographic module (3.9)
Note 1 to entry: The non-administrator guidance describes the security functions of the cryptographic module
and contains information and procedures for the secure use of the cryptographic module, including instructions,
guidelines, and warnings.
[SOURCE: ISO/IEC 19790:2025, 3.88]
3.16
operational environment
operating system (including virtual machine(s) and runtime environment where applicable,) and hardware
platform required for the cryptographic module (3.9) to operate
Note 1 to entry: This can include, where applicable, integrated circuits, processors, libraries, memory management,
process control, device drivers for hardware, power supplies and enclosures.
[SOURCE: ISO/IEC 19790:2025, 3.96]

© ISO/IEC 2025 – All rights reserved
3.17
operator
entity external to the cryptographic module (3.9) that exercises the module's services via the provided
interfaces
Note 1 to entry: In this definition entity means an individual (person), organization, device, process or another module.
[SOURCE: ISO/IEC 19790:2025, 3.98]
3.18
organization
entity specifying, deploying and operating a cryptographic module (3.9)
3.19
pre-field testing
field testing (3.12) performed by a vendor (3.27) during the development of a cryptographic module (3.9) or
on behalf of a certification body (3.5) during the validation according to ISO/IEC 19790:2025, for the intended
field of the organization
3.20
public security parameter
PSP
security related public information whose modification can cause a compromise of the security of a
cryptographic module (3.9)
EXAMPLE Public cryptographic keys, public key certificates, self-signed certificates, trust anchors, one-time
passwords associated with a counter and internally held date and time.
Note 1 to entry: A PSP is considered protected if it cannot be modified or if its modification can be determined by the
cryptographic module.
[SOURCE: ISO/IEC 19790:2025, 3.115]
3.21
random bit generator
RBG
device or algorithm that outputs a sequence of bits that appears to be statistically independent and unbiased
[SOURCE: ISO/IEC 19790:2025, 3.116]
3.22
security function
cryptographic algorithms together with modes of operation, such as block ciphers, stream ciphers,
symmetric or asymmetric key algorithms, message authentication codes, hash functions, random bit
generators, etc. or other security functions such as entity authentication, sensitive security parameter (3.23)
generation and establishment
[SOURCE: ISO/IEC 19790:2025, 3.126]
3.23
sensitive security parameter
SSP
critical security parameter (3.7) or public security parameter (3.20)
[SOURCE: ISO/IEC 19790:2025, 3.131]
3.24
supply chain
set of organizations with linked set of resources and processes, each of which acts as an acquirer, supplier, or
both to form successive supplier relationships established upon placement of a purchase order, agreement,
or other formal sourcing agreement
[SOURCE: ISO/IEC 27036-1:2021, 3.10, modified — notes to entry have been removed.]

© ISO/IEC 2025 – All rights reserved
3.25
user
operator (3.17) that accesses a cryptographic module (3.9) in order to perform general security services,
including cryptographic operations and other approved security function
[SOURCE: ISO/IEC 19790:2025, 3.154]
3.26
validated
assurance of tested conformance by a certification body (3.5)
[SOURCE: ISO/IEC 19790:2025, 3.155, modified — reference to "this document" removed for contextual
reasons.]
3.27
vendor
entity, group or association that submits the cryptographic module (3.9) for testing and validation
Note 1 to entry: The vendor has access to all relevant documentation and design evidence regardless whether they did
or did not design or develop the cryptographic module.
[SOURCE: ISO/IEC 19790:2025, 3.156]
4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
API application program interface
AVA assurance vulnerability assessment
AI Artificial Intelligence
CSP critical security parameter
IoT Internet of Things
PDA personal digital assistant
PSP public security parameter
RBG random bit generator
5 Document organization
Clause 6 describes the development, validation and field testing and the relationships with other key
stakeholders in the production, validation and operation of cryptographic modules.
Clause 7 specifies the types of cryptographic modules, security requirements, life-cycle assurance,
cryptographic module security policy requirements and guidance, and intended purpose that should be
satisfied by the cryptographic module’s compliance to ISO/IEC 19790:2025.
Clause 8 describes the application environment in which cryptographic modules are utilized and the security
requirements related to cryptographic modules for their application environment.
Clause 9 describes the field in which cryptographic modules are utilized and the security requirements
related to cryptographic modules for the environment of an organization.
Clause 10 provides guidance on how to select cryptographic modules in their field.

© ISO/IEC 2025 – All rights reserved
Clause 11 describes the principles for field testing, including the assumptions to be made testing activities
to be performed, expected competence requirements of field testers, use of evidences that has been gained
from the validation of cryptographic modules, documentation requirements for field testing, and procedures
for field testing.
Clause 12 describes the recommendations or requirements for field testing including:
— assessing the installation, configuration, and operation;
— identifying the residual vulnerabilities;
— inspecting the key management system;
— inspecting the security requirements of authentication credentials;
— assessing the availability of cryptographic modules;
— assessing the security toolkit of cryptographic modules; and
— checking the security policies.
Clause 13 describes how to report the results of field testing, describing the contents of a report giving the
results of field testing.
6 Developing, validating and field testing
This clause specifies the developing, validating and field testing of cryptographic modules. A vendor designs,
develops and manufactures a cryptographic module. The vendor may apply the cryptographic module for the
validation and may have the module validated by a certification body in support of a claim that the module is
compliant to ISO/IEC 19790:2025. The validated module may be utilized in the organization’s field.
NOTE For some organizations, there can be an organizational security policy such that the module validated by
a named certification body can be acquired by an organization for deployment in a security system or application
environment.
Figure 1 illustrates the scope of this document in context with a generalized life cycle of a cryptographic
module. It depicts both the development life cycle of the module by the vendor, and the life cycle of the
module in the organization’s environment.
The vendor starts with a risk assessment process (1-1 in Figure 1) to determine the security requirements
for cryptographic modules. This risk assessment, which is based on the intended environment of an
organization and the intended market, defines the security requirements of the modules for each specific
area in ISO/IEC 19790:2025;. Once defined, the vendor proceeds with the module's development which
includes the design (1-2 in Figure 1), implementation (1-3 in Figure 1) and testing processes (1-3 in Figure 1).
Typically, validation (2-1 in Figure 1) by a certification body, is initiated by the vendor, but validation (2-1 in
Figure 1) can also be initiated by an original equipment manufacturer, an integrator, or by the organization itself.
An organization performs a risk assessment (3-1 in Figure 1) and defines security requirements (3-2 in
Figure 1) for the environment of the organization. If this risk assessment is addressed, the organization
may procure a validated cryptographic module which satisfies the security requirements, and performs the
field-testing process (3-4 in Figure 1), before the module is deployed (3-6 in Figure 1). The cryptographic
modules reflected by their assurance maintenance (1-4, 2-2 in Figure 1) should be used in field testing.
The field-testing process, as shown in Figure 1, is performed to select (3-3 in Figure 1) a proper cryptographic
module for use in the specific environment of an organization. The result of the field-testing process may be
used to perform the organization’s accreditation (3-5 in Figure 1) of the cryptographic module.
The field-testing process is located between the validation and accreditation for the module. The validation
is performed by the certification body. The accreditation is performed by the organization. The scope of this
document is the field-testing process, shown in Figure 1 as a grey box.

© ISO/IEC 2025 – All rights reserved
Figure 1 — Process for developing, validating, field testing, accreditation, deploying and operation
of a cryptographic module
7 Cryptographic modules
7.1 General
This clause specifies the types of cryptographic modules, security requirements, life-cycle assurance,
cryptographic module security policy requirements and guidance, and intended purpose that are satisfied
when a cryptographic module is in compliance with ISO/IEC 19790:2025.
The vendor provides the cryptographic module security policy document and the required guidance that
is specified in ISO/IEC 19790:2025. The vendor may also provide other documentation, guidance, tools or
specifications that were not specified as part of the compliance with ISO/IEC 19790:2025.
7.2 Types of cryptographic modules
7.2.1 General
Cryptographic modules can take various forms of modules as illustrated in Figure 2, and contain various
kinds of security functions, different security function strengths, etc. Cryptographic modules may contain
the same algorithms with appropriate security strengths.
Figure 2 — Various types of cryptographic modules

© ISO/IEC 2025 – All rights reserved
The following cryptographic module types shall be defined by ISO/IEC 19790:2025: software cryptographic
module, firmware cryptographic module, hardware cryptographic module, and hybrid cryptographic
module. Precise descriptions of the types of cryptographic modules are given in ISO/IEC 19790:2025, 7.2.2,
and are reproduced below.
7.2.2 Software module
A software module is a module whose cryptographic boundary delimits the software exclusive component
(or multiple software components) that execute(s) in a modifiable operational environment. The computing
platform and operating system of the operational environment in which the software executes are external
to the defined software module boundary.
The maximum overall security rating of software module is security level 2.
7.2.3 Firmware module
A firmware module is a module whose cryptographic boundary delimits the firmware exclusive
component(s) that execute(s) in a limited or non-modifiable operational environment. The computing
platform and operating system of the operational environment in which the firmware executes are external
to the defined firmware module boundary but explicitly bound to the firmware module.
The maximum overall security rating of firmware module is security level 4.
7.2.4 Hardware module
A hardware module is a module whose cryptographic boundary is specified at a hardware perimeter.
Firmware which can also include an operating system, may be included within this hardware cryptographic
boundary.
The maximum overall security rating of hardware module is security level 4.
7.2.5 Hybrid software module
A hybrid software module is a module whose cryptographic boundary delimits the composite of a software
component that executes in a modifiable operational environment and a disjoint hardware component (i.e.
the software component is not contained within the cryptographic boundary of the hardware component).
The computing platform and operating system of the operational environment in which the software
executes are external to the cryptographic boundary of the hybrid software module.
The maximum overall security rating of hybrid software module is security level 2.
7.2.6 Hybrid firmware module
A hybrid firmware module is a module whose cryptographic boundary delimits the composite of a firmware
component that executes in a limited or non-modifiable operational environment and a disjoint hardware
component (i.e. the firmware component is not contained within the cryptographic boundary of the
hardware component). The computing platform and operating system of the operational environment in
which the firmware executes are external to the cryptographic boundary of the hybrid firmware module
but explicitly bound to the hybrid firmware module.
The maximum overall security rating of hybrid firmware cryptographic module is security level 4.

© ISO/IEC 2025 – All rights reserved
7.3 Security requirements for cryptographic modules
7.3.1 General
The security requirements for cryptographic modules are specified in ISO/IEC 19790:2025. There are 11
security areas in the security requirements. 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.
Four security levels are specified for each of the 11 requirement areas. Each security level offers an increase
in security over the preceding level. The cryptographic module is independently rated in each area. Several
areas provide for incre
...