# Phoeniqs Cloud HSM

Phoeniqs Cloud Hardware Security Module (HSM) Service is a Swiss-hosted key management platform that supports a comprehensive set of cryptographic algorithms, including quantum-safe, designed for organizations that need the highest levels of security, sovereignty, and operational resilience. Built on FIPS 140-2 Level 4–certified IBM CryptoExpress 8S hardware and IBM LinuxONE with Hyper Protect Virtual Servers, it delivers a true hardware root of trust where master keys never leave the HSM and all cryptographic operations are performed inside tamper-responding, confidential-computing enclaves. The service implements a Keep Your Own Key (KYOK) model: customers generate and control their master keys on IBM Trusted Key Entry (TKE) smart cards under quorum ceremonies, while Phoeniqs operates the infrastructure without any access to customer key material.

The platform is stateless by design— keeping most secrets outside the HSM in wrapped and MACed form — allowing HSM domains to be added horizontally for near-unlimited scalability, high throughput, and low latency. Dual data center deployment on separate IBM LinuxONE systems provides automatic failover and continuous availability, making the service suitable for mission-critical workloads such as online banking, identity, and core data protection. Customers benefit from a broad cryptographic portfolio, including widely used algorithms such as ECC, RSA, AES, and cryptographically secure random number generation, as well as post-quantum algorithms (CRYSTALS-Kyber and Dilithium), all exposed through enterprise-grade PKCS#11 and gRPC (Grep11) APIs.

Operationally, the service offers transparent, fully auditable key ceremonies, controlled master key lifecycle management (creation, rotation, backup, and decommissioning). A standard price plan provides geo-redundant master key domains (primary and failover) on a monthly subscription with a one-time setup fee covering the TKE ceremony and issuance of HSM smart cards. Together, these elements position Phoeniqs Cloud HSM Service as a turnkey, high-assurance KYOK solution for banks, public-sector institutions, and regulated enterprises that must prove not only that their data is encrypted, but that they—and only they—control the keys.

Effective key management is critical to any business that relies on encryption for protecting customer data, intellectual property, and regulated information, because whoever controls the keys ultimately controls access to the data—regardless of where it is stored. At the heart of strong key management is a Hardware Security Module (HSM), which acts as a hardware root of trust: a dedicated, tamper-resistant device where cryptographic keys are generated, stored, and used without ever being exposed in plaintext to the outside world. IBM’s CryptoExpress 8S goes even further by being essentially stateless: it keeps long-term secrets outside the hardware in wrapped form, so the HSM primarily performs cryptographic operations rather than storing large numbers of keys. This stateless design allows additional HSM domains to be added horizontally with minimal coordination, enabling the service to scale almost without limit as demand grows, while still providing tamper-responding protection that zeroizes sensitive material and renders the module inoperable if physical intrusion is detected.

In the cloud, two common approaches have emerged: Bring Your Own Key (BYOK) and Keep Your Own Key (KYOK). With BYOK, organizations generate and own their keys but then load them into the cloud provider’s key management service, gaining better control and auditability than provider-managed keys, but still relying on the provider’s infrastructure and trust model. KYOK goes a step further: keys are generated, stored, and managed entirely under customer-control, and the cloud provider never can see, use, or export them, significantly reducing insider risk, strengthening sovereignty, and simplifying compliance narratives. BYOK can be simpler and cheaper to adopt, while KYOK offers stronger guarantees of separation of duties and long-term control, especially when implemented with dedicated HSM domains as the foundation of the key lifecycle. This is exactly the problem our HSM-based KYOK offering is designed to solve.

Because this HSM platform is exposed as an internal “crypto utility” with standard APIs, hundreds of applications and millions of daily transactions can use the same pool of devices. New projects don’t need to buy their own hardware or invent their own key management—they simply onboard to the HSM service, which already provides high availability, key rotation, dual control, and full audit trails. In this way, a relatively small number of HSM domains can safely support massive transaction volumes across online banking, trading, and data protection, turning strong cryptography into a scalable shared service for the entire institution.

Phoeniqs Cloud HSM service delivers enterprise-grade cryptographic security designed for organizations that require uncompromising key custody, governance, and resilience. Built on FIPS 140-2 Level 4 certified IBM Crypto Express8S hardware security modules (HSM) and hosted in Switzerland's strict data protection jurisdiction, this service combines three critical security components: stateless HSM architecture ensuring no customer data or operational keys are stored on the hardware; exclusive Master Key custody with Master Keys held exclusively by customers on IBM Trusted Key Entry (TKE) HSM smart cards, created through professional key ceremonies under quorum control; and confidential computing with all cryptographic services providing hardware-enforced isolation and runtime protection.

• Tamper-responding secure hardware engineered for FIPS 140-2 Level 4 with protections against physical penetration, side-channel attacks, and environmental manipulation, destroying secrets and disabling the HSM upon tamper detection.
• Exclusive Master Key Control: Customers retain exclusive control of their Master Keys created through professional key ceremonies under quorum control. Phoeniqs cannot access customer Master Keys.
• Dual Data Center Redundancy: Customer Master Keys are deployed in geographically independent data centers with automatic failover for continuous operation.
• Transparent Operations: Observable provisioning, verifiable key ceremonies, and fully auditable processes. Administrative commands are signed by M-of-N administrators before the command is accepted by the HSM.
• Confidential Computing: HSM services run within IBM trusted execution enclaves with hardware-enforced isolation.
• Swiss Data Sovereignty: Hosted in Switzerland with strict compliance to data protection regulations.
• Hardware Supported Cryptographic Algorithms: AES, HMAC, CMAC, RSA to 4096-bit, Elliptic Curve, Brainpool, Curve25519, Curve448.
• Quantum-Safe Key Encapsulation: CRYSTALS-Kyber.
• Signature Generation/Verification: ECDSA, EC-SDSA, EdDSA, RSA-PSS, CRYSTALS- Dilithium.
• Reliability, Availability, and Serviceability (RAS) with continuous real-time self-check.
• Generation of high-quality random numbers.
• The system is stateless, keeping most of the secrets outside the HSM in wrapped and MACed form, allowing maximizing throughput and a potential unlimited number of users.

The following price plan covers the monthly service cost for a fully redundant Master Key domain as well as the one-time setup required to establish secure operations. Master keys are provisioned in geo-redundant pairs, with one primary and one backup domain in active configuration. Because fault tolerance always requires two Master Key domains, the service is priced at CHF 3,000 per month in total (CHF 1,500 per domain per month), plus a one-time setup fee of CHF 1,500 covering the Trusted Key Entry (TKE) ceremony and issuance of primary HSM smart cards. Backup HSM Smart Cards are priced separately. Due to the stateless design, customers typically only need a single Master Key and associated HSM Smart Cards.

• CHF 1,500 Master Key domain (primary) per month
• CHF 1,500 Master Key domain (failover) per month
• CHF 1,500 One-time setup fee including Trusted Key Ceremony and 5x HSM Smart Cards
• CHF 1,000 One-time fee for 5x Backup HSM Smart Cards

_{The TKE ceremony includes two hours of support from a Phoeniqs subject-matter specialist; additional assistance can be purchased. HSM smart cards are provided for master key parts and domain administration, and additional cards are available for purchase if required. For additional and updated information about service prices, click here.}

This HSM service is designed for organizations that require the strongest possible assurances in cryptographic security, operational integrity, regulatory compliance, and long-term data protection. It delivers capabilities that go beyond typical cloud key management solutions, providing customers with full control of their keys, transparent and auditable operations, continuous availability, and protections rooted in certified hardware security. The following eleven sections explain why customers choose this service and how each capability supports high-assurance, mission-critical environments.

Cloud HSM services are useful anywhere organizations need strong, auditable protection for cryptographic keys without running physical hardware themselves. Typical use cases include protecting encryption keys for databases and object storage, meeting compliance requirements (like PCI DSS, GDPR, HIPAA) that demand hardware-backed key management, and securing root keys for PKI and certificate authorities. They’re also widely used for code signing and software supply chain security, payment and banking cryptography (e.g., card data, tokenization keys), and securing identities and tokens in SSO/IdP systems. Increasingly, organizations also use Cloud HSMs to experiment with and deploy quantum-safe algorithms, so their “crown jewel” keys and signatures remain secure long term.

• Encryption and decryption operations for sensitive application data (e.g., PII, financial data, healthcare)
• Database encryption use cases, including transparent and application-level encryption
• File and object storage encryption
• Private key generation and certificate signing for TLS and PKI deployments
• Client and device certificate issuance
• Code-signing operations for software binaries, containers, and update packages
• Software supply chain signing and release integrity
• Tokenization systems and digital asset custody
• Electronic signature and legally binding signing workflows
• Signing of identity and access tokens (OAuth tokens, JWT signing)
• Protection of API keys and service credentials
• Adopting post-quantum cryptographic algorithms for long-term key and signature protection

Customers who require the highest assurance —banks, governments, telecom, healthcare— must use hardware that:

• Detects tampering
• Auto-zeroizes keys
• Becomes inoperable under attack

This assurance is essential for environments handling root certificates, identity systems, or national-level secrets.

Customers control their Master Keys through quorum-controlled key ceremonies, meaning:

• The provider cannot access keys
• No insider can extract keys
• Auditors can verify key custody

This control is critical for regulatory compliance, zero-trust architectures, and environments where trust boundaries must be explicit.

To ensure high availability and cross–data-center continuity, the architecture spans pool of two IBM LinuxONE systems in separate sites, each with IBM Crypto Express8S adapters—two active for primary live cryptographic operations and for fault tolerance with identical customer HSM domains and Master Key data. Domains are provisioned on both adapters and mirrored across both systems for adapter-level and site-level resilience. If an active adapter or host becomes unavailable, cryptographic operations are redirected to the to the corresponding domain hosted in the alternate data center. Because all customer domains are pre-initialized and Master Key–activated through the TKE, failover resources are ready for immediate use without any key re-entry or re-enrollment. The underlying LinuxONE and Grep11 infrastructure routes cryptographic requests to the available adapters, minimizing interruption to customer applications. Master keys being replicated across independent data centers with automatic failover ensures:

• No downtime if a data center fails
• No lost keys
• Cryptographic operations continue uninterrupted

This fault tolerance matters for authentication services, and 24×7 production environments.

Customers benefit from observable provisioning, verifiable ceremonies, and M-of-N signed administrative commands, enabling:

• Full auditability
• Compliance with strict internal and external controls
• Assurance that no unauthorized operation can occur

This verifiable ceremony appeals to organizations governed by PCI, eIDAS, GDPR, banking supervisory rules, and national security frameworks.

Running HSM services inside trusted execution enclaves prevents:

• Cloud administrators from accessing memory
• VM escape attacks
• Malware or tenant cross-contamination

These enclaves allow sensitive HSM workloads in cloud environments without sacrificing confidentiality.

Switzerland has a reputation that projects:

• Strict privacy protection
• Stable jurisdiction
• Strong legal frameworks for confidentiality

This sovereignty is highly desirable for finance, wealth management, healthcare, and international organizations.

Customers require a broad cryptographic portfolio, including:

• RSA up to 4096 bits and symmetric cryptography such as AES
• Modern elliptic curves (secp, Brainpool, Curve25519, Curve448)
• High-performance ECDSA, EdDSA, and Schnorr-based signatures
• Hardware-based true random number generation (TRNG)

This algorithm support ensures compatibility with existing and next-generation applications.

Enterprises preparing for the impact of quantum computing are increasingly adopting post-quantum cryptographic capabilities, including:

• Post-quantum key encapsulation mechanisms (KEMs)
• Post-quantum digital signatures

This is driven by the “harvest now, decrypt later” threat model, where encrypted data captured today may become vulnerable once sufficiently powerful quantum computers become available.

Quantum-safe cryptography is particularly critical for protecting long-lived data that must remain confidential for decades, such as healthcare records, government documents, financial records and transaction histories, and identity credentials.

Real-time self-checks, stateless design, and externalized wrapped secrets allow:

• High concurrency and scalable request handling
• Independent scaling and operation of service components without impacting existing applications
• Fault tolerance without compromising cryptographic security guarantees

These RAS features are key for large-scale identity providers, financial exchanges, and authentication platforms.

Horizontal scalability is achieved by adding additional HSM domains, each acting as an independent, isolated security context that can be provisioned on demand. Because the service is effectively stateless—with long-term keys stored in wrapped form outside the HSM hardware—new domains can be brought online without complex reconfiguration or internal key migration.

If an additional master key domain is requested, it is initialized on extra crypto adapters in a configuration equivalent to the first pair, spanning two IBM LinuxONE systems in separate sites. With two pairs of domains, a customer can utilize up to four HSMs in parallel, distributing cryptographic workloads across a larger pool of hardware. This horizontal scaling not only preserves strong isolation and consistent policy enforcement, but also delivers higher aggregate throughput and lower latency, making the service significantly more performant as demand grows.

The Phoeniqs Cloud HSM Service architecture provides a high-assurance, stateless Hardware Security Module (HSM) service built on IBM LinuxONE, IBM Hyper Protect Virtual Servers (HPVS), and FIPS-validated HSM hardware. It is designed for cryptographic operations requiring the highest security, transparency, and continuity.

The service is deployed across two independent IBM LinuxONE data centers (DC1 and DC2). Each data center hosts an identical and fully functional HSM service stack, enabling:

• Geographic redundancy
• Automatic failover
• Continuous service availability
• Resilience against regional outages

Clients interact with the service through a single, load-balanced endpoint, ensuring transparent distribution across both sites.

Each cryptographic card is associated with its own dedicated LinuxONE LPAR running Ubuntu as the primary compute environment. Within each LPAR:

• Hypervisors (KVM) provide virtualization
• IBM Hyper Protect Virtual Servers (HPVS) host the cryptographic service logic

HPVS enforces secure execution enclaves, ensuring:

• Hardware-isolated execution
• Encrypted memory
• Protection from privileged insiders, including cloud administrators
• Attestation of the runtime environment

HPVS creates a trusted execution environment for the HSM service.

Within each HPVS enclave runs the Grep11 HPVS instance (the application layer providing the PKCS#11-compatible API). These instances:

• Are stateless and do not persist any cryptographic key material inside the HPVS environment
• Act as a secure application layer that brokers cryptographic operations to the HSM hardware
• Are deployed as encrypted workloads that are only decrypted and instantiated inside the HPVS trusted execution environment

Each data center hosts cryptographic cards that contain the customer HSM domains, where the customer key material is initialized and protected, and to which HPVS directly connects.

The HSM provide:

• Physical tamper-response
• Zeroization on intrusion attempts
• Protection against power, temperature, and side-channel manipulation
• Master key storage
• Cryptographic operations requiring secure boundary enforcement

Master key material exists and is protected exclusively within the HSM boundary and is never exposed outside the HSM.

Customer Master Keys are created and controlled by the customer via:

• Formal key ceremonies
• Quorum (M-of-N) authorization
• Signed administrative commands

HSMs verify signatures before accepting administrative actions. The service provider cannot access or unseal customer Master Keys.

To maximize throughput and user scalability:

• Only the Master Keys live inside the HSMs
• All other keys are stored externally by the customer in wrapped and MACed form
• Grep11 HPVS retrieves, unwraps, and uses keys ephemerally
• No persistent secrets reside on the service nodes

This design supports large-scale multi-tenant workloads while retaining FIPS-compliant boundaries.

Clients connect via a unified endpoint:

• Load balancer provides routing across DC1 and DC2
• All connections use mutual TLS (mTLS)
• Clients are identified and authenticated via certificate-based trust
• IP whitelisting capability is enforced at the endpoint
• The load balancer ensures even traffic distribution, health-based routing, and continuous service without requiring clients to manage site failover.

Security and Traffic Confidentiality:

• The load balancer operates in TLS passthrough mode
• Traffic is not terminated or decrypted at the load balancer
• End-to-end encryption is preserved from the client to the workload
• TLS termination and decryption occur only inside the confidential compute environment (HPVS)

Enterprise PKCS#11 over gRPC (grep11) API integration provides high-performance cryptographic operations optimized for enterprise workloads, full compatibility with enterprise and regulatory cryptographic requirements, custom application development capabilities, and a stateless design ensuring no operational keys are stored in the service environment.

All customer HSM operational events are captured in audit logs to support security monitoring, forensic analysis, and compliance reporting. Logs only capture metadata and not customer key material. Logs are retained for 30 days on a rolling basis by default. Phoeniqs reserves the right to review non-customer diagnostic data to for reliability, serviceability and availability (RAS).

Public-sector institutions and regulated companies safeguard sensitive data such as citizen records, law enforcement data, revenues, health, social services and intellectual property while facing escalating cyber threats, strict sovereignty and privacy laws (e.g., Swiss DPA/GDPR), and intense scrutiny over operational continuity. The following procedure establishes customer dedicated, hardware-isolated IBM Crypto Express8S (EP11) HSM domains—with observable provisioning and a verifiable Master Key ceremony via IBM Trusted Key Entry (TKE)—to ensure full transparency and traceability from initialization through protection.

• The customer receives dedicated HSM domain(s), securely isolated at the hardware level
• Customer Master Key domain assignment occurs through a controlled provisioning process that customer personnel may observe
• During the Master Key ceremony, the customer can verify domain identifiers, confirm configuration, and participate in or witness Master Key entry via the TKE
• This process ensures full transparency and traceability in how customer’s domains are initialized and protected

A Key Ceremony is a formal, controlled, and auditable process used to create, activate, and manage a Master Key within a Hardware Security Module (HSM). Master key protects all other cryptographic keys used within the HSM domain and therefore serves as the root key for subsequent cryptographic operations.

The Key Ceremony is performed to ensure that:

• Master Key material is generated and activated under defined controls
• Responsibilities and authorizations are clearly separated
• All sensitive operations are observable and auditable
• No single individual can activate or control the Master Key alone

A Key Ceremony typically includes:

• Physical presence of authorized participants
• Clearly defined roles and responsibilities
• Use of hardware-based credentials (smart cards) for key parts and authorization
• Authorization controls enforced through TKE
• Documentation and evidence collection for audit purposes

Phoeniqs key ceremonies are conducted using IBM Trusted Key Entry (TKE) and take place at our secure facility in UpTown Basel, Switzerland.

The key ceremony is not just a technical procedure—it's your guarantee that you have exclusive, verifiable control over your cryptographic keys, with complete transparency and auditability. This is what sets enterprise-grade HSM services apart from basic cloud encryption.

The Phoeniqs Cloud HSM Service implements a strict security organization model based on IBM Trusted Key Entry (TKE) principles. This ensures complete separation of duties and customer control.

Customer

• Defines the number of domain pairs
• Assigns Domain Administrators, Master Key Custodians, and a Supervisor
• Defines quorum rules
• Performs all Master Key–related actions via TKE
• Retains custody of smart cards and credentials

Phoeniqs

• Operates HSM and TKE infrastructure
• Prepares the environment
• Provides technical and procedural support only Phoeniqs does not access customer keys, smart cards, PINs, or authorization data and cannot override quorum rules.

The table below summarizes the roles, organizational ownership, and responsibility boundaries between the customer and Phoeniqs during the Master Key Ceremony.

Before the ceremony, the customer must define:

• Number of Domain Administrators
• Number of Master Key Custodians (Master Key part holders)
• Number of backup set for Domain Administrator and Master Custodian smart cards
• Required authorization thresholds for Domain Administrators (e.g. 2-of-2, 2-of-3, 3-of-5)
• Number of HSM domain pairs to be provisioned
  • Each domain pair consists of two EP11 HSM domains
  • The two domains are deployed in separate data centers
  • Domain pairs are provisioned as a mandatory unit and are not separable

Domain Administrator authorization:

• Applies to domain initialization and administrative operations
• Cannot be bypassed after domain initialization

Master Key control:

• The Master Key is split into parts (2 or 3 parts)
• Each Custodian holds one Master Key part
• All parts (n-of-n) are required to generate and activate the Master Key
• Master Key parts are generated and loaded using TKE smart cards

The Master Key lifecycle encompasses all activities required to establish, maintain, use, and retire a customer’s Master Key within the HSM environment. This process spans from initial planning and assignment of key ownership through the creation of the Master Key, the generation of backup HSM smart card sets, and the operational use of the key within the service. Throughout the lifecycle, customers may request key rotation, renewal, or the creation of additional backup sets, each of which follows established, auditable procedures. The lifecycle concludes with secure off-boarding and decommissioning when the key is no longer required.

Roles and responsibilities for each phase are clearly defined to ensure accountability, separation of duties, and compliance with security and regulatory requirements. Master key Custodians, Domain Administrators, Supervisors, and Facilitators (TKE Administrators) each contribute specific functions—from holding smart cards and managing the HSM domain to monitoring ceremonies and providing technical support—ensuring that every step of the process is performed with accuracy, transparency, and integrity.

The following steps describe what is performed during the ceremony, in execution order. All steps apply consistently to both domains within each domain pair.

• Authenticate to the IBM TKE environment
• Start the TKE workstation and application

• Open the host overview in TKE
• Identify the crypto modules assigned to the customer and authenticate to them.
• Confirm that the assigned HSM domains are empty (no existing customer key material present) across all crypto modules
• Create and verify a domain group to associate the customer’s domains across all crypto modules
• Confirm that domain grouping ensures that all subsequent administrative updates and key- related operations are applied consistently across all crypto modules
• Capture screenshots of the host overview, domain state, and domain group configuration for audit evidence

• Initialize domain administrator and master key custodian smart cards
• Set PINs for all smart cards and label the cards accordingly
• Initialize backup smart cards for each role
• Each card holder is personally responsible for setting, remembering, and securely safeguarding their smart card PIN
• The smart card PIN must remain known to the responsible card holder throughout the ceremony and for all post-ceremony operations

• Open the domain group to associate the customer’s domains across all assigned crypto module
• Generate administrator signature key pairs on administrator smart cards
• Add all administrator signature keys in the domain group
• After all administrator keys are created and registered, configure the domain authorization threshold according to the customer-defined policy
• Back up administrator signature keys to secondary smart cards

• Master Key Custodians insert their smart cards
• Each Custodian generates one Master Key part under split knowledge
• Generated Master Key parts are securely stored on the respective custodian smart cards
• Back up master key parts to secondary smart cards

• Master Key Custodians load their Master Key parts via TKE
• TKE verifies that all Master Key parts (n-of-n) are provided
• TKE enforces the defined quorum and domain administrators provide their administrator signature keys according to quorum rule
• Once the required administrator signature quorum (threshold) is satisfied, the Master Key is committed in domain group
• Following a successful commit, the Master Key is activated in the associated domains.

• Record Master Key Verification Patterns (MKVPs)
• Capture Master Key status screenshots
• Verify all evidence is complete
• Supervisor signs the completion record
• Close the TKE session

After the Master Key creation and entry is completed, the HSM middleware service required for the customer is activated. Phoeniqs is responsible solely for ensuring the availability of the HSM and its related services. The generation, management, and secure storage of all operational and data keys created under the Master Key are the exclusive responsibility of the customer. The HSM service operates within confidential computing environment, providing isolated and hardware-based protection for key operations. It is stateless by design and does not retain or store any data keys within its environment.

Access to the HSM service is controlled through mTLS certificates managed by the customer. Network traffic remains encrypted end-to-end and is never decrypted prior to reaching the secure enclave. Data is decrypted only within the secure enclave, ensuring that sensitive information is never exposed outside the confidential computing environment.

Master-key rotation is a controlled and auditable operation that may be performed upon the customer’s written request and approval. During the rotation process, new master key parts are generated under the same quorum and dual-control policies used during the original key ceremony. Because these operations must be performed directly on the customer’s HSM domain through IBM Trusted Key Entry (TKE), the physical presence of authorized customer Custodians and domain administrators is required.

The new Master Key is first loaded in a staged state while the existing Master Key remains active. The customer then runs controlled re-wrapping or migration jobs to prepare new key blobs protected under the new Master Key. Once this process is completed and verified, the new Master Key is committed and activated.

After the customer has confirmed that production operations are functioning normally with the new Master Key, an optional controlled operation may be performed, at the customer’s request, to securely zeroize and destroy the previous Master Key under dual control. Any associated smart card data may also be physically destroyed and documented in the key-destruction log.

Backup HSM smart card sets are created during the initial Master Key ceremony. In this process, duplicate smart cards are generated for both the Domain Administrators and the Master Key Custodians, under the same quorum and dual-control conditions. If a Master Key rotation is requested, the new Master Key value is added to the backup Master Key Custodian smart cards also. Customer’s backup HSM smart cards should be kept in a secure environment such as a controlled facility.

Domain decommissioning follows a controlled and fully auditable procedure. Upon receiving the customer’s written request, a joint session is scheduled to plan the process and allow the customer to observe or participate in the secure removal activities. Before decommissioning, the customer should export any required key material using HSM APIs to ensure a trusted and encrypted transfer to the new environment. After the customer confirms readiness, the customer domain is zeroized and permanently removed from all HSM adapters, relying on the stateless design of IBM EP11 HSMs, which ensures that no customer data or operational keys reside on the hardware. Phoeniqs does not retain any copies or backups of customer key material. Once the operation is complete, formal technical proofs are issued to confirm the permanent deletion of the domain.

The customer’s Master Key, stored on TKE HSM Smart Cards, is cryptographically bound to IBM’s infrastructure and cannot be used directly in non-IBM systems or in a different IBM Trusted Key Entry (TKE) zone without a proper trust relationship being established. To migrate encrypted data or keys to a new platform, a secure key-exchange procedure must be established between the existing IBM HSM and the target system.

When migrating key material from an IBM HSM to a non-IBM HSM, the key material is first re-wrapped under a mutually trusted ephemeral transport key using IBM’s supported key-import and key-export mechanisms before transferring. IBM EP11 HSMs support leading industry-standard key-exchange algorithms, ensuring broad compatibility with enterprise HSMs and key-management systems.

If the migration target is another IBM HSM or IBM TKE environment, it may be possible to reuse the existing master key and smart cards, provided that the required trust relationship is established between the environments.

If the customer requires technical assistance for the migration, Phoeniqs can provide professional services (at additional cost) to ensure a secure and disruption-free transition. Once migration is complete and the customer confirms readiness, all customer HSM smart cards must be returned to Phoeniqs for joint zeroization and destruction under dual control. Alternatively, the customer may choose to retain its existing Master Key smart cards for an additional fee; if so, this decision will be documented in the decommissioning record.

Under the IBM TKE smart card security model, customer’s key custody and domain administration are enforced through certified, non-exportable hardware tokens and a quorum-based administrator group, ensuring that only designated Custodians with their credentials can perform dual-control, fully logged operations within the HSM domain. IBM TKE HSM smart cards function as hardware security modules (IBM Smart Card HSMs are rated overall FIPS 140-2 Level 3 (with Physical Security Level 4), EAL5+ (AVA_VAN.5) under the NL scheme, single-chip hardware module.) that are cryptographically protected; without the card owner’s credentials and PIN, their contents cannot be accessed, decrypted, or used for any key-loading or recovery activity.

All TKE operations, including key generation, loading, verification, and zeroization, require dual control and are fully recorded in the audit log. Physical possession of the cards and knowledge of authentication credentials is restricted to customer designated Custodians, while authorization within the domain is governed by a customer-assigned administrator quorum group. No administrative or cryptographic action can occur unless the required quorum of authorized administrators is present and approves it. Phoeniqs role is limited to facilitating TKE connectivity and providing procedural support during ceremonies; it does not access, retain, or override any customer smart card data, credentials, or domain authorization controls.

Once the master key ceremony is complete:

1. Smart Card Handover: All master and backup smart cards are handed over to the customer, who is responsible for their secure storage and custody.
2. Documentation: Complete logbook with all evidence is maintained for audit purposes
3. HSM Service Activation and Ready: You can now begin using the HSM service for your cryptographic operations

After the ceremony, you are responsible for:

• Generating and managing all operational keys (data encryption keys, application keys, etc.)
• Managing mTLS certificates that control access to the HSM service
• Integrating the HSM service into your applications

Phoeniqs is responsible for:

• Ensuring HSM infrastructure availability
• Hardware maintenance and updates
• Technical support for service operations

GREP11 endpoint: host:port (example: grep11.example.com:9876)

Client mTLS materials

• Client certificate: client.pem

• Client private key: client-key.pem

• CA certificate used to verify the GREP11 server: ca.pem

From the machine that will run the service:

nc -vz grep11.example.com 9876 or telnet grep11.example.com 9876

If this fails, fix routing/firewall first.

This checks TLS + client auth end-to-end:

openssl s_client \
-connect grep11.example.com:9876 \
-cert client.pem \
-key client-key.pem \
-CAfile ca.pem \
-servername grep11.example.com \
-showcerts

IBM provides a comprehensive client library and code examples to help you integrate Grep11 into your applications. The IBM Cloud hpcs-grep11-go repository contains:

• HSM Client library for connecting and interacting with Grep11 services
  • Key generation, encryption/decryption, signing/verification
  • Key wrapping and unwrapping
  • Key derivation (BIP32, SLIP10)
  • Advanced cryptographic algorithms (BLS12-381, Kyber, Dilithium, Schnorr, Edwards Curve)
  • Quantum cryptography
  • Message digest operations
  • Random data generation
• Complete documentation and setup instructions
• Support for all Enterprise PKCS #11 operations over gRPC

This repository enables developers to quickly integrate Grep11 API functionality into their applications and understand how to leverage the full capabilities of the HSM service.

• IBM Cloud – GREP11 overview (EP11 over gRPC)

• IBM Cloud – GREP11 API reference

• IBM Documentation – Testing the GREP11 server (on-prem)

• GitHub – IBM hpcs-grep11 (proto & specs)

• GitHub – IBM GREP11 Go examples

• GitHub – IBM GREP11 JavaScript examples

Back to Overview

Next: HSM-Backed KMS