ISO 13133:2026

• Abstract:

  This document provides a taxonomy, reference model, considerations for a security framework and a security problem definition for digital currency hardware wallets (DCHWs). It also specifies security objectives to address security issues related to the security problem definition. This document is applicable to organizations that develop and operate DCHWs, e.g. mobile device manufacturers, chip manufacturers and companies that provide DCHW solutions. This document is also relevant to third parties that provide services to these stakeholders. It addresses sovereign or fiat digital currencies issued by a specific entity, e.g. a central bank.

• Status: Published
• Publication Date: 21-Sep-2026
• ICS: 35.240.40 - IT applications in banking
• 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: 22-Sep-2026
• Due Date: 09-May-2027
• Completion Date: 22-Sep-2026

Overview

ISO 13133: Financial services - Security reference model for digital currency hardware wallet (SRM-DCHW) is an international standard developed by ISO, focusing on the security of digital currency hardware wallets (DCHW). As digital currencies, particularly central bank digital currencies (CBDCs), become more prevalent in global financial services, robust security frameworks are essential for the safe storage and management of these assets. ISO 13133 delivers a comprehensive security reference model for hardware wallets used specifically for digital currencies issued by entities such as central banks.

This standard is designed for organizations involved in the development, manufacturing, and operation of DCHWs-including mobile device producers, chip manufacturers, and solution providers-as well as for third-party service providers in the digital currency ecosystem.

Key Topics

ISO 13133 addresses a wide array of security-centric topics vital for the lifecycle and operation of digital currency hardware wallets, including:

• Security Domains and Controls: Defining security domains and relevant controls applicable to DCHWs.
• Data Management Security: Requirements and recommendations for the secure processing, storage, and handling of sensitive data within the hardware wallet.
• Communication Security: Guidelines for securing communication channels both within the wallet’s internal modules and with external entities.
• Access Control: Requirements for restricting and authorizing access to wallet assets, ensuring only legitimate actions are allowed.
• Software Operating Environment Security: Security requirements for the operational environment in which DCHW software is executed.
• Service Operation Security Policies: Best practices and policies for the secure operation of DCHWs in service environments.
• Threat Identification and Countermeasures: Considerations for identifying threats such as unauthorized access, data theft, and supply chain risks, and establishing objectives for mitigation.

Applications

ISO 13133 finds direct application in a range of practical scenarios, enhancing both user trust and regulatory compliance for hardware wallets in financial services:

• Central Bank Digital Currency (CBDC) Wallets: Establishing a security foundation for government-issued digital currencies managed through DCHWs.
• Commercial Hardware Wallets: Ensuring interoperable and secure design practices for devices used by financial institutions and service providers.
• Mobile Device Integration: Providing reference models that support secure DCHW implementation on commercial off-the-shelf mobile devices and integrated circuit cards (ICCs).
• Third-Party Service Providers: Enabling vendors and partners to align their security practices with internationally recognized standards, improving security across the digital currency ecosystem.
• Risk Management: Supporting organizations in conducting thorough risk assessments, as encouraged by reference to ISO 31000 for risk management frameworks.

By implementing the security requirements detailed within ISO 13133, organizations can address security threats, protect sensitive assets, and uphold end-user privacy for digital currency transactions.

Related Standards

For comprehensive digital currency security and interoperability, ISO 13133 should be used in conjunction with other recognized ISO and international standards, such as:

• ISO/IEC 27000 Series: For establishing overarching information security management systems and controls.
• ISO/IEC 15408 Series (Common Criteria): For evaluation criteria relating to IT security.
• ISO 31000: For risk management principles and assessment.
• ISO 13491: For secure cryptographic devices, including hardware security modules (HSMs).
• ISO 9564: For the handling and management of PIN security in card-based systems.

By referencing and implementing ISO 13133 alongside these related standards, organizations can build a robust, standards-based security posture for digital currency hardware wallets, fostering trust and operational resilience in the rapidly evolving landscape of digital financial services.

International
Standard
ISO 13133
First edition
Financial services — Security
2026-09
reference model for digital currency
hardware wallet (SRM-DCHW)
Services financiers — Modèle de référence de sécurité pour les
portefeuilles matériels de monnaie numérique (SRM-DCHW)
Reference number
© ISO 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
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 . 5
5 Taxonomy . 7
6 Reference model of a DCHW system . . 8
6.1 General .8
6.2 DC life cycle . .8
6.2.1 General .8
6.2.2 DC states .9
6.2.3 DC state changes .9
6.3 DCHW life cycle .10
6.3.1 General .10
6.3.2 DCHW states .10
6.3.3 DCHW state changes .10
6.4 Participants of a DCHW system .11
6.4.1 General .11
6.4.2 Issuing entities .11
6.4.3 Intermediaries .11
6.4.4 End users .11
6.4.5 TSPs .11
6.5 Conceptual model of a DCHW system . 12
6.5.1 General . 12
6.5.2 Issuing entity components . 12
6.5.3 Intermediary components . 13
6.5.4 DCHW components . 13
6.5.5 Acceptance device components . 13
6.6 TOE of a DCHW .14
6.6.1 General .14
6.6.2 Mobile devices . 15
6.6.3 ICCs . 15
6.7 TOE environment of a DCHW . 15
7 Considerations for the design of a security framework.15
8 Security problem definition . 16
8.1 General .16
8.2 Assets to be protected .16
8.2.1 User data .16
8.2.2 TSF hardware and software .17
8.2.3 TSF data .17
8.3 Threat actors .17
8.4 Threats .17
8.4.1 Threats to DC .17
8.4.2 Transaction threats .18
8.4.3 Cryptography threats .18
8.4.4 Communication threats .18
8.4.5 Authentication threats .19
8.4.6 User privacy threats .19
8.4.7 Hardware and software threats .19
8.4.8 Risk management threats . 20
8.4.9 Emergency response threats . 20

iii
8.4.10 Monitoring threats . 20
8.4.11 Threats to supply chain security .21
8.5 Organizational security policies .21
8.6 Assumptions . 22
9 Security objectives.22
9.1 General . 22
9.2 Security objectives for the TOE . 22
9.2.1 DC security objectives . 22
9.2.2 Transaction security objectives . 23
9.2.3 Cryptography security objectives .24
9.2.4 Communication security objectives . 25
9.2.5 Authentication security objectives . 26
9.2.6 Privacy security objectives . 26
9.2.7 Hardware and software security objectives .27
9.2.8 Risk management security objectives . 28
9.2.9 Emergency response security objectives . 28
9.2.10 Monitoring security objectives. 28
9.2.11 Supply chain security objectives . 29
Annex A (informative) Example models for secure implementation of DCHW on mobile devices .30
Annex B (informative) Examples of tiered DCHWs .33
Bibliography .34

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 68, Financial services, Subcommittee SC 2,
Financial services, security.
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
Users are stepping away from cash payments in favour of electronic payments. Many central banks and
monetary authorities conduct research on and pilot digital currencies (DCs) issued by a specific entity such
as a central bank [referred to as "central bank digital currencies (CBDCs)" in this document] to safely and
conveniently:
— provide access to public money;
— maintain the characteristics of a cash-like experience;
[23], [24], [25], [26]
— protect the privacy of users .
CBDCs are not intended to replace cash, but rather to complement cash and provide a backup to existing
payment tools. For example, CBDCs can be designed to maintain critical payment functionality in the event of
service disruptions, poor network coverage or natural disasters. CBDCs can also improve financial inclusion,
providing better access to financial services for the underbanked, unbanked, elderly and others. They can
also facilitate innovation, bringing new features and services to the ecosystem through the adoption of
appropriate technologies and designs.
Multiple central banks are considering introducing DCs in digital wallets. This has led to the establishment
of global standards to provide clear guidelines for mitigating circulation and payment risks associated with
these DCs. These standards are expected to be based, to the greatest extent possible, on existing financial
industry security standards and best practices.
This document outlines a DC wallet that can be embodied in, e.g. an integrated circuit card (ICC) or a
commercial off-the-shelf (COTS) mobile device. While commodity smartphones can be used as wallets,
the sensitive data and code of the wallets can reside within hardware devices, known as digital currency
hardware wallets (DCHWs).
This document focuses on hardware wallets for sovereign or fiat DCs issued by a specific entity, e.g. a central
bank.
This document does not require a specific architecture. It uses a two-tier model as an illustrative example.
In this model, the central bank issues CBDCs and manages the supply, while intermediaries are responsible
for distributing CBDCs to end users and supporting CBDC payments.
The purpose of this document is to facilitate the secure design and implementation of DCHWs.
It is recommended to use ISO 31000 as a risk management framework reference and accordingly conduct a
detailed and specific assessment of the threat impact, threat likelihood, etc.

vi
International Standard ISO 13133:2026(en)
Financial services — Security reference model for digital
currency hardware wallet (SRM-DCHW)
1 Scope
This document provides a taxonomy, reference model, considerations for a security framework and a security
problem definition for digital currency hardware wallets (DCHWs). It also specifies security objectives to
address security issues related to the security problem definition.
This document is applicable to organizations that develop and operate DCHWs, e.g. mobile device
manufacturers, chip manufacturers and companies that provide DCHW solutions. This document is also
relevant to third parties that provide services to these stakeholders. It addresses sovereign or fiat digital
currencies issued by a specific entity, e.g. a central bank.
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
means to ensure that access to assets is authorized and restricted based on business and security
requirements
[SOURCE: ISO 27789:2021, 3.1]
3.2
asset
anything (e.g. sensitive data) that has value to a stakeholder of a digital currency hardware wallet (DCHW),
which is processed, stored, transmitted and protected against unauthorized disclosure, alteration or
destruction
3.3
attack
successful or unsuccessful unauthorized attempt to destroy, alter, disable or gain access to an asset or any
attempt to expose, steal or make unauthorized use of an asset
Note 1 to entry: Attacks can also involve attempts to illegitimately create assets.
[SOURCE: ISO/IEC 27002:2022, 3.1.3, modified — Note 1 to entry has been added.]

3.4
central bank digital currency
CBDC
new form of central bank money in a digital format, denominated in the national unit of account, that is a
direct liability of the central bank and can be used for either retail payments or wholesale settlement or both
3.5
counter, verb
act on or respond to a particular threat so that the threat is eradicated or mitigated
[SOURCE: ISO/IEC 15408-1:2026, 3.29]
3.6
digital currency
DC
digital version of money that has the basic functions of money, e.g. unit of account and medium of exchange
3.7
digital currency hardware wallet
DCHW
hardware wallet that facilitates digital currency transactions
Note 1 to entry: This document focuses on hardware wallets for sovereign or fiat digital currencies issued by a specific
entity, e.g. a central bank.
3.8
hardware security module
HSM
secure cryptographic device (SCD) 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.
[SOURCE: ISO 13491-1:2024, 3.12]
3.9
hardware wallet
wallet which leverages a hardware device to generate, manage, store or use cryptographic keys or
cryptographic data
EXAMPLE A secure cryptographic device, a secure element or a trusted execution environment.
[SOURCE: ISO/TR 23576:2020, 3.4, modified — The example "(e.g. HSM)" has been deleted, "private and
public key" has been replaced with "cryptographic keys or cryptographic data" and the EXAMPLE has been
added.]
3.10
information security
preservation of confidentiality, integrity and availability of information
Note 1 to entry: In addition, other properties, such as authenticity, accountability, non-repudiation and reliability, can
also be involved.
[SOURCE: ISO/IEC 27000:2026, 3.1, modified — Note 1 to entry has been added.]
3.11
integrated circuit card
ICC
IC card
card into which one or more integrated circuits have been inserted

3.12
operating system
OS
software that controls the execution of programs and that can provide services such as resource allocation,
scheduling, input-output control and data management
Note 1 to entry: Although operating systems are predominantly software, partial hardware implementations are
possible.
[SOURCE: ISO/IEC TR 13066-6:2014, 2.12]
3.13
organizational security policy
OSP
set of security rules, procedures or guidelines for an organization
Note 1 to entry: A policy can pertain to a specific operational environment.
[SOURCE: ISO/IEC 15408-1:2026, 3.68]
3.14
private key
key in an asymmetric key pair which is known only by that entity
[SOURCE: ISO 11568:2023, 3.69]
3.15
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 or point of sale terminal
EXAMPLE Personal identification number entry device or hardware security module.
[SOURCE: ISO 13491-1:2024, 3.18]
3.16
secure element
SE
tamper-resistant component capable of securely hosting and executing applications and associated
confidential and cryptographic data (e.g. key management)
[SOURCE: ISO 5201:2024, 3.20, modified — The term "platform in the mobile device" has been replaced by
"component".]
3.17
security objective
statement of an intent to either counter identified threats or satisfy identified organization security policies
or assumptions, or both
[SOURCE: ISO/IEC 15408-1:2026, 3.82]
3.18
security problem definition
SPD
statement that defines the nature and scope of the security that the target of evaluation (TOE) is intended to
address
Note 1 to entry: This statement consists of a combination of: threats to be countered by the TOE and its operational
environment, the organizational security policies (OSPs) enforced by the TOE and its operational environment, and
the assumptions that are upheld for the operational environment of the TOE.
Note 2 to entry: SPD elements include threats, OSPs and assumptions.

[SOURCE: ISO/IEC 15408-1:2026, 3.83]
3.19
sensitive data
sensitive information
data which need to be protected against unauthorized disclosure, alteration or destruction
EXAMPLE Status information, cryptographic key, personal identification number.
[SOURCE: ISO 13491-1:2024, 3.20]
3.20
target of evaluation
TOE
set of software, firmware, hardware, or a combination of these, possibly accompanied by guidance, which is
the subject of an evaluation
[SOURCE: ISO/IEC 15408-1:2026, 3.93]
3.21
TOE security functionality
TSF
combined functionality of all hardware, software and firmware of a target of evaluation (TOE) that is relied
upon for the correct enforcement of the security functional requirements
[SOURCE: ISO/IEC 15408-1:2026, 3.95]
3.22
TSF data
data for the operation of the target of evaluation upon which the enforcement of the security functional
requirements relies
[SOURCE: ISO/IEC 15408-2:2026, 3.13]
3.23
threat
potential cause of an unwanted incident, which can result in harm to a system or organization
[SOURCE: ISO/IEC 27032:2023, 3.21]
3.24
transaction key
key used to cryptographically protect the transaction data elements between nodes
Note 1 to entry: If more than one key is used for different cryptographic functions, each key can be a variant or
derivative of the transaction key.
Note 2 to entry: A transaction key is sometimes referred to as a data key, communications key, session key or working
key.
[SOURCE: ISO 11568:2023, 3.85]
3.25
trusted execution environment
TEE
aspect of the device comprising either hardware or software or both which provides security services to the
device computing environment, protects data against general software attacks and isolates hardware and
software security resources from the operating system
[SOURCE: ISO 5201:2024, 3.21, modified — The wording "mobile" has been deleted, "and/" has been deleted,
"either" and "or both" have been added.]

3.26
user data
data received or produced by the target of evaluation (TOE), which are meaningful to some external entity,
but which do not affect the operation of the TOE security functionality (TSF)
Note 1 to entry: Depending on the concept, this definition assumes that the same data created by users that have an
actual impact on the operation of the TSF can be regarded as the TSF data.
[SOURCE: ISO/IEC 15408-2:2026, 3.14]
3.27
value form
representation of value held in a wallet
EXAMPLE A value form can be a plain balance (account) or a cryptographically computed digital coin (token).
3.28
vulnerability
weakness of an asset or control that can be exploited by one or more threats
[SOURCE: ISO/IEC 27002:2022, 3.1.38]
4 Abbreviated terms
AML anti-money laundering
ATC application transaction counter
ATE anti-tax evasion
ATM automated teller machine
CBDC central bank digital currency
CC common criteria
CFT counter terrorist financing
COTS commercial off-the-shelf
DC digital currency
DCHW digital currency hardware wallet
eSE embedded secure element
eSIM embedded subscriber identity module
HAL hardware abstraction layer
HSM hardware security module
ICC integrated circuit card
ISMS information security management system
KYC know your customer
MNO mobile network operator
NFC near field communication
OS operating system
OSP organizational security policy
P2P person to person
PCI payment card industry
PIN personal identification number
PII personally identifiable information
POI point of interaction
POS point of sale
PSP payment service provider
SCD secure cryptographic device
SDK software development kit
SE secure element
SIM subscriber identity module
SPD security problem definition
TEE trusted execution environment
TOE target of evaluation
TSF TOE security functionality
TSM trusted service manager
TSP technology service provider
TUI trusted user interface
5 Taxonomy
DCHW-related taxonomy in this document is classified as follows:
a) DCs can be expressed as different value forms, e.g. account balance or single-use key pairs with
denomination [sometimes referred to as "token" or "unspent transaction output (UTXO)"].
b) DCHWs can be subdivided according to the type of hardware used to ensure security, e.g. secure
elements or trusted execution environments. They differ in the security guarantees that they provide,
e.g. degree of tamper-resistance.
c) DCHW systems can provide for different payment scenarios (see References [16] and [17]):
1) online payments, where both payer and payee are connected to the internet;
2) single-offline payments, where either payer or payee is connected to the internet;
3) dual-offline payments, in which neither party is connected to the internet.
NOTE This document does not cover permanently dual-offline payments.
d) DCHWs may operate in any of those modes and may be prevented (temporarily or permanently) from
single-offline payments, dual-offline payments or both, due to implementation restrictions, policy
restrictions or both.
e) DCHW systems that support dual-offline payments can be further subdivided according to whether
DCHWs can immediately use the funds received in one dual-offline payment for subsequent dual-offline
payments without intermediate reconciliation. They primarily consist of two types: intermittent dual-
offline and staged dual-offline.
1) In intermittent dual-offline systems, DCHWs can be dual-offline for either a certain amount of time
or for a certain number of dual-offline transactions or both. They shall also connect to DC backend
systems for an integrity check, as shown in Figure 1.
2) In staged dual-offline systems, DCHWs may perform dual-offline transactions, but these
transactions are not considered to be settled or final until a receiver of funds has connected to the
DCHW backend systems for settlement.

Key
means integrity check
means payment
Figure 1 — Example illustration of intermittent dual-offline
6 Reference model of a DCHW system
6.1 General
This document specifies a reference model as follows:
— DC life cycle model;
— DCHW life cycle model;
— participants of a DCHW system;
— conceptual model of a DCHW system;
— target of evaluation (TOE) of a DCHW;
— TOE environment of a DCHW.
The model is used as a reference for subsequent security problem definition and security objective
specification.
The model should not be considered as a design for a full operational solution. The implementation of a
reference model can be tailored according to specific choices, designs or requirements.
6.2 DC life cycle
6.2.1 General
Figure 2 shows an example of a DC life cycle, which consists of DC states and DC state changes.

6.2.2 DC states
Examples of DC states include:
a) issued;
b) circulated:
1) distributed to intermediaries [if applicable, e.g. commercial banks, payment service providers
(PSPs), mobile network operators (MNOs)] or the issuing entities themselves;
2) stored in DCHWs;
3) accepted by acceptance devices [e.g. points of sale (POSs), automated teller machines (ATMs)];
c) redeemed.
Figure 2 — Example illustration of a DC life cycle
6.2.3 DC state changes
Examples of DC state changes include:
a) Issue: Create new DCs.
b) Fund: Convert deposits or cash to DCs, which means loading DCs into DCHWs.
c) Defund: Convert DCs to deposits or cash, which means unloading DCs from DCHWs.
d) Pay: Pay for goods or services with DCs stored in DCHWs.
e) Refund: Return paid DCs to payers by cancellation of payments.
f) Transfer: Transfer DCs between end users, including P2P transfers.
g) Aggregate: Upload DCs received in payments for goods or services.
h) Recycle: Modify collected DCs so that they can be reused.
i) Redeem: Redeem and destroy collected DCs.
NOTE Not all architectures are expected to support all the state changes.

6.3 DCHW life cycle
6.3.1 General
Figure 3 shows an example illustration of a DCHW life cycle, which consists of DCHW states and DCHW state
changes.
6.3.2 DCHW states
Examples of DCHW states include:
a) installed and initialized;
b) normal;
c) suspended;
d) lost;
e) disabled;
f) removed.
Figure 3 — Example illustration of a DCHW life cycle
6.3.3 DCHW state changes
Examples of DCHW state changes include:
a) Open: Create and activate new DCHWs.
b) Update: Update DCHWs' software, configuration or security parameters.
c) Suspend: Temporarily disable DCHWs, initiated either by the intermediaries or end users.
d) Cancel suspension: Restore suspended DCHWs to normal operation.
e) Lost report: Report DCHWs as lost or stolen.
f) Cancel loss report: Cancel previous loss reports of DCHWs.
g) Destruct or obsolete: Permanently disable DCHWs due to destruction, obsolescence or decommissioning.
h) Remove: Remove DCHWs and terminate all associated services.

6.4 Participants of a DCHW system
6.4.1 General
Participants of DCHW systems consist of issuing entities, intermediaries, end users and technology service
providers (TSPs).
6.4.2 Issuing entities
Issuing entities are responsible for the DC relevant functions, e.g. DC issuance, DC redemption, DC monitoring.
Examples of issuing entities include:
a) central banks;
b) monetary authorities.
6.4.3 Intermediaries
Intermediaries are responsible for the DC relevant functions, e.g. DC distribution, DC circulation, DC
exchange.
Examples of intermediaries include:
a) entities authorized or delegated by issuing entities, e.g. commercial banks, PSPs, MNOs;
b) issuing entities themselves, e.g. central banks, monetary authorities.
6.4.4 End users
End users are responsible for making or receiving value transfers (e.g. payments, fund transfers).
Examples of end users include:
a) individual users, e.g. P2P transfers, in-person payments, online purchases;
b) merchant or business users, e.g. in-store payments, e-commerce payments;
c) government users, e.g. tax collections and refunds, subsidy and benefit disbursements, pension fund
distributions.
6.4.5 TSPs
TSPs are responsible for delivering frontend and backend technical services and products that enable DCHW
systems.
Examples of TSPs include:
a) Point-of-interaction (POI) service providers: They provide and maintain the POI terminals and software
to facilitate transactions at physical or remote locations.
b) Integrated circuit card (ICC) service providers: They provide ICCs to store and process payments and
DC credentials.
c) Commercial off-the-shelf (COTS) device service providers: They provide the necessary hardware or
software solution to facilitate payments on COTS devices, e.g. smartphones, tablets.
d) Wallet service providers: They develop and operate digital wallet applications to securely store payment
instruments and facilitate transactions.
e) Operating system (OS) providers: They develop underlying OS software to manage hardware resources
and provide platforms supporting applications (e.g. payment, DC).

f) Chip providers: They design and manufacture semiconductor chips to form the secure hardware
foundations for payments and transactions.
6.5 Conceptual model of a DCHW system
6.5.1 General
Figure 4 shows an illustration of a DCHW system conceptual model, which consists of issuing entity
components, intermediary components, DCHW components and acceptance device components.
Figure 4 — Illustration of a DCHW system conceptual model
6.5.2 Issuing entity components
Examples of issuing entity components include:
a) DC issuance, which creates and introduces DC into the system;
b) DC monitor, which monitors transactions, balances and other metrics to ensure the system operates as
intended and to detect anomalies or fraud;
c) DC redemption, which manages the process of redeeming CBDC from circulation and exchanging it for
fiat currency or other forms of value;
d) DC validity check, which verifies the authenticity and integrity of CBDC to prevent counterfeiting or
double-spending;
e) ledger, which maintains a definitive record of DC-related data according to specific designs;
f) DC revocation, which cancels or invalidates DC in cases of fraud, loss or other issues to maintain system
integrity.
6.5.3 Intermediary components
Examples of intermediary components include:
a) DC distribution, which ensures the efficient and secure distribution of DC to end users or intermediaries
(e.g. commercial banks, PSPs, MNOs);
b) user onboarding, which includes the process of onboarding users into a DC system and may incorporate
AML, CFT, ATE and KYC (see examples in Annex B) requirements;
c) provision management, which includes the process of DCHW deployment, installation, initialization,
activation;
d) risk management, which allows configuration of transaction settings (e.g. limits, amounts) and provides
patch updates for DCHW to address vulnerabilities;
e) transaction management, which processes, validates and records transactions to ensure accuracy,
security and conformity;
f) DC recovery, which includes processes to restore CBDC in cases of hardware failure, loss of access or
other issues.
NOTE Intermediary is optional, and the components described can also be provided directly by the issuing entity.
6.5.4 DCHW components
Examples of DCHW components include:
a) value form, which provides the capability to securely hold, generate or both hold and generate the value-
form of DC used to transfer value between DCHWs and to manage DC balances, in whatever form they
are presented;
b) value transfer protocol, which manages a secure value transfer protocol to allow secure online or offline
payments to be made to other DCHWs;
c) value transfer mechanism, which supports functionalities such as data processing and cryptographic
algorithms, used to implement the value transfer protocol;
d) online update, which manages interactions with online systems for risk management purposes, software
updates, etc.;
e) payment (online/offline), which supports making and receiving payments securely online or offline;
f) fund/defund, which supports the conversion between DC and deposit/cash.
6.5.5 Acceptance device components
Examples of acceptance device (e.g. POS, ATM) components include:
a) location management, which ensures the device is correctly identified and operates within its designated
area (e.g. store, branch or network);
b) aggregate, which combines or consolidates data from multiple transactions or devices;
c) DC exchange, which converts cash or deposits into DCs;
d) transaction handling, which processes, validates and completes transactions, ensuring accuracy and
security from initiation to settlement;
e) risk management, which identifies and mitigates risks associated with transactions;
f) provision management, which includes the process, e.g. installation, initialization, activation.

6.6 TOE of a DCHW
6.6.1 General
TOE of a DCHW is a set of hardware, firmware and software, possibly accompanied by guidance, that is the
subject of security assessment and evaluation in this document.
Figure 5 shows two TOE examples of DCHW. More examples are illustrated in Annex A.
Figure 5 — Two TOE examples of DCHW

6.6.2 Mobile devices
The main components of TOE example 1 (Figure 5) related to mobile devices are as follows:
a) user interaction DCHW application, which provides user-friendly interaction, parameter setting, wallet
management and collaborates with the DCHW applet to provide DC-relevant functions;
b) DCHW application, e.g. applet, native application, which stores sensitive information, e.g. the private key,
which never leaves the secure element (SE), and executes critical and sensitive security and business
logic;
c) SE, which provides a tamper-resistant platform capable of securely hosting and executing applications
and associated confidential and cryptographic data (e.g. key management) and includes SE OS, SE
firmware and SE hardware;
d) trusted execution environment (TEE), which is based on a hardware device and may be leveraged
to provide a trusted user interface, trusted authentication (e.g. biometric authentication) and other
security-enhancing functions for DCHW;
e) device OS, which manages the overall functionality of the mobile device, supports the DCHW application
and ensures compatibility with the device's hardware and software components;
f) device firmware, which controls the low-level operations of the device hardware, provides the
foundational software layer that enables the device OS and DCHW application to function correctly;
g) device hardware, which includes the processor, memory and other hardware elements that support the
execution o
...