Is one vendor enough or do we need several?

A single vendor can simplify integration and operations. Different requirements may call for different platforms. We first separate security domains and use cases. Whether this requires multiple vendors is a reasoned decision; separation alone does not automatically require different brands.

What does post-quantum cryptography mean for existing devices?

PQC support depends on hardware, firmware, interfaces and applications. An announced update does not prove a production-ready validated configuration. We inventory keys and protocols, check the vendor’s current implementation and plan compatible transitions, including counterpart systems and recovery.

Products

Hardware Security Modules: Keys in Certified Hardware

HSM solutions for PKI, code signing, payments and key management: we compare seven vendors, test the actual integration and support selection, commissioning and agreed operational tasks.

Try product

FIPS 140-3 Level 3
Common Criteria EN 419 221-5
PCI PTS HSM
eIDAS QSCD

Hardware security modules at a glance

A hardware security module protects cryptographic keys and performs supported operations within a defined security boundary. Whether a key can be exported depends on its configuration and the supported procedure. PKCS #11, CNG or Java providers and key-management interfaces serve different purposes. We assess the complete application path rather than relying on an interface name.

Cryptography and hardware security modules are our core competence. We know the series of the vendors, the certificate numbers of the approvals and the limits of each single platform. We guide your project from the selection through the key ceremony into daily operation.

Certification levels: FIPS / Common Criteria / PCI PTS: verify the specific module and configuration
Interfaces: PKCS#11, CNG, JCE, KMIP, REST
Fields of use: PKI, payments, code signing, key management
Operating models: Own data center, operated by us, as a service

Four fields of use for hardware security modules

Four common tasks illustrate where HSMs can help. Required evidence and protection mechanisms depend on the application and its specific requirements. An HSM alone does not establish the security or compliance of the complete environment.

PKI and certificates

Root and issuing CAs can use private keys through a supported HSM integration. Certificate profiles, roles and revocation procedures must also fit. A compromised CA server may still submit unauthorized requests despite protected key material, so application controls and approvals remain essential.

Payments

Payment HSMs support designated functions for PIN processing, card keys or key distribution. We assess commands, key procedures, partner requirements and the device’s specific approval status. A general-purpose HSM is not automatically a substitute.

Code signing and the software supply chain

HSM-backed signing can protect keys used for software and firmware. The process must also define who may approve and sign each artifact. Key-storage requirements are assessed for the certificate and trust model being used.

Databases, storage and cloud keys

A key-management system can connect applications and storage through supported protocols such as KMIP and use an HSM as a protection component. For BYOK, external key management and envelope encryption, we examine where each key is used and who can request operations. BYOK alone does not rule out provider access to data.

Our vendors

How to pick the right model

Four questions decide the vendor and the series: the required certification level, the necessary performance, the interfaces of your applications and the operating model. We settle them in a workshop and record the result in a decision paper.

Certification level

The required evidence depends on the use case. We check the certificate, status, hardware and firmware versions and documented operating conditions. FIPS, Common Criteria and payment assessments have different scopes. A single certificate does not automatically validate the complete solution.

Performance and tenant separation

Throughput is only comparable with matching algorithms, key sizes, concurrency and client connections. We also measure latency and failure behavior. Tenant separation depends on permissions, shared resources and administration, not just partition counts.

Integration

Providers, mechanisms and key attributes must match the application. A simulator can answer initial development questions but does not prove hardware behavior, performance or a validated operating mode. Representative testing uses the intended target environment.

Operating model

Owned hardware, delegated operation and managed services differ in responsibility, cost and availability. Locations and regions are explicitly agreed. Backup, recovery, vendor support and a future exit belong in the same decision.

Standards and evidence

Assessments and regulatory requirements are not interchangeable quality labels. We map evidence to the specific module, its version and the intended use. Status is checked with the responsible authorities before procurement.

Requirement / Demands / OTOKO® delivers
Requirement	Demands	OTOKO® delivers
FIPS 140-3	Validation of a cryptographic module within a defined scope	Check CMVP certificate, Security Policy, versions, mode and status
Common Criteria	Evaluation against a specific Security Target or Protection Profile	Match the evaluated configuration and requirements to the intended use
PCI PTS HSM	Payment-specific device requirements	Check the specific model, version, approval and operating requirements
eIDAS / QSCD	Requirements for particular trust services and signature creation devices	Assess the complete intended service and applicable device evidence; an HSM alone is insufficient

Frequently asked questions about hardware security modules

You would like to learn more about