CEN-CENELEC needed a horizontal standard for products meeting the “HWSB” (Hardware Security Box) definition — a category spanning hardware security modules (HSMs), payment terminals, and tachograph cybersecurity modules. These products already certify against mature schemes: Common Criteria, FIPS 140-3, PCI, and CSPN. But the Cyber Resilience Act adds a new layer of obligations that applies horizontally, to every connected hardware product, regardless of sector. The job was to map those CRA obligations onto the certifications manufacturers already hold — giving regulators, labs, and conformity assessment bodies one harmonised reference instead of four sector-specific ones, and sparing manufacturers a second round of work they’d effectively already uploaded.
A Hardware Security Box is a physically protected device built to safeguard sensitive operations — key storage, cryptographic processing, transaction validation — against physical and logical tampering. An HSM, a payment terminal, and a tachograph module look like very different products, but they share one architecture: a tamper-resistant enclosure guarding cryptographic assets. That shared structure is what makes a single horizontal standard possible in the first place.
Deliver one standard that maps CRA obligations onto the existing certification baselines — Common Criteria, FIPS 140-3, PCI, and CSPN — without re-opening or contradicting them, and have it hold across product families that share only a single structural trait: reliance on a physically protected box. For a manufacturer of HSMs, payment terminals, or tachograph modules, the target was a single compliance path aligned with the regulations already in force (CRA and NIS 2) — not a separate certification effort bolted on for each new rule.
The four existing schemes each bring their own methodology, vocabulary, and evidence expectations. Reconciling them into one horizontal document that regulators, labs, and manufacturers could all trust — without flattening the differences that matter — was the core difficulty. The hard constraint: manufacturers could not be asked to redo work already completed under their existing scheme. Re-certifying from scratch would impose real cost and delay across the industry for no security gain. The standard had to let existing evidence carry forward, not reset the clock.
01
Assembled a multi-disciplinary team covering Common Criteria, FIPS 140-3, PCI, CSPN, and cryptographic evaluation.
02
Identified what all HWSB products have in common at the technical level, despite different use cases and regulatory histories.
03
Expressed requirements around the real-world risks of how each product is used, rather than copying scheme-specific checklists.
04
Built scheme-agnostic evaluation methods compatible with all four baselines, so manufacturers could reuse evaluation evidence they already had.
05
Mapped CRA requirements against those baselines, pinpointing exactly where CRA is already satisfied and where new evidence is genuinely needed.
A risk-based approach is what makes this possible: tie requirements to how a product is actually used, and multiple schemes, assurance levels, and methods can coexist in one coherent document. The other lesson is where to start. Beginning from the shared technical description of a product family — not from any one existing scheme — keeps the result compatible with all of them. That method transfers directly to any other category facing the same problem: fitting CRA’s horizontal, cross-sector obligations onto mature, sector-specific schemes that industry and regulators already trust.
HSMs, payment terminals, and tachograph cybersecurity modules — any device whose core function is protecting cryptographic operations inside a tamper-resistant hardware enclosure.
No. It maps onto them. Existing certifications keep their value; the standard shows where they already meet CRA and where a manufacturer needs to add evidence.
We’ll send you access by email.
