01. Background | What is this standard and why does it matter?
The EU Cyber Resilience Act (CRA, Regulation EU 2024/2847) has officially entered into force, establishing mandatory cybersecurity requirements for all digital products placed on the EU market. For the specialized category of secure hardware, the European Commission mandated the development of the harmonized standard prEN 40000-11:2026. This standard provides a clear, actionable CRA compliance path specifically tailored for Hardware Devices with a Security Box (HWSB).
An HWSB is a hardware component that protects sensitive data and cryptographic keys through physical tamper-protection countermeasures. This encompasses Hardware Security Modules (HSMs), payment terminals, eIDAS-compliant electronic signature devices, smart tachographs, and similar appliances. Because the security of these devices relies heavily on physical architecture as well as software, they require a dedicated evaluation framework that horizontal standards cannot fully provide.
Conformity with prEN 40000-11 grants a presumption of conformity with the CRA and authorizes manufacturers to affix the CE cybersecurity marking—a mandatory prerequisite for entering the EU market.
02. Scope & Applicability | What's in and what's out?
This standard applies to any hardware system component that incorporates a "security box"—meaning a physical enclosure that features tamper-evidence, tamper-resistance, or active tamper-response protection. Typical products in scope include general-purpose and payment Hardware Security Modules (HSMs), PCI-POI/HSM payment terminals, eIDAS-compliant Qualified Signature Creation Devices (QSCDs), smart tachograph equipment, and FIPS 140-3 Level 3 to 4 cryptographic modules.
Pure software security products, bare microprocessors or Application-Specific Integrated Circuits (ASICs) lacking an execution environment, operating systems, container runtimes, and fixed-function devices without management interfaces fall outside the scope of this standard.
A crucial boundary condition to emphasize: if a product relies on cloud or remote services to execute any of its features, Annex R (Remote Data Processing Solutions, RDPS) becomes applicable. This annex introduces 18 additional requirements covering mutual authentication, data integrity, availability, and failover. Because neither PCI PTS nor EN 18031 covers this specific ecosystem, all compliance evidence for RDPS must be built from the ground up.
03. Standard Structure | How it is organized
The standard is structured into six core clauses and six annexes. The most commercially vital elements are concentrated in the following sections:
- Clause 5: Defines 18 technical requirement families that the product must satisfy.
- Clause 6: Clarifies how compliance must be demonstrated through document review, functional testing, and vulnerability analysis.
- Annex A: Provides two distinct pathways for selecting the applicable "Security Profile."
- Annex K: Mandates that all default cryptographic algorithms must be listed in the ECCG ACM catalogue maintained by the European Union Agency for Cybersecurity (ENISA).
- Annex ZA: Maps each requirement of the standard directly to the essential CRA cybersecurity requirements—forming the core foundation for drafting the Declaration of Conformity.
Before entering the evaluation phase, every product must define its Security Profile. The standard provides two methods to achieve this:
- Route 1: A risk-based self-assessment evaluated across five vectors: attacker expertise, motivation, deployment environment, regulatory context, and network exposure.
- Route 2: Pre-defined templates tailored to recognized product categories. For instance, a payment terminal can instantly adopt a predefined profile and proceed directly to module selection, skipping the need for a ground-up risk analysis.
04. Key Technical Requirements | What organizations must do
The 18 technical requirement families span the entire security lifecycle of HWSB products. Six primary areas demand the utmost attention from manufacturers:
1. Physical Security (REQ-PHY)
The defining characteristic of an HWSB. Products must incorporate tamper-evidence (visible signs of interference), tamper-resistance (deterrence against physical penetration without specialized tools), and active tamper-response (automatic zeroization/erasure of cryptographic keys upon intrusion detection). High-assurance modules are further required to include mesh-based sensors enclosing all areas handling plaintext keys.
2. Cryptography (REQ-CRY)
All default algorithms must be listed in the ECCG ACM catalogue, and products must support crypto agility—possessing a documented mechanism to update algorithms before they become obsolete. Furthermore, minimizing side-channel leakage and enforcing secure key deletion (overwriting/zeroization) are explicitly mandated; these two elements are unique to this standard and lack direct counterparts in PCI PTS or EN 18031.
3. Authentication & Authorization (REQ-USER-AUTH)
Requirements include brute-force lockouts, re-authentication after session timeouts, Multi-Factor Authentication (MFA) for human users, and Device Attestation for machine-to-machine scenarios. MFA and Device Attestation are distinct additions for HWSBs, as neither PCI PTS nor EN 18031 contains equivalent mandates.
4. Security Audit (REQ-LOG)
This is where the most common compliance gaps occur. The standard mandates tamper-protected logging of all security-relevant events, with every entry strictly tied to an authenticated user. PCI PTS entirely lacks logging requirements, while EN 18031 only references them in its -3 variant for financial assets. If aiming for Module 6 (Enhanced Audit), organizations will need to engineer this capability from scratch.
5. Secure Communications (REQ-SEC-COM)
Communication channels must guarantee confidentiality, integrity, and mutual authentication while enforcing strict session timeouts. In this domain, PCI PTS provides the most rigorous overlap (explicitly mandating TLS 1.3), making it a highly reliable source of existing compliance evidence.
6. Secure Firmware Updates (REQ-COP-SECUP)
Firmware images must be cryptographically signed and verified prior to installation, require explicit user authorization before deployment, and strictly prevent rollbacks to vulnerable earlier versions. This anti-rollback requirement is an HWSB-specific addition not found in standard PCI PTS or EN 18031 frameworks.
05. Vulnerability Handling | Meeting the Standard's Criteria
The standard adopts a two-tier model for vulnerability management. The procedural framework—encompassing public disclosure policies, continuous monitoring of the EU Vulnerability Database (EUVD) and National Vulnerability Database (NVD), and coordinated disclosure procedures—is governed by the horizontal standard prEN 40000-1-3. On top of that, prEN 40000-11 superimposes three HWSB-specific assurance requirements:
- First, the vulnerability handling process itself must be demonstrably compliant, ensuring an end-to-end lineage from discovery and tracking to mitigation and public disclosure.
- Second, products must be shipped with zero known exploitable vulnerabilities; evaluation reports must justify every identified flaw, proving it is either mitigated or non-exploitable within the product’s intended environment.
- Third, a Software Bill of Materials (SBOM) must be provided, detailing all hardware components, firmware, dependencies, and version numbers so downstream users can continuously monitor component-level security.
06. Compliance Roadmap | Executing the Standard Effectively
Select either Route 1 (risk-factor evaluation) or Route 2 (product type template) to establish your product’s applicable modules. Document the "Intended Use and Reasonably Foreseeable Use" (IPRFU). This document drives the entire evaluation and must be finalized before compiling any compliance evidence.
If your product holds a PCI PTS POI v7.0 or EN 18031 certification, systematically map these assets against prEN 40000-11. Historically, a PCI PTS POI v7.0 certification satisfies roughly 60% of the requirements; EN 18031 yields about 40%. Pinpointing the exact gaps is the most effective way to control assessment budgets.
For each identified gap, produce the necessary documentation aligned with your target assurance profile. A Basic profile requires Functional Specifications (ADV_FSP), Design Documentation (ADV_TDS), Operational Guidance (AGD_OPE), and Functional Testing results (ATE_FUN). A High Assurance profile mandates additional Implementation Reviews (ADV_IMP), Independent Testing (ATE_IND), and a comprehensive Vulnerability Analysis (AVA_VAN).
The evaluator will systematically assess your product following the sequence of Clause 6: reviewing documentation, executing functional tests, and conducting vulnerability analyses. Under a High Assurance profile, evaluators may carry out sophisticated physical attacks, including fault injection and side-channel analysis, to verify that declared security controls survive real-world adversarial conditions.
07. Evidence Reuse | Leveraging PCI PTS and EN 18031 Data in CRA Assessments
For manufacturers with existing PCI PTS POI v7.0 or EN 18031 certifications, evidence reuse is the most direct mechanism to compress prEN 40000-11 evaluation costs and accelerate time-to-market. Here is how these frameworks map onto the new standard’s requirement families:
PCI PTS offers powerful coverage in five of the six critical areas. Its Attack Potential calculations and penetration testing logs directly support physical security requirements; its comprehensive Device Technical Reports (DTRs) on DRBG validation, key management, and algorithm implementation align cleanly with REQ-CRY; its authentication controls (PIN protection, session management, brute-force rate limiting) cover the bulk of REQ-USER-AUTH; its communication clauses are among the most prescriptive available (explicitly requiring TLS 1.3), mapping smoothly to REQ-SEC-COM; and its firmware signing constraints bolster REQ-COP-SECUP.
EN 18031 provides complementary coverage in secure communications, authentication, and generic security controls, acting as a valuable supplement to PCI PTS evidence. Notably, the Logging Mechanism (LGM) requirement family in EN 18031-3, which applies to financial asset products, can partially support basic audit logging requirements, though it falls short of the tamper-proof auditing and definitive user attribution demanded by Module 6.
In summary, leveraging PCI PTS and EN 18031 allows manufacturers to harvest extensive reusable evidence across physical security, cryptography, authentication, communications, and firmware updates. Net-new investments will primarily center on engineered secure audit logging, anti-rollback logic, fault-injection testing, and (for cloud-connected devices) the complete 18-requirement suite of Annex R (RDPS).
