New cryptography. Old dependencies.

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.

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

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.

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

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

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?

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.

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.

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.

Product support is documented per version and operation. Issuance and verification are tested as a complete chain. Distribution of trust and the transition of existing certificates are planned.

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.

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.

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.

Crypto inventory and protection needs IT, information security, application owners, OTOKO® cryptography specialist CBOM, protection needs and data lifetime per system, gap analysis against BSI TR-02102

Roadmap, target algorithms, transition phases Architecture, information security, PKI operations, procurement Migration roadmap, cryptography policy, target design for PKI and HSM, operating model