ISO 13491-1:2024

International
Standard
ISO 13491-1
Fourth edition
Financial services — Secure
2024-07
cryptographic devices (retail) —
Part 1:
Concepts and requirements
Services financiers — Dispositifs cryptographiques de sécurité
(services aux particuliers) —
Partie 1: Concepts et exigences
Reference number
© ISO 2024
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
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 4
5 Secure cryptographic device concepts . 5
5.1 General .5
5.2 Hardware management devices .5
5.3 Secure cryptographic device types .6
5.3.1 General types .6
5.3.2 Secure cryptographic device components .6
5.3.3 Hardware security module .7
5.3.4 Key loading devices .10
5.4 Attack scenarios .10
5.4.1 General .10
5.4.2 Penetration .10
5.4.3 Monitoring .10
5.4.4 Manipulation .11
5.4.5 Modification . . .11
5.4.6 Substitution.11
5.5 Defence measures .11
5.5.1 General .11
5.5.2 Device characteristics . 12
5.5.3 Device management . 12
5.5.4 Environment . 13
6 Requirements for device security characteristics .13
6.1 General . 13
6.2 Physical security requirements for secure cryptographic devices . 13
6.3 Tamper-evident requirements .14
6.3.1 General .14
6.3.2 Substitution.14
6.3.3 Penetration .14
6.3.4 Modification . . .14
6.3.5 Monitoring .14
6.4 Tamper-resistant requirements . .14
6.4.1 General .14
6.4.2 Penetration .14
6.4.3 Modification . . . 15
6.4.4 Monitoring . 15
6.4.5 Substitution or removal . 15
6.5 Tamper-responsive requirements . 15
6.5.1 General . 15
6.5.2 Penetration . 15
6.5.3 Modification . . . 15
6.6 Logical security requirements for SCDs and HMDs .16
6.6.1 General .16
6.6.2 Dual control .16
6.6.3 Unique key per device .16
6.6.4 Assurance of genuine device . .16
6.6.5 Design of functions .16
6.6.6 Use of cryptographic keys .17
6.6.7 Sensitive device states .17

iii
6.6.8 Multiple cryptographic relationships .17
6.6.9 Secure device software authentication.17
7 Requirements for device management . 17
7.1 General .17
7.2 Life cycle phases .18
7.3 Life cycle protection requirements .19
7.3.1 General .19
7.3.2 Manufacturing phase . 20
7.3.3 Post-manufacturing phase. 20
7.3.4 Commissioning (initial financial key loading) phase . 20
7.3.5 Inactive operational phase . 20
7.3.6 Active operational phase (use) .21
7.3.7 Decommissioning (post-use) phase.21
7.3.8 Repair phase .21
7.3.9 Destruction phase . 22
7.4 Life cycle protection methods . 22
7.4.1 Manufacturing . 22
7.4.2 Post-manufacturing phase. 22
7.4.3 Commissioning (initial financial key loading) phase . 23
7.4.4 Inactive operational phase . 23
7.4.5 Active operational (use) phase . 23
7.4.6 Decommissioning phase .24
7.4.7 Repair .24
7.4.8 Destruction.24
7.5 Accountability .24
7.6 Device management principles of audit and control . 25
Bibliography .27

iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
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 ISO 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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes 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 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. ISO 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.
This document was prepared by Technical Committee ISO/TC 268, Financial services, Subcommittee SC 2,
Financial Services, security.
This fourth edition cancels and replaces the third edition (ISO 13491-1:2016), which has been technically
revised.
The main changes are as follows:
— revision for classes of secure cryptographic devices (SCDs);
— updated life cycle guidance.
A list of all parts in the ISO 13491 series can be found on the ISO website.
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.

v
Introduction
The ISO 13491 series describes both the physical and logical characteristics and the management of the
secure cryptographic devices (SCDs) used to protect messages, cryptographic keys and other sensitive data
used in a retail financial services environment.
This document contains the security requirements for SCDs. ISO 13491-2 is a tool for measuring compliance
against these requirements. It provides a checklist of:
— characteristics that a device has to possess;
— how devices have to be managed;
— characteristics of the operational environments.
The security of retail electronic payment systems is largely dependent upon the security of these
cryptographic devices. This security is based upon the premise that computer files can be accessed and
manipulated, communications lines can be tapped and authorized data or control inputs into system
equipment can be replaced with unauthorized inputs. When personal identification numbers (PINs), message
authentication codes (MACs), cryptographic keys and other sensitive data are processed, there is a risk of
tampering or other compromise to disclose or modify such data. The risk of financial loss is reduced through
the appropriate use of cryptographic devices that have proper characteristics and are properly managed.
Appropriate device characteristics are necessary to ensure that the device has the proper operational
capabilities and provides adequate protection for the data it contains. Appropriate device management is
necessary to ensure that the device is legitimate, that it has not been modified in an unauthorized manner
(e.g. by bugging) and that any sensitive data placed within the device (e.g. cryptographic keys) has not been
subject to disclosure or change.
Absolute security is not achievable in practical terms. Cryptographic security depends upon each life cycle
phase of the SCD and the complementary combination of appropriate management procedures and secure
cryptographic characteristics. These management procedures implement preventive measures to reduce the
opportunities for breaches of SCD security. The aim is for a high probability of detection of any unauthorized
access to sensitive or confidential data in cases where device characteristics fail to prevent or detect the
security compromise.
vi
International Standard ISO 13491-1:2024(en)
Financial services — Secure cryptographic devices (retail) —
Part 1:
Concepts and requirements
1 Scope
This document specifies the security characteristics for secure cryptographic devices (SCDs) based on the
cryptographic processes defined in the ISO 9564 series, ISO 16609 and ISO 11568.
This document states the security characteristics concerning both the operational characteristics of SCDs
and the management of such devices throughout all stages of their life cycle.
This document does not address issues arising from the denial of service of an SCD.
This document does not address software services that use multi-party computation (MPC) to achieve some
security objectives and, relying on these, offer cryptographic services.
NOTE These are sometimes called “soft” or software hardware security modules (HSMs) in common language,
which is misleading and does not correspond to the definition of HSM in this document.
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 11568, Financial services — Key management (retail)
ISO 13491-2:2023, Financial services — Secure cryptographic devices (retail) — Part 2: Security compliance
checklists for devices used in financial transactions
ISO/IEC 18031, Information technology — Security techniques — Random bit generation
NIST SP 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators
NIST SP 800-90B, Recommendation for the Entropy Sources Used for Random Bit Generation
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
audit
evaluates compliance with an evaluation on behalf of an evaluation agency

3.2
auditor
person who conducts an audit (3.1)
3.3
attack
attempt by an adversary on the device to obtain or modify sensitive data (3.20) or a service they are not
authorized to obtain or modify
3.4
controller
entity responsible for the secure management of a secure cryptographic device (SCD) (3.18)
3.5
derived unique key per transaction
DUKPT
key management method that uses a unique key for each transaction and prevents the disclosure of any past
key used by the transaction originating secure cryptographic device (SCD) (3.18)
[SOURCE: ISO 11568:2023, 3.35]
3.6
device compromise
successful defeat of the physical or logical protections provided by the secure cryptographic device (SCD)
(3.18), resulting in the potential disclosure of sensitive data (3.20) or unauthorized use of the SCD
3.7
device security
security of the secure cryptographic device (SCD) (3.18) related to its characteristics only, without reference
to a specific operational environment (3.15)
3.8
device management
processes, including procedures, controlling the access to and use of the device
Note 1 to entry: These processes can vary depending on the deployed environment.
3.9
dual control
process of utilizing two or more separate individuals operating in concert to protect sensitive functions
(3.21) or sensitive information (3.20) whereby no single individual is able to use the function or access all the
information alone
Note 1 to entry: A cryptographic key is an example of the type of material protected by dual control.
[SOURCE: ISO 11568:2023, 3.39, modified — Note 2 to entry deleted.]
3.10
financial key
cryptographic key used to protect financial transaction data
EXAMPLE Entity’s public key used for mutual authentication with the payment terminal, initial derived unique
key per transaction (DUKPT) key, terminal master key, personal identification number (PIN) encryption key.
3.11
hardware management device
HMD
non-secure cryptographic device (SCD) (3.18), typically a dedicated integrated circuit card (ICC), with
security features similar to an SCD but lacking tamper-response characteristics (3.25), which provides a set
of cryptographic services in support of the management of SCDs
Note 1 to entry: HMDs are subject to additional environment controls (see 5.2) due to their limited security features.

Note 2 to entry: Cryptographic services can include key generation, secure storage of key shares and key components,
cryptogram creation and signature generation.
3.12
hardware security module
HSM
secure cryptographic device (SCD) (3.18) that provides a set of secure cryptographic services
Note 1 to entry: Secure cryptographic services can include key generation, cryptogram creation, personal identification
number (PIN) translation and certificate signing.
3.13
key loading device
KLD
secure cryptographic device (SCD) (3.18) that loads keys into other SCDs
3.14
logical security
ability of a device to withstand attacks (3.3) through its functional interface
3.15
operational environment
environment in which the secure cryptographic device (SCD) (3.18) is operated, i.e. the system of which it is
part, the location where it is placed, the persons operating and using it and the entities communicating with it
3.16
physical security
ability of a device to withstand attacks (3.3) against its physical construction, including exploitation of
physical characteristics such as electromagnetic emissions and power fluctuations, the analysis of which
can lead to side-channel attacks
3.17
public key infrastructure
PKI
structure of hardware, software, people, processes and policies that employs digital signature technology
to facilitate a verifiable association between the public component of an asymmetric public key pair with a
specific subscriber that possesses the corresponding private key
Note 1 to entry: The public key may be provided for digital signature verification, authentication of the subject in
communication dialogues, and/or for message encryption key exchange or negotiation
[SOURCE: ISO 21188:2018, 3.48]
3.18
secure cryptographic device
SCD
device that provides physically and logically protected cryptographic services and storage, and which can
be integrated into a larger system, such as an automated teller machine (ATM) or point-of-sale terminal
EXAMPLE Personal identification number (PIN) entry device (PED), hardware security module (HSM) (3.12).
3.19
security scheme
configuration that supports the secure status of the device
3.20
sensitive data
sensitive information
data which need to be protected against unauthorized disclosure, alteration or destruction
EXAMPLE Status information, cryptographic key, personal identification number (PIN).

3.21
sensitive function
function which is accessible when the device is in a sensitive state (3.22)
3.22
sensitive state
device condition that provides access to the secure operator interface, such that it can only be entered when
the device is under dual control (3.9)
3.23
tamper-evident characteristic
characteristic that provides evidence that an attack (3.3) has been attempted
3.24
tamper-resistant characteristic
characteristic that provides passive physical protection against an attack (3.3)
3.25
tamper-response characteristic
characteristic that provides an active response to the detection of an attack (3.3)
4 Abbreviated terms
API application programming interface
ATM automated teller machine
DUKPT derived unique key per transaction
EPP encrypting PIN pad
HMD hardware management device
HSM hardware security module
KLD key loading device
MAC message authentication code
MPC multi-party computation
PED PIN entry device
PIN personal identification number
PKI public key infrastructure
POS point of sale
SCD secure cryptographic device
SCR secure card reader
SCRP SCR with PIN function
5 Secure cryptographic device concepts
5.1 General
Cryptography is used in retail financial services to help ensure the following objectives:
a) the integrity and authenticity of sensitive data (e.g. by using a MAC over transaction details);
b) the confidentiality of secret information (e.g. by encrypting customer PINs);
c) the confidentiality, integrity and authenticity of cryptographic keys;
d) the security of other sensitive operations (e.g. PIN verification).
To ensure that these objectives are met, the following threats to the security of the cryptographic processing
shall be countered:
— unauthorized use, disclosure or modification of cryptographic keys and other sensitive data;
— unauthorized use or modification of cryptographic services.
A secure cryptographic device provides a defined set of cryptographic functions, access controls and secure
key storage. SCDs are employed to protect against these threats. The requirements of this document pertain
to the SCD and not the system in which the SCD might be integrated. However, it is important to analyse the
interfaces between the SCD and the remainder of the system to ensure that the SCD will not be compromised.
Since absolute security is not achievable in practical terms, it is not realistic to describe an SCD as being
“tamper proof” or “physically secure”. With enough cost, effort and skill, virtually any security scheme can
be defeated. Furthermore, as technology continues to evolve, new techniques might be developed to attack a
security scheme that was previously believed to be immune to feasible attack. Therefore, it is more realistic
to categorize an SCD as possessing a degree of tamper protection where an acceptable degree is one that is
deemed adequate to deter any attack envisaged as feasible during the operational life of the device, taking
into account the equipment, skills and other costs to the adversary in mounting a successful attack and the
financial benefits that the adversary could realize from such an attack.
Security of retail payment systems includes the physical and logical aspects of device security, the security
of the operational environment and management of the device. These factors establish jointly the security of
the devices and the applications in which they are used. The security needs are derived from an assessment
of the risks arising from the intended applications.
The required security characteristics will depend on the intended application and operational environment
and on the attack types that need to be considered. A risk assessment should be made as an aid to selecting
the most appropriate method of evaluating the security of the device. The results are then assessed in order
to accept the devices for a certain application and environment.
5.2 Hardware management devices
Some key management activities necessitate the use of non-SCD devices where their form factors have
inherent limitations preventing them from meeting some SCD security requirements, especially tamper-
responsiveness. These limitations have associated security risks which shall be addressed by restricted
usage and additional controls. These devices are hardware management devices (HMDs).
Examples of HMDs include, but are not limited to:
a) smart cards used for component or share transport or storage;
b) smart cards containing public or private key pair(s) used to facilitate management of HSMs;
c) devices used to authorize or enable key management functions.
HMDs shall only be used in cases where the compromise of a single HMD would not compromise keys or
secrets not held within that HMD.

An HMD shall be stored in an environment that meets at least the criteria of a minimally controlled
environment as identified in ISO 13491-2, with additional controls providing reasonable assurance that
any unauthorized access to the device can be detected. Because the device cannot respond to an attack, the
additional controls minimize the probability of unauthorized modifications.
NOTE 1 An SCD can be used for the same purposes as an HMD (e.g. key loading to another SCD).
NOTE 2 General-purpose smart cards are usually certified in accordance with the common criteria methodology
(see the ISO/IEC 15408 series), which specifies different levels of evaluation assurance level (typically EAL 4+).
5.3 Secure cryptographic device types
5.3.1 General types
SCD types are broadly considered in this document to aid description of the different security considerations
for each class of SCD. The types of SCDs considered in the following subclauses are:
a) SCD components (PED, EPP, SCR, SCRP);
b) HSM (single-tenant, multi-tenant, hosted or cloud);
c) KLD;
d) smart cards.
Financial terminals, appliances that include one or more SCD components, are commonly called by the
following names, some of which are also known as “payment terminals”:
— ATM;
— point of interaction (POI);
— unattended payment terminal (UPT).
A financial terminal consists of a number of components, which can include PED, printer, communications
devices, customer–merchant interface, acquirer application, integrated circuit (IC) card reader and magnetic
stripe reader. These components may be configured in various fashions, dependent upon requirements.
Those components of a financial terminal that provide cryptographic services and/or any services involved
in requesting, reception and/or processing of the cardholder PIN shall collectively meet the requirements
of an SCD. The components which process other data (e.g. the customer primary account number (PAN))
received from the payment instrument should be SCDs.
NOTE They can also be required by local regulations to be SCDs.
While financial terminals commonly include one or more SCD components which are considered in this
document, financial terminals are not SCDs under the definition used in this document.
5.3.2 Secure cryptographic device components
The following SCD components, which are commonly used in financial terminals, are considered:
a) PED: A device providing for the secure entry of PINs.
b) EPP: An approved device which is a component of a terminal that provides secure PIN entry and
cryptographic services to that terminal.
c) SCR: A device with the primary function of reading cards and the added feature of supporting
cryptographic function.
d) SCRP: Both SCR and SCRP are secure card readers which evaluate as SCDs (the “P” indicates that the
device can perform PIN management functions such as PIN block formation but neither device has PIN
entry capability, nor can they perform as financial terminals).
5.3.3 Hardware security module
5.3.3.1 Overview
An HSM as used in financial systems and as illustrated in its ecosystem context in Figure 1 is a type of SCD
that typically:
— safeguards keys and functions using those keys in high-performance backend transaction processing
environments;
— provides a set of approved core cryptographic algorithms and key lengths;
— provides a set of cryptographic mechanisms built around those algorithms;
— provides secure random number generation using an approved methodology;
— exposes its security services to administrators and user clients via one or more structured APIs;
— interconnects with clients via an approved secure transport layer discipline for communication over
open networks.
An HSM may provide configuration and administration options, such as the following:
— Key and access control hierarchy: A layered, partitioned, cryptographic key and access control hierarchy
separating:
— manufacturer low-level firmware management functions;
— HSM owner (host) on-site HSM initialization;
— user partition management functions and end-user functions.
— Partitioning: Supporting at least one and potentially multiple isolated end-user partitions, such partitions
often also providing cryptographically segregated configuration and final end-use functionality to the
end-user domain.
— Cloning or backup: Secure cloning capabilities for load sharing or backup purposes via a secure
channel established between HSMs that have an authenticated cryptographic relationship, having been
preconfigured by the HSM owner with purpose-specific shared keying material.
— SCD or HMD secured administration: This may support or enhance the security of HSM administration
through the use of additional locally or remotely secure-channel attached SCD types or through the use
of smart cards (HMDs) for log-on authentication, storage or transfer of key parts.
— Secure user function definition: Beyond its generic capabilities, the HSM may incorporate within its
tamper-protection boundary supplementary user-partition-specific functionality, developed using a
secure programming discipline and inducted into the relevant partition via a higher-layer cryptographic
authentication process.
Key
in-band secure channel
out-of-band secure channel
authenticated human interfaces
Figure 1 — HSM ecosystem
5.3.3.2 Security requirements
The following security requirements for HSMs assume and supplement the security requirements for SCDs
elsewhere in this document:
— Owner and manufacturer administrative functions shall allow for dual control.
— User administrative functions should provide for dual control.
— Handover from manufacturer to the HSM owner (hosting entity) shall be via functionality which provides
for and entails cryptographic decoupling of HSM administration from the manufacturer for cases where
the manufacturer has default administrative keys that ship with the device. The manufacturer will then
not be able to access or control the keys of the owner of the HSM after the owner’s keys have been entered
or generated.
— Handover of an end-user partition from the HSM owner (hosting entity) to the end-user shall be via
functionality which provides for and entails cryptographic decoupling of HSM partition administration
from the HSM owner.
— A partition when assigned shall have no keys from or traces of the previous end-user or HSM owner
other than default administrative keys that allow for end-user initialization and shall be replaced during
initialization.
— The only owner operations on an end-user partition permitted by the HSM firmware shall be to suspend
or terminate the end-user partition.
— When an end-user partition is terminated it shall be with complete erasure of key material, administrative
access and configuration settings. If the end-user relationship with the HSM owner continues after the
termination (e.g. for cloud-based provisioning or reprovisioning events), the partition’s secure log file
shall be retained by the partition end-user or potentially under secure log delegation from the end-user
to the HSM owner.
— Secure cloning refers to replication of the keys and configuration of a partition or HSM to a receiving
partition or HSM. The following applies:
— Secure cloning shall only be feasible using a clearly defined secure-channel API and transfer process
under control of the HSM owner which protects confidentiality and integrity of keys and other
secret cryptographic material. The keys used for the security of the secure channel shall be at least
as strong as the strongest key material being cloned.
— Secure cloning shall protect integrity of the configuration of the end-user and should provide
confidentiality.
— Secure cloning shall not include log files; secure cloning shall be logged as a sensitive operation.
— The end-user of a partition being cloned shall control the cloning, even when the end-user of the
partition is not the HSM owner.
— Where a secure firmware update path is provided between manufacturer and HSM, such updates shall
only be feasible via a dedicated, segregated and authenticated channel, which should entail owner pre-
authorization using a secure owner-operated mechanism such as cryptographic countersigning. The
manufacturer should be unable to affect a firmware update without owner participation. Firmware
updates should be encrypted.
— To protect against protocol attacks, APIs used for financial application end use should be such that multi-
step cryptographic mechanisms or other sensitive operations do not necessitate orchestration by the
controlling client. These should progress atomically within the HSM from initiation to conclusion in a
single API call. In the absence of atomic API calls, the administrator of the HSM shall ensure that the risk
of exploitation is mitigated. Examples include PIN verification or PIN block translation, especially when
using EMV or DUKPT derived operational keys.
5.3.3.3 Hardware security module usage
Typical financial industry deployments of HSMs exhibiting these architectural characteristics and adhering
to these security requirements include:
— single or multi-partition HSMs, used within the one organization for its end-use applications;
— dedicated single or multi-partition HSMs hosted by one, possibly cloud-based, organization on behalf of
a single remote end-user;
— shared-use multi-partition HSMs hosted by one, possibly cloud-based, organization on behalf of multiple
end-users.
Typical financial end uses for HSMs include:
— certificate authority operations;
— payment terminal key management;
— payment transaction acquiring, including PIN and PAN processing protection;

— biometric authentication processing;
— payment card issuance;
— mobile financial application key management, provisioning and attestation o
...