oSIST prEN 40000-11:2026

Essential cybersecurity requirements for products - Part 11: Hardware Devices with Security Boxes incorporating a hardware physical envelope and designed to provide security functions such as secure storage and cryptographic operations in an open environment

This document defines cyber security requirements for products with digital elements belonging to product category “Hardware Device with Security Boxes” (hereinafter called “Product” or “HWSB product”).
The technical description of “Hardware Devices with Security Boxes” can be found in Annex II of [CRA].
The Hardware Devices with Security Boxes in scope are designed for deployment in a range of environments and where the threat landscape includes attackers with various attack potential.
HWSB are hardware-based systems intended to provide secure storage, processing and use of sensitive data, including cryptographic assets, within a protected hardware boundary (envelope).
This document applies to the HWSB part of the product. The applicability of this document to specific products is determined based on their intended purpose, use case and risk assessment.

Grundlegende Cybersicherheitsanforderungen gemäß CRA für Hardware-Geräte mit Sicherheitsboxen, die eine physische Hardware-Umhüllung enthalten und für die Bereitstellung von Sicherheitsfunktionen wie sichere Speicherung und kryptografische Operationen in einer offenen Umgebung ausgelegt sind

Exigences essentielles de cybersécurité pour les produits - Partie 11: Dispositifs matériels avec coffrets de sécurité intégrant une enveloppe physique et conçus pour fournir des fonctions de sécurité telles que le stockage sécurisé et des opérations cryptographiques dans un environnement ouvert

Le présent document définit les exigences en matière de cybersécurité applicables aux produits comportant des éléments numériques et appartenant à la catégorie de produits «Dispositifs matériels avec coffrets de sécurité» (ci-après dénommés «produit» ou «produit HWSB»).
La description technique des «dispositifs matériels avec coffrets de sécurité» se trouve à l'Annexe II du [CRA].
Le domaine d'application des dispositifs matériels avec coffrets de sécurité concerne des environnements variés où le panorama des menaces comprend des attaquants présentant des potentiels d'attaque variés.
Les HWSB sont des systèmes matériels conçus pour assurer le stockage, le traitement et l'utilisation sécurisés de données sensibles, y compris les actifs cryptographiques, au sein d'une enceinte matérielle protégée (enveloppe).
Le présent document s'applique à la partie HWSB du produit. L'applicabilité du présent document à des produits spécifiques est déterminée en fonction de leur utilisation prévue, de leur cas d'utilisation et de l'appréciation du risque.

Bistvene zahteve kibernetske varnosti za izdelke - 11. del: Strojne naprave z varnostnimi škatlami, ki vključujejo strojno fizično ovojnico in so zasnovane za zagotavljanje varnostnih funkcij, kot so varno shranjevanje in kriptografske operacije v odprtem okolju

Ta dokument zajema vrstico 39 iz zahteve za standardizacijo CRA in zagotavlja:
- Splošni opis izdelkov in njihovih komponent, ki spadajo v kategorijo HWSB, vključno – med drugim:
  o Strukturiran opis te kategorije izdelkov:
     Skupne značilnosti izdelkov HWSB s strojno opremo, notranjo HW in SW
     Opis reprezentativnih izdelkov z uporabo teh skupnih značilnosti
  o Identifikacija različnih vrst HWSB;
  o Predvideni namen in razumno predvidena uporaba;
  o Identifikacija HWSB, ki so izključeni iz te kategorije
  o Opredelitev in medsebojno delovanje z drugimi kategorijami, v katere bi lahko HWSB spadali.
- Opis tipičnega življenjskega cikla;
- Obseg uporabe in pomembnost bistvenih zahtev kibernetske varnosti;
- Opredelitev ustreznih profilov tveganja, ki jih je treba upoštevati za te HWSB, kar bo določilo varnostne zahteve in metodologije ocenjevanja, ki jih je treba uporabiti;
- Ustrezne varnostne zahteve, ki zagotavljajo izpolnjevanje bistvenih zahtev za vsak profil tveganja;
- Zagotavljanje meril za določitev ustreznega profila tveganja;
Na voljo je osnovni dokument:
- ki opredeljuje profile tveganja;
- identificira začetne zahteve za kibernetsko varnost.

General Information

• Status: Not Published
• Public Enquiry End Date: 05-Aug-2026
• ICS: 35.030 - IT Security
• Technical Committee: ITC - Information technology
• Current Stage: 4020 - Public enquire (PE) (Adopted Project)
• Start Date: 04-May-2026
• Due Date: 21-Sep-2026
• Directive: Not Harmonized2024/2847 - Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) (Text with EEA relevance)
• Mandate: M/606 - on a standardisation request to European Standards Organisations in support of Union policy on cybersecurity requirements for products with digital elements
• Ref Project: prEN 40000-11 - Essential cybersecurity requirements for products - Part 11: Hardware Devices with Security Boxes incorporating a hardware physical envelope and designed to provide security functions such as secure storage and cryptographic operations in an open environment

Standards Content (Sample)

SLOVENSKI STANDARD
01-julij-2026
Bistvene zahteve kibernetske varnosti za izdelke - 11. del: Strojne naprave z
varnostnimi škatlami, ki vključujejo strojno fizično ovojnico in so zasnovane za
zagotavljanje varnostnih funkcij, kot so varno shranjevanje in kriptografske
operacije v odprtem okolju
Essential cybersecurity requirements for products - Part 11: Hardware Devices with
Security Boxes incorporating a hardware physical envelope and designed to provide
security functions such as secure storage and cryptographic operations in an open
environment
Grundlegende Cybersicherheitsanforderungen gemäß CRA für Hardware-Geräte mit
Sicherheitsboxen, die eine physische Hardware-Umhüllung enthalten und für die
Bereitstellung von Sicherheitsfunktionen wie sichere Speicherung und kryptografische
Operationen in einer offenen Umgebung ausgelegt sind
Exigences essentielles de cybersécurité pour les produits - Partie 11: Dispositifs
matériels avec coffrets de sécurité intégrant une enveloppe physique et conçus pour
fournir des fonctions de sécurité telles que le stockage sécurisé et des opérations
cryptographiques dans un environnement ouvert
Ta slovenski standard je istoveten z: prEN 40000-11
ICS:
35.030 Informacijska varnost IT Security
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

DRAFT
EUROPEAN STANDARD
NORME EUROPÉENNE
EUROPÄISCHE NORM
May 2026
ICS 35.030
English Version
Essential cybersecurity requirements for products - Part
11: Hardware Devices with Security Boxes incorporating a
hardware physical envelope and designed to provide
security functions such as secure storage and
cryptographic operations in an open environment
Grundlegende Cybersicherheitsanforderungen gemäß
CRA für Hardware-Geräte mit Sicherheitsboxen, die
eine physische Hardware-Umhüllung enthalten und für
die Bereitstellung von Sicherheitsfunktionen wie
sichere Speicherung und kryptografische Operationen
in einer offenen Umgebung ausgelegt sind
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 224.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 40000-11:2026 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions and abbreviations . 6
4 Product context . 11
4.1 Product components and architecture . 11
4.2 Operational Environment . 21
4.3 Distribution of security functions . 23
4.4 Users . 26
4.5 Example HWSB Use Case . 26
5 Requirements . 28
5.1 Overview . 28
5.2 Technical Requirements . 29
5.3 Assurance requirements . 73
6 Conformity Assessment / Tests (normative) . 75
6.1 Assessment methodology . 75
6.2 Assessment format . 75
6.3 Product requirements assessment . 76
Annex A (normative) Security Profile . 100
A.1 Introduction . 100
A.2 Selecting Assurance Profile and Requirements Modules based on IPRFU . 101
A.3 Assurance Profile . 104
A.4 Requirements Modules . 106
Annex B (informative) Security Analysis . 113
B.1 Overview . 113
B.2 IPRFU . 113
B.3 Analysis . 115
Annex C (informative) Other verticals of interest . 122
Annex K (normative) Cryptography . 123
K.1 State of the Art Cryptography (CRY-SOTA) . 123
K.2 Crypto agility . 126
Annex R (normative) Additional provisions for products relying on remote data processing
solutions (RDPS) . 128
R.1 Scope and Applicability . 128
R.2 RDPS as a product-boundary extension . 128
R.3 Threat Model . 130
R.4 Security Requirements . 132
R.5 Security controls and mitigation guidance for RDPS requirements (informative) . 146
R.6 Conformity assessment . 147
Annex ZA (informative) Relationship between this European Standard and the essential
cybersecurity requirements of Regulation (EU) 2024/2847 of the European Parliament
and of the Council of 23 October 2024 on horizontal cybersecurity requirements for
products with digital elements and amending Regulations (EU) No 168/2013 and (EU)
2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) aimed to be covered 153
Bibliography . 156
European foreword
This document (prEN 40000-11:2026) has been prepared by Technical Committee CEN/TC 224
“Personal identification and related personal devices with secure element, systems, operations and
privacy in a multi sectorial environment”, the secretariat of which is held by AFNOR.
This document is currently submitted to the CEN Enquiry.
This document has been prepared under a standardization request addressed to CEN by the European
Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
Member States.
For the relationship with EU Legislation, see informative Annex ZA, which is an integral part of this
document.
Introduction
The present document defines cybersecurity requirements applicable to Hardware Devices in Security
Boxes. It applies to products with digital elements designed to provide cryptographic services and secure
storage as well as protection against physical attacks.
It supports the implementation of Regulation (EU) 2024/2847, the Cyber Resilience Act, specifically
addressing the essential cybersecurity requirements defined in Annex I, Parts I and II.
Application of this document
In order to establish presumption of conformity using this standard, the following steps must be followed:
— Step 1: Decide on the pathway (‘template’ or ‘rule-based’) from Annex A to identify a suitable
security profile for the HWSB based on its IPRFU.
The security profile will define what security requirements are applicable based on selection of
requirements modules from Clause 5 alongside an ‘assurance profile’ that is used with conformity
assessment activities in Clause 6.
— Step 2: Develop an HWSB compliant with applicable security requirement using examples where
appropriate.
— Step 3: Develop evidence required to complete conformity assessment activities listed in Clause 6
based on applicable security requirements and required test and evidence checks overlayed with the
selected assurance profile.
— Step 4: Perform the conformity assessment including:
o evidence review,
o independent functional testing (if using assurance profile high), and
o vulnerability testing.
Presumption of conformity as an HWSB is achieved if all checks and testing meet the listed pass criteria.

1 Scope
This document defines cyber security requirements for products with digital elements belonging to
product category “Hardware Device with Security Boxes” (hereinafter called “Product” or “HWSB
product”).
The technical description of “Hardware Devices with Security Boxes” can be found in Annex II of [CRA].
The Hardware Devices with Security Boxes in scope are designed for deployment in a range of
environments and where the threat landscape includes attackers with various attack potential.
HWSB are hardware-based systems intended to provide secure storage, processing and use of sensitive
data, including cryptographic assets, within a protected hardware boundary (envelope).
This document applies to the HWSB part of the product. The applicability of this document to specific
products is determined based on their intended purpose, use case and risk assessment.
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.
prEN 40000-1-3:2025, Cybersecurity requirements for products with digital elements — Part 1-3:
Vulnerability Handling
AIS20/31, A proposal for: Functionality classes for random number generators, Bundesamt für Sicherheit
in der Informationstechnik (BSI)
NIST SP800-90A, Recommendation for Random Number Generation using Deterministic Random Bit,
National Institute of Science and Technology (NIST)
NIST SP800-90B, Recommendation for the entropy sources used for random bit generation, National
Institute of Science and Technology (NIST)
NIST SP800-90C, Recommendations for Random Bit Generator (RBG) Constructions, National Institute of
Science and Technology (NIST)
ISO/IEC 18031:2025, Information technology — Security techniques — Random bit generation
3 Terms and definitions and abbreviations
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
application
software that provides service(s) to the user of the final product
3.2
attack potential
measure of effort needed to exploit a vulnerability in a product
Note 1 to entry: The effort is expressed as a function of properties related to the attacker (e.g. expertise, resources,
and motivation) and properties related to the vulnerability itself (e.g. window of opportunity, time to exposure).
[SOURCE: EN ISO/IEC 15408-1:2023, 3.8]
3.3
client application
application running external to the HWSB that consumes its services either over a local or remote
interface
3.4
firmware
code that is embedded inside the HWSB
3.5
internal application
application running internal to the HWSB that consumes its services over an internal interface
3.6
local application
application running external to the HWSB that consumes its services over a local interface
3.7
multi-factor authentication
authentication of an operator using at least two independent authentication factors. All authentication
data is verified by the cryptographic module
Note 1 to entry: An authentication factor is operator related information that resides outside the module, is used
as proof of identity, and may include a method/process to produce varying or short-lived authentication data from
the operator related information.
Note 2 to entry: Independent authentication factor categories for human operators include: something known,
such as a secret password, something possessed, such as a physical key or token, and a physical property, such as a
biometric.
[SOURCE: ISO/IEC 19790:2025, 3.86]
3.8
remote application
application running external to the HWSB that consumes its services over a remote interface
3.9
security attribute
property of subjects, users, objects, information, sessions or resources that is used in defining the security
functions and whose values are used in enforcing the security functions
Note 1 to entry: Users can include external IT products.
[SOURCE: EN ISO/IEC 15408-1:2023, 3.77]
3.10
security profile
suite of assurance activities and requirements modules linked pre-defined levels of confidence that the
HWSB implements its selected security requirements and mitigates threats relevant to its IPRFU
3.11
user
human or machine operator accessing and consuming services from the HWSB
3.12
user data
data stored and/or processed in the HWSB on behalf of the user
Abbreviations
ADV (CC) Development (assurance class)
AES Advanced Encryption Standard
AGD (CC) Guidance Documents (assurance class)
ALC (CC) Life-Cycle support (assurance class)
API Application Programming Interface
ASE (CC) Security Target Evaluation (assurance class)
ATE
(CC) Tests (assurance class)
ATM Automated Teller Machine
AVA (CC) Vulnerability Assessment (assurance class)
CA Certificate Authority
CC Common Criteria
CCMC CEN-CENELEC Management Centre
CEN European Committee for Standardization
CEN/TC CEN Technical Committee
CIK Crypto Ignition Key
CPLD Complex Programmable Logic Device
CPU Central Processing Unit
CRA Cyber Resilience Act
DICE Device Identifier Composition Engine
DNA Deoxyribonucleic Acid.
DoS Denial of Service
DRAM Dynamic random-access memory
DRBG Deterministic Random Bit Generator
DTBS Data To Be Signed
DTMF Distributed Management Task Force
ECC Elliptic Curve Cryptography
EFP
Environmental Failure Protection
EN European Norm (standard)
ENISA European Union Agency for Cybersecurity
EU European Union
EUCC European Common Criteria–based Cybersecurity Certification Scheme
EFTA European Free Trade Association
FIB Focused Ion Beam
FIDO Fast IDentity Online
FIPS Federal Information Processing Standard
FPGA Field-Programmable Gate Array
FRAM Ferroelectric random-access memory (CC) Resource Utilization (functional class)
FW FirmWare
GNSS Global Navigation Satellite System
HBOM Hardware Bill of Materials
HMAC Hash-based Message Authentication Code
HSM Hardware Security Module
HSS Hierarchal Signature Scheme
HW HardWare
HWSB HardWare device with Security Box
I2C Inter-Integrated Circuit
IC Integrated Circuit
ID Identifier
IEC International Electrotechnical Commission
IPsec
Internet Protocol security
IPRFU Intended Purpose and Reasonable Foreseeable Use
ISO International Organization for Standardization
ISO/IEC Joint ISO / IEC standard
IT Information Technology
KLF Key Loading Facility
LMS Leighton-Micali Signature
MAC (net) Media Access Control (address)
MAC (crypto) Message Authentication Code
MACsec
Medium Access Control (layer) security
MCU
Microcontroller Unit
MFA Multi-Factor Authentication
ML-DSA Module-Lattice Digital Signature Algorithm.
MPU Microprocessor Unit
OEM Original Equipment Manufacturer
OTP One Time Password
PAN Primary Account Number
PCB Printed Circuit Board
PCI (interface) Peripheral Component Interconnect
PCI (other) Payment Card Industry
PCI DSS Payment Card Industry Data Security Standard
PCIe Peripheral Component Interconnect express
PIN Personal Identification Number
PKCS Public-Key Cryptography Standards
PKCS#11 Cryptoki API (PKCS #11)
PKI Public Key Infrastructure
POI Point of Interaction
PP Protection Profile
RAM Random Access Memory
RBAC Role-Based Access Control
RDPS Remote Data Processing Solution
REQ Requirement
RNG Random Number Generator
RATS Remote Attestation Procedure
ROM Read-Only Memory
RSA Rivest-Shamir-Adelman (Asymmetric cryptographic algorithm)
RTC Reat Time Clock
SAR Security Assurance Requirement
SBOM Software Bill Of Materials
SCA Side-Channel Attack
SEMA Simple EMissions Analysis
SFR Security Functional Requirement
SHA Secure Hash Algorithm
SLH-DSA Stateless Hash-Based Signature Algorithm
SPA Simple Power Analysis
SPD Security Problem Definition
SPDX Software Package Data Exchange (SBOM format / identifier scheme)
SPDM Security Protocol and Data Model
SPI Serial Peripheral Interface
SRAM Static Random-Access Memory
SSH Secure SHell
ST Security Target
SW Software
TA Timing Analysis
TLS Transport Layer Security
TOE Target of Evaluation
TPM Trusted Platform Module
TR Technical Report
TRNG True Random Number Generator
TS Technical Specification
TSF TOE Security Functions
TSP Trust Service Provider
UART Universal Asynchronous Receiver/Transmitter
UC Use Case
URI Uniform Resource Identifier
USB Universal Serial Bus
VU Vehicle Unit (tachograph context)
4 Product context
4.1 Product components and architecture
4.1.1 Overview
An HWSB product is composed of an HWSB and some applications. These applications use the HWSB as
a provider of security services such as secure storage, cryptographic processing, authentication, integrity
protection and controlled access to sensitive assets.
An HWSB comprises:
— a secure physical boundary (secure envelope),
— hardware components,
— firmware,
— security functions and services,
— interfaces for interaction with internal, local and remote applications, and
— functions that operate in a Remote Date Processing Solution (RDPS).
The HWSB product may include:
— internal applications, located within the secure boundary,
— local applications, operating in a controlled environment, and
— remote applications, operating through potentially uncontrolled networks or environments.
Figure 1 highlights the HWSB components (in green) and in scope and the additional applications (in
blue) that may be part of the HWSB product and that are out of scope.
Figure 1 — HWSB product generic architecture
The following subclause provides more details on each component.
4.1.2 Secure envelope
The secure envelope defines the physical security boundary of the HWSB product.
It shall:
— enclose all components whose protection relies on the physical security of the device,
— provide a continuous protective boundary against unauthorized physical access,
— protect against tampering, probing, substitution and bypass,
— include tamper detection and, where applicable, tamper response mechanisms.
The secure envelope may include:
— tamper-resistant or tamper-evident enclosure elements,
— fasteners, seals and intrusion detection mechanisms,
— tamper sensors and associated circuitry,
— conductive or mechanical paths crossing the boundary.
Any interface traversing the secure envelope shall be protected at the point of penetration.
HWSB may include multiple layers to its secure envelope where different levels of security are provided
by each layer. It is also possible that HWSB consist of multiple secure enclaves each containing their own
secure envelope and with interfaces between each envelope being cryptographically secured.
Example layered or distributed secure envelope are provided in Figure 2 and Figure 3:

Figure 2 — Layered security envelope

Figure 3 — Distributed secure envelope with protection islands
4.1.3 Hardware components
The HWSB product commonly includes the following hardware components, as applicable to the
intended use case and product design:
a) Processing components
These components provide the main computing capabilities of the HWSB product and may include:
— microcontrollers,
— microprocessors,
— dedicated secure processing units,
— auxiliary controllers,
— System-on-Chip (SoC).
They shall control security-relevant operations and the interaction between internal components and
external interfaces.
b) Cryptographic components
These components implement or accelerate cryptographic operations and may include:
— dedicated cryptographic processors,
— hardware cryptographic engines,
— hardware accelerators,
— secure coprocessors.
They may support functions such as:
— encryption and decryption,
— digital signature generation and verification,
— hashing,
— message authentication,
— key derivation (including key agreement)
— key encapsulation and decapsulation,
— key generation,
— random number generation support (e.g. standalone DRBG).
c) Memory components
The HWSB product may include several types of memory, including:
— volatile memory for execution and temporary data,
— non-volatile memory for firmware and persistent configuration,
— secure memory for sensitive data,
— remanence protect memory for cryptographic keys.
Memory architecture shall ensure that sensitive data are protected against unauthorized disclosure or
modification as applicable to the IPRFU.
d) Random number generation components
The HWSB product may include:
— true random number generators,
— entropy sources and conditioning mechanisms.
These components shall support the generation of random values required for cryptographic functions.
e) Tamper protection components
These components may include:
— tamper sensors,
— tamper controller,
— voltage, temperature or environmental monitoring,
— secure erase or zeroization circuitry,
— protective mesh or equivalent mechanisms.
They shall support detection of abnormal physical conditions and initiation of protective responses.
f) Power and support components
The HWSB product may include:
— power control and regulation modules,
— backup batteries for security-critical functions,
— buffering and protection circuits,
— real-time clock components,
— interface support IC.
These components may contribute to secure operation, event logging, tamper response or continuity of
security functions.
In addition to the explicitly listed components above, HWSB will also commonly use reconfigurable logic
such as CPLD and FPGA to realize some of the components listed above (such as cryptographic processors
alongside random number generators) alongside being used to inter-connect integrated circuits
alongside managing board level logic such as global reset nets used to reset and power-on IC in sequence
as part of startup of a HWSB.
Specialist HWSB will in addition likely support many other forms of integrated alongside analogue
circuits to support functions with some examples being:
— radio interfaces (e.g. as used to support wireless interfaces);
— specialist analogue and digital signal processing chips (e.g. as might be used to acquire and process
a Global Navigation Satellite System (GNSS) signal for a HWSB tracking location such as a
tachograph);
— Accelerometers (e.g. as might be used to provide measurements of multi-axis acceleration as used by
tachographs).
4.1.4 Firmware
The firmware implements the security behaviour of the HWSB product.
They may include the following functional groups.
a) Boot and integrity management
These functions may include:
— bootloader,
— secure boot manager,
— firmware authenticity and integrity verification,
— anti-rollback protection,
— version control.
These functions shall ensure that only authorized firmware is executed.
b) Cryptographic and key management functions
These functions may include:
— cryptographic kernel,
— key generation,
— key import and export,
— key wrapping and unwrapping,
— key storage control,
— key backup and restore,
— key deletion and zeroization,
— entropy and random number management.
These functions shall ensure that keys and other sensitive cryptographic assets are handled securely
throughout their lifecycle.
c) Security policy enforcement
These functions may include:
— authentication mechanisms,
— authorization mechanisms,
— access policy enforcement,
— role separation,
— resource control,
— mandatory access restrictions,
— isolation or sandboxing mechanisms.
These functions shall ensure controlled access to sensitive data, services and system resources.
d) Audit and monitoring
These functions may include:
— audit logging,
— event recording,
— security monitoring,
— environmental monitoring,
— self-test mechanisms.
These functions shall support detection of abnormal conditions and provide traceability of security-
relevant events.
e) Tamper response and recovery
These functions may include:
— tamper state handling,
— secure erase or zeroization logic,
— lockdown behaviour,
— recovery support.
These functions shall ensure that critical security actions are taken in response to tamper events or other
severe faults.
f) Communication and interface support
These functions may include:
— command dispatch,
— protocol handling,
— interface drivers,
— secure session handling,
— transport protection,
— update services.
These functions shall ensure that interactions with external entities are performed securely.
4.1.5 Security Functions
The HWSB product shall implement security functions appropriate to its intended use.
These functions may include:
a) Secure storage
The HWSB product may provide protected storage for:
— cryptographic keys,
— authentication data,
— configuration data,
— audit logs,
— other sensitive data.
Secure storage functions shall protect sensitive data against unauthorized disclosure, modification and
extraction.
b) Key management
The HWSB product may manage the lifecycle of cryptographic keys, including:
— generation,
— loading,
— derivation,
— storage,
— backup,
— recovery,
— revocation,
— deletion,
— zeroization.
c) Cryptographic services
The HWSB product may provide:
— encryption and decryption,
— signature generation and verification,
— MAC computation and verification,
— hashing,
— random number generation,
— other approved cryptographic services.
d) Access control
The HWSB product shall enforce policies governing:
— who may access sensitive data,
— which services may be used,
— how keys may be used,
— which roles are permitted to perform administrative or operational actions.
e) Audit and logging
The HWSB product may record security-relevant events including:
— authentication attempts,
— administrative actions,
— cryptographic operations, where applicable,
— tamper events,
— security state changes,
— update events.
f) Secure boot and secure update
The HWSB product may provide:
— verification of firmware integrity and authenticity at startup,
— controlled installation of authorized firmware,
— protection against rollback to previous or unauthorized versions.
g) Secure execution
The HWSB product may provide an isolated execution environment ensuring:
— separation between security-relevant functions and other functions,
— controlled execution of firmware components,
— protection of memory and process context.
4.1.6 Interfaces and Connectivity
The HWSB product may expose interfaces for interaction with users, external systems and services.
a) Local interfaces
Local interfaces are intended for direct interaction in controlled environments. These may include:
— PCIe,
— USB,
— Ethernet used in a local network,
— serial interfaces,
— smartcard interfaces,
— maintenance or debug interfaces, where permitted and protected.
These interfaces shall be controlled in accordance with the security policy of the HWSB product.
b) Remote interfaces
Remote interfaces are intended for interaction with external systems over potentially uncontrolled
environments. These may include:
— network interfaces,
— remote management channels,
— remote service interfaces,
— application service interfaces.
These interfaces shall be protected by appropriate communication security mechanisms.
c) Internal interfaces
Internal interfaces are used for communication between internal components of the HWSB product and
may include:
— internal buses,
— dedicated interconnects,
— FPGA or controller interfaces,
— secure memory access paths.
Internal interfaces shall not weaken the protection of sensitive assets.
4.1.7 External Services and Supporting Systems
The HWSB product may interact with external services and supporting systems, including:
— secure update services,
— authentication services,
— key provisioning or key injection services,
— licensing services,
— management and monitoring platforms,
— external storage or backup services.
Where such services are used, the HWSB product shall ensure that interactions are authenticated and
protected against unauthorized access, modification and disclosure.
4.1.8 Architectural Variability
The exact architectural composition of an HWSB product depends on:
— the use case,
— the threat environment,
— the operational environment,
— the implementation technology,
— the product risk assessment.
Not all HWSB products will implement the same hardware, firmware or interface sets. However, all HWSB
products within the scope of this document shall provide a coherent security architecture ensuring
protection of sensitive assets and consistent with their intended purpose.
4.2 Operational Environment
4.2.1 Physical Environment
HWSB products may operate in environments with varying levels of physical and organizational
protection.
These environments may include:
— uncontrolled or hostile environments,
— partially controlled environments,
— controlled environments with restricted access,
— highly protected environments with strong physical and procedural controls.
The level of protection required from the HWSB product depends on the characteristics of the operational
environment and the associated risk assessment.
Security shall be achieved through:
— security mechanisms implemented within the HWSB product, and
— external controls applied in the operational environment.
These controls may include:
— physical access control,
— surveillance and monitoring,
— procedural controls,
— secure operational practices.
The operational environment plays a crucial role. Several types of environments have been identified.
These can be classified in three categories: open, controlled, and protected.
Summary on the different levels
— Open
— Uncontrolled - e.g. unattended ATM, Gas pump, kiosk. Device is used in an unprotected or hostile
location. Assumes an attacker may have prolonged physical access. Requires strong tamper
resistance and automatic zeroization.
Typical use cases: Payment terminals, ATM key load modules, PIN pads.
— Controlled
— Minimally controlled - e.g. merchant location with PIN entry devices that are maintained inside a
store. Physical access is restricted but not highly secure. Assumes attackers may gain access through
compromise of facility controls. Requires tamper detection and protection against invasive probing.
Typical use cases: General purpose network HSMs, data centre appliances.
— Controlled - e.g. computer room with access controls. Interior and exterior surveillance. Device
resides in a secure room or data centre with physical security controls. Assumes limited opportunity
for prolonged physical attacks. Requires tamper evidence, controlled service interfaces, monitored
access.
Typical use cases: CA HSMs, payment HSMs, key management servers, enterprise cryptographic
modules.
— Controlled-plus environments - e.g. installation within a secure cabinet where it is itself installed in
a controlled environment. Device is operated in a high assurance, controlled environment
Physical access by unauthorized personnel is very unlikely.
Device protections can rely more on the surrounding environment.
Typical use cases: HSMs in multi-layer secure vaults, central-bank crypto systems.
— Protected
— Protected environment- e.g. Key Loading Facility (KLF) this is considered to considerably more
secure than a controlled environment. Only individuals with authorized access to use the device are
permitted access to the environment hosting it (which could be cabinet, room or safe). Protected
environments are often located within a controlled environment. Environment provides highest
physical protection, multiple security layers, audit controls. Device may rely on the environment
rather than maximal onboard tamper resistance.
Typical use cases: Tachograph key personalization stations, SE provisioning centres, card issuance
machines.
4.2.2 Logical and physical connectivity
The HWSB product can be connected to local or external applications. Depending on the security in the
local environment these may be protected or not. For remote or hostile connections, secure channel is
mandatory.
4.3 Distribution of security functions
4.3.1 HWSB Integration
This clause describes the HWSB market.
The HWSB can be sold as
— a complete product to open market for the end usage of a legal person or a specific business;
— a platform to a manufacturer who loads its own applications to make a product;
— a component to be integrated a larger product.
4.3.2 Objectives on the environment
4.3.2.1 General
The following objectives define the conditions on the environment under which the security objectives
of the HWSB can be achieved. They describe the expected protect provided by the development,
operational, and application environments in which the HWSB is used.
4.3.2.2 Protection of data outside the HWSB
It is assumed that any data originating from or protected by the HWSB, when stored or processed outside
the HWSB, is protected by external entities (e.g. client applications or systems) according to the risks of
the deployment environment.
This applies in particular to:
— Cryptographic keys,
— Logs,
— Backup data,
— Software images and related artefacts.
Backup data shall be:
— Strictly controlled in terms of creation, storage, and usage,
— Limited to the minimum number of copies required for service continuity,
— Protected such that restoration of the HWSB requires at least dual control by authenticated
administrators.
4.3.2.3 Definition and enforcement of key management policies
It is assumed that comprehensive key management policies are defined and enforced in the operational
environment. These policies include:
— Constraints on key usage and clearly defined scope of use,
— Separation of duties and dual control for sensitive key operations,
— Monitoring for anomalous key usage (e.g. unexpected volume or operations),
— Definition of recovery procedures (revocation, re-issuance).
Keys are updated:
— When compromised,
— Periodically, according to defined policies,
— With minimized lifetime for high-value keys.
Key update mechanisms may include:
— Key injection,
— Key activation,
— Key generation.
4.3.2.4 Protected operating environment
It is assumed that the HWSB operates within a protected environment that:
— Restricts physical access to authorized administrators only
— Ensures that hardware, software, and client applications are installed and maintained securely
— Mitigates risks of physical and logical compromise
This includes physical protection of the hosting environment and enforcement of access control policies.
4.3.2.5 Operational security controls
It is assumed that the entity deploying and operating the HWSB enforces appropriate organizational and
procedural controls based on the intended use case and associated risks.
These controls include:
— Physical protection of equipment,
— Access control for authorized roles,
— Separation of duties and dual control for sensitive operations,
— Key management practices (e.g. rotation, lifetime limitation),
— Operational recovery procedures (revocation, restore),
— Monitoring for anomalous usage.
Where specific environmental protections are required, they are defined in user guidance.
4.3.2.6 Correct use of cryptographic services
It is assumed that client applications correctly and securely use the cryptographic services of the HWSB.
In particular, they:
— Provide correct and authentic input data (e.g. Data to be signed (DTBS) for signatures),
— Ensure integrity and confidentiality of exchanged data,
— Properly manage outputs such as signatures,
— Perform necessary verification checks where required.
Client applications are also responsible for:
— Logging usage of HWSB services,
— Supporting secure procedures for initial configuration and ongoing operation.
These assumptions also apply to internal applications without external client applications.
4.3.2.7 Secure user authentication handling
It is assumed that client applications:
— Correctly collect user identification, authentication, and authorization data,
— Protect this data during transmission to the HWSB (e.g. confidentiality protection),
— Ensure that only properly authenticated users can access HWSB services and assets.
4.3.2.8 Audit data management and review
It is assumed that:
— Audit data generated by the HWSB is collected, stored, and reviewed,
— A System Auditor performs regular analysis according to defined procedures.
This reflects the assumption that the HWSB operates within a larger system where audit responsibilities
are handled externally.
4.4 Users
Users of the HWSB product may represent different types o
...