ISO/IEC 19790:2025

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

This document specifies the security requirements for a cryptographic module utilized within a security system protecting sensitive information in Information and Communication Technologies (ICT). It defines four security levels for cryptographic modules to provide for a wide spectrum of data sensitivity and a diversity of application environments. This document specifies up to four security levels for each of the 11 requirement areas with each security level increasing security over the preceding level.

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

Le présent document spécifie les exigences de sécurité pour un module cryptographique utilisé dans un système de sécurité qui protège les informations sensibles dans les technologies de l’information et de la communication (TIC). Il définit quatre niveaux de sécurité pour les modules cryptographiques afin de couvrir un large éventail de sensibilités des données et une diversité d’environnements d’application. Le présent document spécifie jusqu’à quatre niveaux de sécurité pour chacun des 11 domaines d’exigences, chaque niveau de sécurité offrant une augmentation de la sécurité par rapport au niveau précédent.

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 19790:2012 - Information technology - Security techniques - Security requirements for cryptographic modules
• Effective Date: 06-Jun-2022

Overview

ISO/IEC 19790:2025 - Information security, cybersecurity and privacy protection - Security requirements for cryptographic modules - defines a comprehensive set of security requirements for cryptographic modules used to protect sensitive information in ICT systems. The third edition establishes a layered approach with four security levels across 11 requirement areas, enabling vendors, integrators and evaluators to match cryptographic-module assurance to data sensitivity and deployment environments.

Key topics and technical requirements

ISO/IEC 19790:2025 covers functional and assurance requirements that address the full lifecycle of a cryptographic module. Major topics include:

• Cryptographic module security levels: Four increasing levels of protection to support a wide spectrum of use cases and threat models.
• Cryptographic boundary and specification: Definition of module scope, supported cryptographic functions and operational behavior.
• Interfaces and protected paths: Rules for module interfaces, categories of interfaces, and requirements for plaintext trusted paths and protected internal paths.
• Roles, services and authentication: Role-based access, services exposed by the module, and authentication mechanisms for operators and administrators.
• Software/firmware security: Requirements for secure software/firmware design, update controls and protections that scale with security level.
• Operational environment: Requirements for modifiable and fixed environments, including OS constraints for higher assurance.
• Physical security and environmental failure protection: Embodiments and tests for physical tamper resistance and environmental failure handling.
• Non-invasive attack mitigation: Protections and test metrics against side-channel and other non-invasive attacks.
• Sensitive Security Parameter (SSP) management: Generation, entry, storage, zeroization and RNG requirements for keys and other SSPs.
• Self-tests and life‑cycle assurance: Pre-operational and conditional self-tests, configuration management, secure development and vendor testing.
• Mitigation of other attacks: Measures for residual risks and high-level attack vectors at advanced security levels.
• Normative annexes: Documentation requirements, approved functions, SSP generation methods, authentication mechanisms, test metrics and development/manufacturing guidance (Annexes A–G).

Applications and who uses this standard

ISO/IEC 19790:2025 is used by:

• Cryptographic module designers and manufacturers to design hardware and software modules to meet defined security levels.
• Security architects and system integrators selecting modules for systems that protect classified, regulated or sensitive data.
• Certification labs and evaluators performing assurance assessments against the standard.
• Procurement and compliance teams specifying module security requirements in contracts and regulatory submissions.

Typical applications include HSMs, secure elements, TPMs, smart cards, VPN concentrators, cloud KMS components and embedded IoT security modules.

Related standards

ISO/IEC 19790:2025 is part of the ISO/IEC JTC 1/SC 27 family addressing cryptographic techniques and information security. It is commonly implemented alongside complementary standards for information security management and cryptographic algorithms to produce an end-to-end security solution.

Keywords: ISO/IEC 19790:2025, cryptographic modules, security requirements, cryptographic boundary, sensitive security parameter, physical security, non-invasive attacks, self-tests, life-cycle assurance.

Standards Content (Sample)

International
Standard
ISO/IEC 19790
Third edition
Information security, cybersecurity
2025-02
and privacy protection — Security
requirements for cryptographic
modules
Sécurité de l’information, cybersécurité et protection de
la vie privée — Exigences de sécurité pour les 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 Abbreviated terms . 17
5 Cryptographic module security levels . .18
5.1 General .18
5.2 Security level 1 .18
5.3 Security level 2 .19
5.4 Security level 3 .19
5.5 Security level 4 . 20
6 Functional security objectives .21
7 Security requirements .21
7.1 General .21
7.2 Cryptographic module specification .24
7.2.1 Cryptographic module specification general requirements .24
7.2.2 Types of cryptographic modules .24
7.2.3 Cryptographic boundary .24
7.2.4 Module operations . 25
7.3 Cryptographic module interfaces .27
7.3.1 Cryptographic module interfaces general requirements .27
7.3.2 Types of interfaces .27
7.3.3 Categories of interfaces .27
7.3.4 Plaintext trusted path . 28
7.3.5 Protected internal paths . 29
7.4 Roles, services, and authentication . 29
7.4.1 Roles, services, and authentication general requirements . 29
7.4.2 Roles . 29
7.4.3 Services . 30
7.4.4 Authentication .31
7.5 Software/firmware security . 33
7.5.1 Software/firmware security general requirements . 33
7.5.2 Security level 1 . 34
7.5.3 Security level 2 . 34
7.5.4 Security levels 3 and 4. 35
7.6 Operational environment. 35
7.6.1 Operational environment general requirements . 35
7.6.2 Clause applicability . 36
7.6.3 Operating system requirements for modifiable operational environments .37
7.7 Physical security . 39
7.7.1 Physical security embodiments . 39
7.7.2 Physical security general requirements . 40
7.7.3 Physical security requirements for each physical security embodiment .42
7.7.4 Environmental failure protection/testing .43
7.7.5 Environmental failure protection features .43
7.7.6 Environmental failure testing procedures . 44
7.8 Non-invasive security . 44
7.8.1 Non-invasive security general requirements . 44
7.8.2 Security levels 1 and 2.45
7.8.3 Security level 3 .45
7.8.4 Security level 4 .45

© ISO/IEC 2025 – All rights reserved
iii
7.9 Sensitive security parameter management .45
7.9.1 Sensitive security parameter management general requirements .45
7.9.2 Random bit generators .45
7.9.3 Sensitive security parameter generation . 46
7.9.4 Automated sensitive security parameter establishment . 46
7.9.5 Sensitive security parameter entry and output . 46
7.9.6 Sensitive security parameter storage .47
7.9.7 Sensitive security parameter zeroization .47
7.10 Self-tests . 48
7.10.1 Self-test general requirements . 48
7.10.2 Security levels 3 and 4. 49
7.10.3 Pre-operational self-tests . 49
7.10.4 Conditional self-tests . 50
7.11 Life-cycle assurance . 53
7.11.1 Life-cycle assurance general requirements . 53
7.11.2 Configuration management . 53
7.11.3 Design . 54
7.11.4 Finite state model . 54
7.11.5 Development . 55
7.11.6 Vendor testing . 56
7.11.7 Delivery and operation . 56
7.11.8 Guidance documents . 58
7.12 Mitigation of other attacks . 58
7.12.1 Mitigation of other attacks general requirements . 58
7.12.2 Security levels 1, 2 and 3 . 58
7.12.3 Security level 4 .59
Annex A (normative) Documentation requirements .60
Annex B (normative) Cryptographic module security policy .66
Annex C (normative) Approved security functions .72
Annex D (normative) Approved sensitive security parameter generation and establishment
methods . 74
Annex E (normative) Approved authentication mechanisms .75
Annex F (normative) Approved non-invasive attack mitigation test metrics . 76
Annex G (normative) Module secure development, manufacturing and operation .77
Bibliography .78

© 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 third edition cancels and replaces the second edition (ISO/IEC 19790:2012), which has been technically
revised. It also incorporates the Technical Corrigendum ISO/IEC 19790:2012/Cor 1:2015.
The main changes are as follows:
— Clauses 3, 4 and 5 have been refined and updated to reflect changes in requirements in Clause 7;
— the language in Clause 6 has been refined and modernized;
— in Clause 7, the requirements have been reworded and rearranged for clarity. New requirements have
been added, and redundant or unnecessary requirements removed;
— Annexes A and B have been updated to reflect changes in requirements in Clause 7;
— Annexes C, D and E have been restructured and updated in line with standards published since the
previous edition, as well as with examples of rate limiting methods;
— Annex F has been updated with the inclusion of ISO/IEC 17825; and
— new Annex G on module secure development, manufacturing and operation has been added.
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.
This document 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.
The overall security rating or the security level within each area of a cryptographic module is chosen to
provide a level of security which is appropriate for the security requirements of the application and
environment in which the module is utilized and for the security services that the module is to provide.
The responsible authority in each organization should ensure that their computer and telecommunication
systems that utilize cryptographic modules provide an appropriate level of security for the given application
and environment. Since each authority is responsible for selecting which approved security functions are
appropriate for a given application, conformity with this document does not imply either full interoperability
or mutual acceptance of compliant products. The importance of security awareness and of making
information security a management priority should be communicated to all concerned.
Information security requirements vary for different applications; organizations should identify their
information resources and determine the sensitivity to and the potential impact of a loss by implementing
appropriate controls. Controls include, but are not limited to:
— physical and environmental controls;
— access controls;
— system security maintenance and patch management;
— backup and contingency plans; and
— information and data controls.
These controls are only as effective as the administration of appropriate security policies and procedures
within the operational environment.
Conformity with this document is not sufficient to ensure that a module is secure or that the security
provided by the module is sufficient and acceptable to the owner of the information that is being protected.

© ISO/IEC 2025 – All rights reserved
vi
Owners of sensitive information are expected to assess the risks to their information and to deploy
cryptographic modules as part of their overall risk mitigation plan, in order to mitigate specific identified
risks. The security policy of the module, which outlines its strengths and limitations, is expected to be
followed for any given deployment.

© ISO/IEC 2025 – All rights reserved
vii
International Standard ISO/IEC 19790:2025(en)
Information security, cybersecurity and privacy protection —
Security requirements for cryptographic modules
1 Scope
This document specifies the security requirements for a cryptographic module utilized within a security
system protecting sensitive information in Information and Communication Technologies (ICT). It defines
four security levels for cryptographic modules to provide for a wide spectrum of data sensitivity and a
diversity of application environments. This document specifies up to four security levels for each of the 11
requirement areas with each security level increasing security over the preceding level.
2 Normative references
There are no normative references in this document.
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
access control list
ACL
list of permissions to grant access to an object
3.2
administrator guidance
written material that is used by either the crypto officer (3.30) or any other administrative role (3.119) for
the correct configuration, maintenance, and administration of the cryptographic module (3.35)
3.3
automated
without manual (3.81) intervention or input (e.g. electronic means such as through a computer network)
3.4
approved data authentication technique
approved method providing assurance that the originator of the data is as claimed
Note 1 to entry: Approved data authentication techniques can include the use of an approved digital signature (3.43),
approved message authentication code (3.82) or approved keyed hash. Approved data authentication techniques are
specified in Annex C.
3.5
approved integrity technique
approved method of verifying whether or not data has been corrupted or modified
Note 1 to entry: Approved integrity techniques can be keyed, and can include an approved hash, a message
authentication code (3.82) or a digital signature (3.43) algorithm.

© ISO/IEC 2025 – All rights reserved
Note 2 to entry: Approved integrity techniques are specified in Annex C.
3.6
approved process
set of interrelated functions that includes at least one approved security function (3.8), and can include a
non-cryptographic function or non-approved security function (3.126) which are not security relevant to the
process’s operation
Note 1 to entry: A banking transaction, a compression service that includes encryption, etc.
3.7
approved service
service (3.136) which includes at least one approved security function (3.8) or process, and can include non-
security relevant (3.91) functions or processes
Note 1 to entry: Any security relevant (3.128) but non-approved security functions or processes are excluded from
approved services.
3.8
approved security function
security function (3.126) that is permitted for use in an approved service (3.7)
Note 1 to entry: Approved security functions are referenced in Annex C, which references Annex D and Annex E.
3.9
asymmetric algorithm
asymmetric technique
cryptographic algorithm (3.31) or technique that uses two related transformations: a public transformation
(defined by the public key (3.113)) and a private transformation (defined by the private key (3.110))
Note 1 to entry: The two transformations have the property that, given the public transformation, it is computationally
infeasible to derive the private transformation in a given limited time and with given computational resources.
3.10
attestation
process used to allow an entity (3.49) outside the boundary of the cryptographic module (3.35) to securely
verify the identity and other physical or logical characteristics of the cryptographic module using an
attestation record (3.11)
Note 1 to entry: An attestation conforms to the attestation standards and methods listed in Annex G.
3.11
attestation record
record that is generated by and retrievable from a cryptographic module (3.35) that supports the attester
service (3.12)
Note 1 to entry: The attestation record contains measurement details about software (3.140), firmware (3.58) or
hardware (3.64) components within the cryptographic module. Measurements can include hash values or copies of
software, firmware, or hardware components within the cryptographic module as well as configuration settings,
status information (3.145), registers, and fuse values.
3.12
attester service
service (3.136) that a cryptographic module (3.35) can support, which requires the module to support an
identity and the generation of an attestation record (3.11)
3.13
authentication data
data entered into the cryptographic module (3.35) by the operator (3.98), used to authenticate the operator
to the module
Note 1 to entry: Authentication data within the module are transient and are considered a temporary critical security
parameter (3.29).
© ISO/IEC 2025 – All rights reserved
Note 2 to entry: During an authentication attempt, authentication data are submitted to the module as:
a) a data input by the operator (e.g. a password (3.102), personal identification number (3.103), cryptographic key
(3.34) or equivalent); or
b) the result of a method/process involving operator related information (e.g. the signing of a challenge with a
private key (3.110), insertion of a physical key, processing of biometric (3.15) data).
3.14
authorized
when an operator (3.98) has authority to assume a specific role (3.119) and perform a corresponding set of
services
3.15
biometric
measurable, physical characteristic or personal behavioural trait used to recognize the identity, or verify
the claimed identity, of an operator (3.98)
3.16
bitstream
series of instructions parsed by a field programmable gate array (FPGA) on start-up to configure its
internal logic
Note 1 to entry: Bitstream is considered a highly customized form of executable code.
3.17
certificate
data of an entity, which is rendered unforgeable with the private or secret key of a certification authority (CA)
Note 1 to entry: This term should not to be confused with a module’s validation certificate issued by a certification
body (3.18).
3.18
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 this document 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 17065:2012, 3.12]
3.19
compromise
unauthorized disclosure, modification, substitution, or use of a critical security parameter (3.29), the
unauthorized modification or substitution of a public security parameter (3.115), or the loss of integrity
(3.72) or availability of the cryptographic module (3.35) itself, which can result in an unintended bypass of
security functions supported by the module
3.20
conditional self-test
test performed by a cryptographic module (3.35) when the conditions specified for the test occur
3.21
confidential
intending that information is not made available or disclosed to unauthorized entities

© ISO/IEC 2025 – All rights reserved
3.22
configuration management
discipline applying technical and administrative direction and surveillance to: identify and document the
functional and physical characteristics of a configuration item, control changes to those characteristics,
record and report change processing and implementation status, and verify compliance with specific
requirements
[SOURCE: ISO/IEC/IEEE 24765:2017 3.779.1, modified — in the definition "specified" has been replaced by
"specific".]
3.23
configuration management system
CMS
set of procedures and tools (including their documentation) used by a vendor (3.156) to develop and maintain
configurations of a cryptographic module (3.35) during its life cycle
3.24
control information
commands, signals (e.g. clock input/output), and control data (including function calls and manual (3.81)
control data such as from switches, buttons, and keyboards) used to direct or control the operation of a
cryptographic module (3.35) or disjoint components of a hybrid module (3.68)
3.25
control input
control information (3.24) that is input into a cryptographic module (3.35) or disjoint components of a hybrid
module (3.68)
3.26
control input interface
module interface(s) for which all control information (3.24) is input into the cryptographic module (3.35)
3.27
control output
control information (3.24) that is output from a cryptographic module (3.35) or disjoint component of a hybrid
module (3.68) to be used as control input (3.25) into another cryptographic module or disjoint component of
a hybrid module
3.28
control output interface
module interface(s) for which all control information (3.24) is output from the cryptographic module (3.35)
3.29
critical security parameter
CSP
security related information whose unauthorized access, use, disclosure, modification and substitution can
cause a compromise (3.19) of the security of a cryptographic module (3.35)
EXAMPLE Secret and private cryptographic key (3.34), authentication data (3.13) or verifier data (3.157) such as a
password (3.102) or personal identification number (3.103).
Note 1 to entry: A CSP can be plaintext (3.105) or encrypted.
3.30
crypto officer
role (3.119) taken by an operator (3.98) that accesses a cryptographic module (3.35) in order to perform
cryptographic initialization or management functions of a cryptographic module (e.g. module initialization,
management of sensitive security parameters (3.131) and auditing)

© ISO/IEC 2025 – All rights reserved
3.31
cryptographic algorithm
well-defined computational procedure that takes variable inputs, which can include a cryptographic key
(3.34), and produces an output
Note 1 to entry: Approved cryptographic algorithm standards are included in Annex C.
3.32
cryptographic boundary
explicitly defined perimeter that establishes the boundary of all components (i.e. set of hardware (3.64),
software (3.140) or firmware (3.58) components) of the cryptographic module (3.35)
3.33
cryptographic bypass
ability of a service (3.136) to partially or wholly circumvent a cryptographic function or process
3.34
cryptographic key
key
sequence of symbols that controls the operation of a cryptographic transformation
Note 1 to entry: A cryptographic transformation can include but is not limited to encipherment, decipherment,
cryptographic check value computation, signature generation, or signature verification.
3.35
cryptographic module
module
set of hardware (3.64) and either software (3.140) or firmware (3.58) that implements security functions and
are contained within the cryptographic boundary (3.32)
3.36
cryptographic module security policy
security policy
precise specification of the security rules under which a cryptographic module (3.35) will operate, including
the rules derived from the requirements of this document and additional rules imposed by the module or
certification body (3.18)
Note 1 to entry: See Annex B.
3.37
cryptographic operation
implementation of one or more cryptographic algorithm (3.31) in the cryptographic module (3.35)
3.38
data input interface
module interface(s) for which all input data (3.71) is input into the cryptographic module (3.35)
3.39
data output interface
module interface(s) for which all output data (3.99) is output from the cryptographic module (3.35)
3.40
data path
physical or logical route over which data passes
Note 1 to entry: A physical data path can be shared by multiple logical data paths.

© ISO/IEC 2025 – All rights reserved
3.41
debugging technique
method used to halt or alter the execution of the cryptographic module (3.35) to analyse malfunctions, using
interfaces or tools that can modify objects in memory (e.g. including executable code), in a way that it is
possible to bypass security controls
Note 1 to entry: Security controls are considered to be any feature of the executable code required to meet the
functional requirements of this document.
3.42
degraded operation
operation where a subset of the entire set of security functions, services or processes are either available or
configurable or both as a result of reconfiguration from an error state
3.43
digital signature
data appended to, or a cryptographic transformation of, a data unit that allows the recipient of the data unit
to prove the origin and integrity (3.72) of the data unit and protect against forgery (e.g. by the recipient)
3.44
direct entry
entry of a sensitive security parameter (3.131) or key component (3.74) into a cryptographic module (3.35),
using a device such as a keyboard or number pad
3.45
disjoint signature
signature used as part of a group of signatures, which together represent an entire set of code
3.46
electronic entry
entry of a sensitive security parameter (3.131) or key component (3.74) into a cryptographic module (3.35)
using electronic methods
Note 1 to entry: It is possible that the operator (3.98) of the cryptographic module (3.35) has no knowledge of the value
of the key being entered.
3.47
encompassing signature
single signature for an entire set of code
3.48
encrypted critical security parameter
encrypted CSP
critical security parameter (3.29) that has been encrypted using an approved security function (3.8)
3.49
entity
person, group, device or process
3.50
entropy
measure of the disorder, randomness or variability in a closed system
Note 1 to entry: The entropy of a random variable X is a mathematical measure of the amount of information provided
by an observation of X.
3.51
environmental failure protection
EFP
use of features to protect against a compromise (3.19) of the security of a cryptographic module (3.35) due to
environmental conditions outside of the module’s normal operating range

© ISO/IEC 2025 – All rights reserved
3.52
environmental failure testing
EFT
use of specific methods to provide reasonable assurance that the security of a cryptographic module (3.35)
will not be compromised by environmental conditions outside of the module’s normal operating range
3.53
error detection code
EDC
value computed from data and comprised of redundant bits of information designed to detect, but not
correct, unintentional changes in the data
3.54
executable form
form of the code in which the software (3.140) or firmware (3.58) is managed and controlled completely by
the operational environment (3.96) of the cryptographic module (3.35) and does not require compilation
3.55
factory state
default settings consistent with how the cryptographic module (3.35) left the factory
Note 1 to entry: It is possible that some sensitive security parameters (3.131) will be replaced during the lifetime of the
module and still be considered part of the factory state, such as a trust anchor.
3.56
fault injection
technique to induce operating behaviour changes in hardware (3.64), such as by the application of transient
voltages, radiation, laser or clock skewing techniques
3.57
finite state model
FSM
mathematical model of a sequential machine that is comprised of a finite set of input events, a finite set of
output events, a finite set of states, a function that maps states and input to output, a function that maps
states and inputs to states (a state transition function), and a specification that describes the initial state
3.58
firmware
code that is executed in a non-modifiable operational environment (3.90) or limited operational environment (3.77)
3.59
firmware module
cryptographic module (3.35) whose cryptographic boundary (3.32) delimits the firmware (3.58) exclusive files(s)
that execute(s) in a limited operational environment (3.77) or non-modifiable operational environment (3.90)
Note 1 to entry: The computing platform and operating system of the operational environment (3.96) in which the
firmware executes are external to the defined firmware module’s cryptographic boundary. However, the version of
the computing platform and the version of the operating system of the operational environment are explicitly bound
to the firmware module.
3.60
functional specification
high-level description of any port (3.107) or interface visible to the operator (3.98) and high-level description
of the behaviour of the cryptographic module (3.35)
3.61
functional testing
testing of the cryptographic module (3.35) functionality as defined by the functional specification (3.60)

© ISO/IEC 2025 – All rights reserved
3.62
hard
resistant to bending, and ability to resist penetration by another object; physically toughened; rugged,
and durable
3.63
hardness
relative resistance of a metal or other material to denting, scratching, or bending, including a material’s
ability to resist penetration by another object
3.64
hardware
physical equipment/elements
3.65
hardware module
cryptographic module (3.35) whose cryptographic boundary (3.32) is specified at a hardware (3.64) perimeter
Note 1 to entry: Firmware (3.58), which can also include an operating system, can be included within this hardware
cryptographic boundary.
Note 2 to entry: A bitstream (3.16) contains a series of instructions parsed by a field programmable gate array (FPGA)
on start-up to configure its internal logic. Bitstreams used to configure FPGAs in a hardware module or hardware
component are subject to the requirements of 7.4.3.4, 7.5, 7.10.3.2 and 7.10.4.4.
3.66
hash function
computationally efficient function mapping binary strings of arbitrary length to binary strings of fixed
length, such that it is computationally infeasible to find two distinct values that hash into a common value
3.67
hash value
output of a cryptographic hash function (3.66)
3.68
hybrid module
cryptographic module (3.35) whose cryptographic boundary (3.32) delimits the composite of a software
(3.140) or firmware (3.58) component and a disjoint hardware (3.64) component
Note 1 to entry: Hybrid firmware module (3.69) and hybrid software module (3.70) are the sub-categories of the
hybrid module.
3.69
hybrid firmware module
cryptographic module (3.35) whose cryptographic boundary (3.32) delimits the composite of a firmware
(3.58) component and a disjoint hardware (3.64) component (i.e. the firmware component is not contained
within the hardware component)
Note 1 to entry: The computing platform and operating system of the operational environment in which the firmware
executes are external to the defined hybrid firmware module’s cryptographic boundary but explicitly bound to the
hybrid firmware module.
3.70
hybrid software module
cryptographic module (3.35) whose cryptographic boundary (3.32) delimits the composite of a software
(3.140) component and a disjoint hardware (3.64) component (i.e. the software component is not contained
within the hardware component)
Note 1 to entry: The computing platform and operating system of the operational environment in which the software
executes are external to the defined hybrid software module’s cryptographic boundary.

© ISO/IEC 2025 – All rights reserved
3.71
input data
data (except control data entered via the control input interface (3.26)) that is input to and processed by a
cryptographic module (3.35), including plaintext (3.105) data, c
...

Norme
internationale
ISO/IEC 19790
Troisième édition
Sécurité de l’information,
2025-02
cybersécurité et protection de la vie
privée — Exigences de sécurité pour
les modules cryptographiques
Information security, cybersecurity and privacy protection —
Security requirements for cryptographic modules
Numéro de référence
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO/IEC 2025
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: [phone]
E-mail: [e-mail]
Web: www.iso.org
Publié en Suisse
© ISO/IEC 2025 – Tous droits réservés
ii
Sommaire Page
Avant-propos .v
Introduction .vii
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Abréviations . 19
5 Niveaux de sécurité des modules cryptographiques . 19
5.1 Généralités .19
5.2 Niveau de sécurité 1 . . 20
5.3 Niveau de sécurité 2 . 20
5.4 Niveau de sécurité 3 . 20
5.5 Niveau de sécurité 4 .21
6 Objectifs de sécurité fonctionnelle .22
7 Exigences de sécurité .22
7.1 Généralités . 22
7.2 Spécification du module cryptographique . 25
7.2.1 Exigences générales relatives à la spécification du module cryptographique . 25
7.2.2 Types de modules cryptographiques . 26
7.2.3 Frontière cryptographique . 26
7.2.4 Fonctionnements du module .27
7.3 Interfaces du module cryptographique . 29
7.3.1 Exigences générales relatives aux interfaces du module cryptographique . 29
7.3.2 Types d’interfaces . 29
7.3.3 Catégories d’interfaces . 29
7.3.4 Chemin de confiance en clair . 30
7.3.5 Chemins internes protégés .31
7.4 Rôles, services et authentification .31
7.4.1 Exigences générales en matière de rôles, de services et d’authentification .31
7.4.2 Rôles .32
7.4.3 Services .32
7.4.4 Authentification . 34
7.5 Sécurité logicielle/micrologicielle . 36
7.5.1 Exigences générales en matière de sécurité logicielle/micrologicielle . 36
7.5.2 Niveau de sécurité 1 . 36
7.5.3 Niveau de sécurité 2 .37
7.5.4 Niveaux de sécurité 3 et 4 . 38
7.6 Environnement opérationnel . 38
7.6.1 Exigences générales relatives à l’environnement opérationnel . 38
7.6.2 Applicabilité des paragraphes . 39
7.6.3 Exigences relatives au système d’exploitation pour les environnements
opérationnels modifiables . 40
7.7 Sécurité physique .42
7.7.1 Matérialisations de la sécurité physique .42
7.7.2 Exigences générales en matière de sécurité physique .43
7.7.3 Exigences de sécurité physique pour chaque matérialisation de sécurité physique . 46
7.7.4 Protection contre les défaillances environnementales/essais de défaillance
environnementale .47
7.7.5 Fonctionnalités de protection contre les défaillances environnementales .47
7.7.6 Procédures d’essai de défaillance environnementale .47
7.8 Sécurité non invasive . 48
7.8.1 Exigences générales en matière de sécurité non invasive . 48
7.8.2 Niveaux de sécurité 1 et 2 . 48

© ISO/IEC 2025 – Tous droits réservés
iii
7.8.3 Niveau de sécurité 3 . 48
7.8.4 Niveau de sécurité 4 . 49
7.9 Gestion des paramètres de sécurité sensibles . 49
7.9.1 Exigences générales relatives à la gestion des paramètres de sécurité sensibles . 49
7.9.2 Générateurs de bits aléatoires . 49
7.9.3 Génération de paramètres de sécurité sensibles . 49
7.9.4 Établissement automatisé de paramètres de sécurité sensibles . 50
7.9.5 Entrée et sortie de paramètres de sécurité sensibles . 50
7.9.6 Stockage des paramètres de sécurité sensibles .51
7.9.7 Abrogation des paramètres de sécurité sensibles .51
7.10 Auto-tests .52
7.10.1 Exigences générales relatives aux auto-tests .52
7.10.2 Niveaux de sécurité 3 et 4 . 53
7.10.3 Auto-tests pré-opérationnels . 53
7.10.4 Auto-tests conditionnels . 54
7.11 Assurance du cycle de vie .57
7.11.1 Exigences générales relatives à l’assurance du cycle de vie .57
7.11.2 Gestion de la configuration . 58
7.11.3 Conception . 58
7.11.4 Modèle à état fini . 58
7.11.5 Développement .59
7.11.6 Essais fournisseur .61
7.11.7 Livraison et fonctionnement.61
7.11.8 Guides (d’orientation).62
7.12 Atténuation des autres attaques . 63
7.12.1 Exigences générales relatives à l’atténuation des autres attaques . 63
7.12.2 Niveaux de sécurité 1, 2 et 3 . 63
7.12.3 Niveau de sécurité 4 . 63
Annexe A (normative) Exigences en matière de documentation .64
Annexe B (normative) Politique de sécurité du module cryptographique .71
Annexe C (normative) Fonctions de sécurité approuvées .77
Annexe D (normative) Méthodes approuvées de génération et d’établissement de paramètres
de sécurité sensibles .79
Annexe E (normative) Mécanismes d’authentification approuvés .80
Annexe F (normative) Mesures d’essai d’atténuation des attaques non invasives approuvées .81
Annexe G (normative) Développement, fabrication et fonctionnement sécurisés du module .82
Bibliographie .83

© ISO/IEC 2025 – Tous droits réservés
iv
Avant-propos
L'ISO (Organisation internationale de normalisation) et l’IEC (Commission électrotechnique internationale)
forment le système spécialisé de la normalisation mondiale. Les organismes nationaux membres de l'ISO ou
de l’IEC participent au développement de Normes internationales par l'intermédiaire des comités techniques
créés par l'organisation concernée afin de s'occuper des domaines particuliers de l'activité technique.
Les comités techniques de l'ISO et de l’IEC collaborent dans des domaines d'intérêt commun. D'autres
organisations internationales, gouvernementales et non gouvernementales, en liaison avec l'ISO et l’IEC,
participent également aux travaux.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document a
été rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir
www.iso.org/directives ou www.iec.ch/members_experts/refdocs).
L’ISO et l’IEC attirent l’attention sur le fait que la mise en application du présent document peut entraîner
l’utilisation d’un ou de plusieurs brevets. L’ISO et l’IEC ne prennent pas position quant à la preuve, à la
validité et à l’applicabilité de tout droit de brevet revendiqué à cet égard. À la date de publication du présent
document, L’ISO et l’IEC n'avaient pas reçu notification qu’un ou plusieurs brevets pouvaient être nécessaires
à sa mise en application. Toutefois, il y a lieu d’avertir les responsables de la mise en application du présent
document que des informations plus récentes sont susceptibles de figurer dans la base de données de
brevets, disponible à l'adresse www.iso.org/brevets et https://patents.iec.ch. L’ISO et l’IEC ne sauraient être
tenues pour responsables de ne pas avoir identifié tout ou partie de tels droits de propriété.
Les appellations commerciales éventuellement mentionnées dans le présent document sont données pour
information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions spécifiques
de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion de l'ISO aux
principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles techniques au commerce
(OTC), voir www.iso.org/iso/avant-propos. Pour l'IEC, voir www.iec.ch/understanding-standards.
Le présent document a été élaboré par le comité technique mixte ISO/IEC JTC 1, Technologies de l’information,
sous-comité SC 27, Sécurité de l’information, cybersécurité et protection de la vie privée.
Cette troisième édition annule et remplace la deuxième édition (ISO/IEC 19790:2012), qui a fait l’objet d’une
révision technique. Elle incorpore également le Rectificatif technique ISO/IEC 19790:2012/Cor 1:2015.
Les principales modifications sont les suivantes:
— les Articles 3, 4 et 5 ont été complétés et mis à jour afin d’intégrer les changements d’exigences de
l’Article 7;
— l’Article 6 a été complété et modernisé;
— les exigences de l’Article 7 ont été reformulées et réorganisées pour des raisons de clarté. De nouvelles
exigences ont été ajoutées et les exigences redondantes ou inutiles ont été supprimées;
— les Annexes A et B ont été mises à jour afin d’intégrer les changements d’exigences de l’Article 7;
— les Annexes C, D et E ont été restructurées et mises à jour en fonction des normes publiées depuis l’édition
précédente, et des exemples de méthodes de limitation du débit ont été ajoutés;
— l’Annexe F a été mis à jour en intégrant l’ISO/IEC 17825; et
— une nouvelle Annexe G relative au développement, à la fabrication et au fonctionnement sécurisés des
modules, a été ajoutée.
© ISO/IEC 2025 – Tous droits réservés
v
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes se
trouve à l’adresse www.iso.org/members.html et www.iec.ch/national-committees.

© ISO/IEC 2025 – Tous droits réservés
vi
Introduction
Dans le domaine des technologies de l’information, il est de plus en plus nécessaire d’utiliser des mécanismes
cryptographiques, tels que la protection des données contre la manipulation ou la divulgation non autorisée,
pour l’authentification d’entité et pour la non-répudiation. La sécurité et la fiabilité de ces mécanismes
dépendent directement des modules cryptographiques dans lesquels ils sont mis en œuvre.
Le présent document prévoit quatre niveaux qualitatifs croissants d’exigences de sécurité destinés à couvrir
un large éventail d’applications et d’environnements potentiels. Les techniques cryptographiques sont
identiques dans les quatre niveaux de sécurité définis dans le présent document. Les exigences de sécurité
couvrent des domaines relatifs à la conception et à la mise en œuvre d’un module cryptographique. Ces
domaines incluent:
— la spécification du module cryptographique;
— les interfaces du module cryptographique;
— les rôles, les services et l’authentification;
— la sécurité logicielle/micrologicielle;
— l’environnement opérationnel;
— la sécurité physique;
— la sécurité non invasive;
— la gestion des paramètres de sécurité sensibles;
— les auto-tests;
— l’assurance du cycle de vie; et
— l’atténuation des autres attaques.
La classification globale de sécurité ou le niveau de sécurité dans chaque domaine d’un module
cryptographique est choisi de façon à fournir un niveau de sécurité qui est approprié pour les exigences
de sécurité de l’application et de l’environnement dans lequel le module est utilisé, ainsi que pour les
services de sécurité que le module est appelé à fournir. Il convient que l’autorité responsable de chaque
organisation s’assure que ses systèmes informatiques et de télécommunications qui utilisent des
modules cryptographiques offrent un niveau de sécurité approprié pour l’application et l’environnement
concernés. Étant donné qu’il incombe à chaque autorité de choisir quelles fonctions de sécurité approuvées
sont appropriées pour une application donnée, la conformité au présent document n’implique ni une
interopérabilité complète ni une acceptation mutuelle des produits conformes. Il convient de sensibiliser
toutes les personnes concernées à l’importance de la sécurité et de la nécessité de faire de la sécurité de
l’information une priorité en matière de gestion.
Les exigences en matière de sécurité de l’information varient en fonction des applications; il convient que
les organisations identifient leurs ressources d’information et déterminent la sensibilité aux pertes et
leur impact potentiel en mettant en œuvre des mesures de sécurité appropriées. Les mesures de sécurité
incluent, sans s’y limiter:
— les mesures de sécurité physiques et environnementales;
— les contrôles d’accès;
— le maintien de la sécurité des systèmes et la gestion des correctifs;
— les plans de sauvegarde et de secours; et
— les mesures de sécurité des informations et des données.

© ISO/IEC 2025 – Tous droits réservés
vii
Ces mesures de sécurité ne sont efficaces que sous réserve de la mise en place de procédures et de politiques
de sécurité appropriées dans l’environnement opérationnel.
La conformité au présent document n’est pas suffisante pour garantir qu’un module est sûr ou que la sécurité
offerte par le module est suffisante et acceptable pour le propriétaire des informations qui sont protégées.
Il est attendu que les propriétaires d’informations sensibles évaluent les risques pour leurs informations
et déploient des modules cryptographiques dans le cadre de leur plan global d’atténuation des risques, afin
d’atténuer les risques spécifiques identifiés. Il est attendu que la politique de sécurité du module, qui donne
un bref aperçu de ses forces et faiblesses, soit appliquée pour tout déploiement donné.

© ISO/IEC 2025 – Tous droits réservés
viii
Norme internationale ISO/IEC 19790:2025(fr)
Sécurité de l’information, cybersécurité et protection de
la vie privée — Exigences de sécurité pour les modules
cryptographiques
1 Domaine d’application
Le présent document spécifie les exigences de sécurité pour un module cryptographique utilisé dans un
système de sécurité qui protège les informations sensibles dans les technologies de l’information et de
la communication (TIC). Il définit quatre niveaux de sécurité pour les modules cryptographiques afin de
couvrir un large éventail de sensibilités des données et une diversité d’environnements d’application. Le
présent document spécifie jusqu’à quatre niveaux de sécurité pour chacun des 11 domaines d’exigences,
chaque niveau de sécurité offrant une augmentation de la sécurité par rapport au niveau précédent.
2 Références normatives
Le présent document ne contient aucune référence normative.
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en normalisation,
consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse https:// www .electropedia .org/
3.1
liste de contrôle d’accès
ACL
liste des permissions autorisant l’accès à un objet
3.2
recommandations administrateur
contenu écrit qui est utilisé par le responsable cryptographie (3.30) et/ou d’autres rôles (3.119)
d’administrateurs pour la configuration, la maintenance et l’administration correctes du module
cryptographique (3.35)
3.3
automatisé
sans entrée ou intervention manuelle (3.81) (par exemple via des moyens électroniques, tels qu’un réseau
informatique)
3.4
technique d’authentification des données approuvée
méthode approuvée donnant l’assurance que l’expéditeur des données est bel et bien celui qui est déclaré
Note 1 à l'article: Les techniques d’authentification des données approuvées peuvent inclure l’utilisation d’une
signature numérique (3.43) approuvée, d’un code d’authentification de message (3.82) approuvé ou d’un hachage par clé
approuvé. Des techniques d’authentification des données approuvées sont spécifiées à l’Annexe C.

© ISO/IEC 2025 – Tous droits réservés
3.5
technique d’intégrité approuvée
méthode approuvée pour vérifier si des données ont été ou non corrompues ou modifiées
Note 1 à l'article: Les techniques d’intégrité approuvées peuvent utiliser des clés et inclure l’utilisation d’un hachage
approuvé, d’un code d’authentification de message (3.82) ou d’un algorithme de signature numérique (3.43).
Note 2 à l'article: Des techniques d’intégrité approuvées sont spécifiées à l’Annexe C.
3.6
processus approuvé
ensemble de fonctions interdépendantes qui comprend au moins une fonction de sécurité approuvée (3.8), et
peut inclure une fonction non cryptographique ou une fonction de sécurité (3.126) non approuvée qui ne sont
pas relatives à la sécurité du fonctionnement du processus
Note 1 à l'article: Une transaction bancaire, un service de compression qui inclut un chiffrement, etc.
3.7
service approuvé
service (3.136) comprenant au moins une fonction de sécurité approuvée (3.8) ou un processus de sécurité
approuvé, et pouvant inclure des fonctions ou processus non relatifs à la sécurité (3.91)
Note 1 à l'article: Les fonctions ou processus de sécurité relatifs à la sécurité (3.128) mais non approuvés sont exclus
des services approuvés.
3.8
fonction de sécurité approuvée
fonction de sécurité (3.126) dont l’utilisation dans un service approuvé (3.7) est autorisée
Note 1 à l'article: Les fonctions de sécurité approuvées sont référencées dans l’Annexe C, qui fait référence à l’Annexe D
et à l’Annexe E.
3.9
algorithme asymétrique
technique asymétrique
algorithme cryptographique (3.31) ou technique cryptographique qui utilise deux transformations liées: une
transformation publique (définie par la clé publique (3.113)) et une transformation privée (définie par la clé
privée (3.110))
Note 1 à l'article: Les deux transformations ont pour propriété que, compte tenu de la transformation publique, il est
impossible de trouver par calcul la transformation privée en un temps limité donné et avec des ressources de calcul
données.
3.10
attestation
processus utilisé pour permettre à une entité (3.49) située à l’extérieur de la frontière du module
cryptographique (3.35) de vérifier de manière sécurisée l’identité et d’autres caractéristiques physiques ou
logiques du module cryptographique en utilisant un enregistrement d’attestation (3.11)
Note 1 à l'article: Une attestation est conforme aux normes et méthodes d’attestation énumérées à l’Annexe G.
3.11
enregistrement d’attestation
enregistrement accessible et généré par un module cryptographique (3.35) qui prend en compte le service
d’attestation (3.12)
Note 1 à l'article: L’enregistrement d’attestation contient les détails de mesure des composants logiciels (3.140),
micrologiciels (3.58) ou matériels (3.64) dans le module cryptographique. Les mesures peuvent inclure des valeurs de
hachage ou des copies de composants logiciels, micrologiciels ou matériels dans le module cryptographique, ainsi que
des réglages de configuration, des informations d’état (3.145), des registres et des valeurs de fusibles.

© ISO/IEC 2025 – Tous droits réservés
3.12
service d’attestation
service (3.136) qu’un module cryptographique (3.35) peut prendre en charge et nécessitant la prise en charge
d’une identité et la génération d’un enregistrement d’attestation (3.11) par ce module
3.13
données d’authentification
données chargées dans le module cryptographique (3.35) par l’opérateur (3.98), servant à authentifier
l’opérateur vis-à-vis du module
Note 1 à l'article: Les données d’authentification à l’intérieur du module sont transitoires et considérées comme un
paramètre de sécurité critique (3.29) temporaire.
Note 2 à l'article: Au cours d’une tentative d’authentification, les données d’authentification sont soumises au module
sous forme:
a) d’entrée de données effectuée par l’opérateur (par exemple un mot de passe (3.102), une valeur d’identification
personnelle (3.103), une clé cryptographique (3.34) ou équivalent); ou
b) de résultat d’une méthode ou d’un processus impliquant des informations liées à l’opérateur (par exemple
la signature d’un challenge avec une clé privée (3.110), l’insertion d’une clé physique, le traitement de données
biométriques (3.15)).
3.14
autorisé
lorsqu’un opérateur (3.98) a le pouvoir d’endosser un rôle (3.119) spécifique et d’exécuter un ensemble de
services correspondant
3.15
biométrique
caractéristique physique ou trait comportemental personnel, mesurable, utilisé pour reconnaître l’identité
ou vérifier l’identité déclarée d’un opérateur (3.98)
3.16
flux binaire
série d’instructions analysées par une matrice prédiffusée programmable par l’utilisateur (FPGA) au
démarrage afin de configurer sa logique interne
Note 1 à l'article: Le flux binaire est considéré comme une forme de code exécutable fortement personnalisée.
3.17
certificat
données d’une entité qui sont rendues infalsifiables à l’aide de la clé privée ou secrète d’une autorité de
certification (CA)
Note 1 à l'article: Il convient de ne pas confondre ce terme avec un certificat de validation de module délivré par un
organisme de certification (3.18).
3.18
organisme de certification
organisme tierce partie d’évaluation de la conformité mettant en œuvre un programme de certification
Note 1 à l'article: Un organisme de certification peut être gouvernemental ou non gouvernemental (avec ou sans
pouvoir réglementaire).
Note 2 à l'article: Un organisme de certification qui évalue la conformité au présent document est qualifié d’autorité de
validation.
Note 3 à l'article: Un programme de certification est un système associé à des produits spécifiés, auquel s’appliquent
les mêmes exigences spécifiées, règles et procédures spécifiques.
[SOURCE: ISO/IEC 17065:2012, 3.12]

© ISO/IEC 2025 – Tous droits réservés
3.19
compromission
divulgation, modification, substitution ou utilisation non autorisée d’un paramètre de sécurité critique (3.29),
modification ou substitution non autorisée d’un paramètre de sécurité public (3.115), ou perte d’intégrité
(3.72) ou de disponibilité du module cryptographique (3.35) lui-même, qui peut entraîner le contournement
non prévu des fonctions de sécurité prises en charge par le module
3.20
auto-test conditionnel
test effectué par un module cryptographique (3.35) lorsque les conditions spécifiées pour le test sont réunies
3.21
confidentiel
souhait de ne pas mettre à disposition l’information et de ne pas la divulguer aux entités non autorisées
3.22
gestion de configuration
processus appliquant le pilotage et la surveillance techniques et administratives pour: identifier et
documenter les caractéristiques fonctionnelles et physiques d’un élément de configuration, contrôler les
modifications apportées à ces caractéristiques, enregistrer et rendre compte du traitement des modifications
et de leur état de mise en œuvre, et vérifier la conformité à des exigences spécifiques
[SOURCE: ISO/IEC IEEE 24765:2017 3.779.1, modifié — Dans la définition, le terme «spécifiées» a été
remplacé par «spécifiques».]
3.23
système de gestion de configuration
CMS
ensemble de procédures et d’outils (y compris leur documentation) utilisés par un fournisseur (3.156) pour
développer et maintenir des configurations d’un module cryptographique (3.35) tout au long de son cycle de vie
3.24
informations de contrôle
commandes, signaux (entrée/sortie d’horloge, par exemple) et données de contrôle (y compris les appels
de fonctions et les données de commandes manuelles (3.81) telles que celles provenant d’interrupteurs, de
boutons et de claviers) utilisés pour piloter ou contrôler le fonctionnement d’un module cryptographique
(3.35) ou de composants séparés d’un module hybride (3.68)
3.25
entrée de contrôle
informations de contrôle (3.24) qui sont entrées dans un module cryptographique (3.35) ou des composants
séparés d’un module hybride (3.68)
3.26
interface d’entrée de contrôle
interface(s) du module, par laquelle (lesquelles) toutes les informations de contrôle (3.24) sont entrées dans
le module cryptographique (3.35)
3.27
sortie de contrôle
informations de contrôle (3.24) qui sont issues d’un module cryptographique (3.35) ou d’un composant séparé
d’un module hybride (3.68) pour être utilisées comme une entrée de contrôle (3.25) dans un autre module
cryptographique ou un composant séparé d’un module hybride
3.28
interface de sortie de contrôle
interface(s) du module, par laquelle (lesquelles) toutes les informations de contrôle (3.24) sont sorties du
module cryptographique (3.35)
© ISO/IEC 2025 – Tous droits réservés
3.29
paramètre de sécurité critique
CSP
informations relatives à la sécurité dont l’accès, l’utilisation, la divulgation, la modification et la substitution
non autorisés peuvent entraîner une compromission (3.19) de la sécurité d’un module cryptographique (3.35)
EXEMPLE Clés cryptographiques (3.34) secrètes et privées, données d’authentification (3.13) ou données de
vérification (3.157) telles qu’un mot de passe (3.102) ou une valeur d’identification personnelle (3.103).
Note 1 à l'article: Un CSP peut être en clair (3.105) ou chiffré.
3.30
responsable cryptographie
rôle (3.119) assumé par un opérateur (3.98) qui accède à un module cryptographique (3.35) afin d’exécuter
les fonctions d’initialisation ou de gestion cryptographique d’un module cryptographique (initialisation du
module, gestion des paramètres de sécurité sensibles (3.131) et audit, par exemple)
3.31
algorithme cryptographique
procédure de calcul bien définie qui prend en entrée des variables, qui peuvent inclure une clé cryptographique
(3.34), et qui produit une sortie
Note 1 à l'article: Des normes relatives aux algorithmes cryptographiques approuvés sont spécifiées à l’Annexe C.
3.32
frontière cryptographique
périmètre clairement défini qui établit la frontière de tous les composants (c’est-à-dire l’ensemble des
composants matériels (3.64), logiciels (3.140) ou micrologiciels (3.58)) du module cryptographique (3.35)
3.33
contournement cryptographique
capacité d’un service (3.136) à contourner, en tout ou partie, une fonction ou un processus cryptographique
3.34
clé cryptographique
clé
suite de symboles qui commande le fonctionnement d’une transformation cryptographique
Note 1 à l'article: Une transformation cryptographique peut inclure, sans s’y limiter, le chiffrement, le déchiffrement,
le calcul de valeur de contrôle cryptographique, la génération de signatures ou la vérification de signatures.
3.35
module cryptographique
module
ensemble des matériels (3.64) et des logiciels (3.140) ou micrologiciels (3.58) qui mettent en œuvre des
fonctions de sécurité et qui sont contenus à l’intérieur de la frontière cryptographique (3.32)
3.36
politique de sécurité du module cryptographique
politique de sécurité
spécification précise des règles de sécurité sur la base desquelles un module cryptographique (3.35)
fonctionnera, y compris les règles dérivées des exigences du présent document et les règles supplémentaires
imposées par le module ou l’organisme de certification (3.18)
Note 1 à l'article: Voir l’Annexe B.
3.37
opération cryptographique
mise en œuvre d’un ou plusieurs algorithmes cryptographiques (3.31) dans le module cryptographique (3.35)

© ISO/IEC 2025 – Tous droits réservés
3.38
interface d’entrée de données
interface(s) du module, par laquelle (lesquelles) toutes les données d’entrée (3.71) sont entrées dans le module
cryptographique (3.35)
3.39
interface de sortie de données
interface(s) du module, par laquelle (lesquelles) toutes les données de sortie (3.99) sont sorties du module
cryptographique (3.35)
3.40
chemin de données
itinéraire physique ou logique emprunté par les données
Note 1 à l'article: Un chemin de données physique peut être partagé par plusieurs chemins de données logiques.
3.41
technique de débogage
méthode utilisée pour interrompre ou modifier l’exécution du module cryptographique (3.35) afin d’analyser
les dysfonctionnements, en utilisant des interfaces ou des outils qui peuvent modifier des objets en mémoire
(incluant par exemple du code exécutable), d’une façon qui permet de contourner les mesures de sécurité
Note 1 à l'article: Les fonctionnalités du code exécutable requises pour satisfaire aux exigences fonctionnelles du
présent document sont considérées comme des mesures de sécurité.
3.42
fonctionnement dégradé
fonctionnement dans lequel un sous-ensemble de l’ensemble complet de fonctions, services ou processus de
sécurité est soit disponible soit configurable, ou les deux, en raison d’une reconfiguration à partir d’un état
d’erreur
3.43
signature numérique
données ajoutées à une unité de données, ou transformation cryptographique d’une unité de données,
permettant à un destinataire de prouver l’origine et l’intégrité (3.72) de l’unité de données et protégeant
contre la contrefaçon (par le destinataire, par exemple)
3.44
saisie directe
saisie d’un paramètre de sécurité sensible (3.131) ou d’un composant de clé (3.74) dans un module
cryptographique (3.35), à l’aide d’un dispositif tel qu’un clavier ou un pavé numérique
3.45
signature disjointe
signature utilisée comme partie d’un groupe de signatures qui, collectivement, représentent un ensemble de
code complet
3.46
saisie électronique
saisie d’un paramètre de sécurité sensible (3.131) ou d’un composant de clé (3.74) dans un module
cryptographique (3.35) à l’aide de méthodes électroniques
Note 1 à l'article: Il est possible que l’opérateur (3.98) du module cryptographique (3.35) n’ait aucune connaissance de
la valeur de la clé saisie.
3.47
signature englobante
signature unique pour un ensemble de code complet

© ISO/IEC 2025 – Tous droits réservés
3.48
paramètre de sécurité critique chiffré
CSP chiffré
paramètre de sécurité critique (3.29) qui a été chiffré en utilisant une fonction de sécurité approuvée (3.8)
3.49
entité
personne, groupe, dispositif ou processus
3.50
entropie
mesure du désordre, du caractère aléatoire ou de la variabilité d’un système fermé
Note 1 à l'article: L’entropie d’une variable aléatoire X est une mesure mathématique de la quantité d’informations
fournies par une observation de X.
3.51
protection contre les défaillances environnementales
EFP
utilisation de fonctionnalités destinées à protéger contre une compromission (3.19) de la sécurité d’un
module cryptographique (3.35) due à des conditions environnementales situées en dehors de la plage de
fonctionnement normale du module
3.52
essai de défaillance environnementale
EFT
utilisation de méthodes spécifiques dans le but de fournir une assurance raisonnable que la sécurité d’un
module cryptographique (3.35) ne sera pas compromise par des conditions environnementales situées en
dehors de la plage de fonctionnement normale du module
3.53
code détecteur d’erreurs
EDC
valeur calculée à partir de données et composée de bits d’information redondants, conçue pour détecter,
sans les corriger, les modifications involontaires des données
3.54
forme exécutable
forme du code dans laquelle le logiciel (3.140) ou le micrologiciel (3.58) est intégralement géré et contrôlé par
l’environnement opérationnel (3.96) du module cryptographique (3.35) et qui ne nécessite pas de compilation
3.55
état d’usine
réglages par défaut identiques à ceux du module cryptographique (3.35) en sortie d’usine
Note 1 à l'article: Il se peut que certains paramètres de sécurité sensibles (3.131) soient remplacés au cours de la durée
de vie du module tout en étant encore considérés comme faisant partie de l’état d’usine (une ancre de confiance, par
exemple).
3.56
injection de fautes
technique destinée à induire des changements de comportement opérationnel du matériel (3.64), telle que
l’application de tensions transitoires, d’un rayonnement, de laser ou de techniques de décalage d’horloge
3.57
modèle à état fini
FSM
modèle mathématique d’une machine séquentielle, composé d’un ensemble fini d’événements d’entrée,
d’un ensemble fini d’événements de sortie, d’un ensemble fini d’états, d’une fonction qui relie les états et
les entrées aux sorties, d’une fonction qui relie les états et les entrées aux états (une fonction de transition
d’état) et d’une spécification qui décrit l’état initial

© ISO/IEC 2025 – Tous droits réservés
3.58
micrologiciel
code qui est exécuté au sein d’un environnement opérationnel non modifiable (3.90) ou d’un environnement
opérationnel limité (3.77)
3.59
module micrologiciel
module cryptographique (3.35) dont la frontière crypt
...