PQC for PKI & HSM

New cryptography. Old dependencies.

Long-lived certificates and signature keys need a particularly well-coordinated transition. We review your certificate hierarchies and HSM connections, develop a suitable target architecture and test new algorithms with the applications that actually verify them.

What we take care of Discuss your project

PKI and HSM migration architecture · Planning and implementation by OTOKO®

Your brief for OTOKO®

What we take care of for you.

An HSM can support an algorithm while the CA, the provider or the eventual verifier does not yet support it. We record the entire chain, including certificate profiles, trust stores, status services and signature formats. Long lifecycles of devices and documents affect the transition. A parallel hierarchy can make sense, but it needs a clear mapping: which application trusts which chain, and how are old and new artifacts distinguished?

The possible scope of services

Record certificate hierarchies, keys and verifying applications
Assess support in the specific PKI and HSM configuration
Plan parallel or supported hybrid transition models
Prepare key ceremonies and trust distribution
Test certificate validation, revocation and signature workflows

We define the specific scope, your involvement and the acceptance criteria before the start.

Technology explained clearly

How we carry out the task.

Distinguish product support from evidence

We review vendor documentation for hardware, firmware, licenses and operating mode. An available algorithm does not automatically mean it may be used within the required validation or approval. Backup, replication and key migration must also support the new type. For new trust anchors, we plan roles, access credentials and ceremonies. Stateful signature schemes additionally require particularly careful state management; they are not introduced unchecked just because a product option exists.

Distribute trust in a controlled way

Acceptance covers issuing and validating representative certificates as well as error cases, revocation information and the behavior of older clients. The order of trust distribution is defined before the cutover. Long-term signature verification and archiving requirements are coordinated with the responsible parties. The result is a documented, tested configuration with stated limitations.

Meeting room at the OTOKO® Cologne office

A verifiable result

What you keep working with.

PKI and HSM migration architecture
Compatibility matrix
Pilot with ceremony and test documentation

The handover brings together implementation and documentation. Together, we review the agreed cases and record any remaining tasks.

Your project in detail

Migrate PKI and HSM as one connected chain of trust.

We plan PQC projects based on actual product and application support. A new algorithm in the HSM is not enough if the CA, certificate format, library or verifying application cannot handle it.

Prove support per version and use

We create a compatibility matrix for the HSM, firmware, client, PKI and consuming systems. Support for key generation does not yet show that all required signature, import or backup operations are supported. Statements are therefore tied to specific versions and operations.

Approvals and certifications are considered separately. A technical PQC capability does not automatically result in approval for a specific regulated use. Required evidence and vendor commitments are tracked as prerequisites in the project plan.

Roll out new chains of trust in a controlled way

Before a switch, we review certificate profiles, size, transport and storage, as well as the distribution of trust anchors. Applications with limited libraries or fixed certificate assumptions may need further adjustments. The pilot therefore includes at least one complete issuance and one successful verification by a real consumer.

For the transition, we plan the remaining lifetime of existing certificates, revocation and possible parallel states. Key material cannot simply be converted to a new algorithm; new keys and certificates are often required. A fallback path must also account for objects already issued and their dependencies.

Illustrative project scenario

How the service helps in everyday use.

Example: An internal PKI is to be prepared for a future switch. We select a well-defined test service, check the CA and HSM with the intended versions and test certificate verification on the client. Unsupported systems remain visible as concrete migration dependencies.

This example explains a possible process and is not a customer reference.

Before the first step

Your questions about PQC for PKI & HSM.

Does every HSM need to be replaced?

This can only be decided based on the model, firmware, operating mode and required algorithm. Expansion, parallel operation and replacement are weighed against each other.

Are parallel certificate chains the same as hybrid signatures?

No. Parallel chains and cryptographically combined algorithms are different transition models. Which variant works depends on the products and verifiers involved.

Your project

Which task would you like to solve?

Describe your situation and the desired result. The selected service will be included in the contact request.

Request this service

Navigation

New cryptography. Old dependencies.