Products for cryptography and secure data

We start from your requirements for assurance level, load, interfaces and operating model and match them against the series of the seven vendors. When several series fit, we name the trade-offs openly, for example assurance level against throughput. The result goes into a decision paper that you can pass on internally.

We start from your requirements. These are assurance level, load, interfaces and operating model. We match them against the series of the seven vendors. Often several series fit your case. Then we name the trade-offs openly. One example is assurance level against throughput. The result goes into a decision paper. You can pass that paper on internally.

No, we are a partner of each vendor named here and we take responsibility for selection, integration and operations. We claim no exclusivity, because the choice follows your requirement and not a framework contract. Procurement and licenses we clarify together with the vendor and your purchasing department.

No, we are not a distributor. We are a partner of each vendor named here. We take responsibility for selection, integration and operations. We claim no exclusivity. The choice follows your requirement. It does not follow a framework contract. We clarify procurement and licenses together. The vendor and your purchasing department take part.

Today the section holds one category, hardware security modules, with seven vendor pages from Utimaco to IDEMIA. Further categories for key management, signing and data encryption follow as soon as the research proves every series. If a product you are evaluating is missing, tell us about it.

Today the section holds one category. It is called hardware security modules. It has seven vendor pages from Utimaco to IDEMIA. More categories will follow. Planned are key management, signing and data encryption. We publish them once the research proves every series. If a product is missing, tell us about it.

You decide that. You can run the devices yourself, hand operations over to us or use the vendor offering as a service. One team accompanies you from consulting to operations, so contacts and documentation stay the same after the project.

You decide that. You can run the devices yourself. You can hand operations over to us. You can also use the vendor offering as a service. One team accompanies you from consulting to operations. Contacts and documentation stay the same after the project.

The section brings together products that generate keys, protect them and make them usable for applications. We are a partner of each vendor and not a distributor, so we compare the series against your requirements for assurance level, load and operations. Every figure on a vendor page comes from the official product documentation. Cryptography and hardware security modules are our core competence. We know the certification schemes, the interfaces and the limits of each product line, and we tell you where a device runs out of throughput. From that knowledge comes a selection your auditors can follow.

We compare the series of several vendors against your requirements and name the trade-offs instead of promoting one product line.

One team accompanies you from consulting to operations. The same people connect your applications and later watch the devices in production.

Cryptography and hardware security modules are our core competence. We know firmware, key ceremonies and migration paths, not only the data sheet.

The entire solution runs in German data centers. We settle location, access and documentation with your audit department up front.

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.

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.

These four examples show possible HSM uses. The evidence you need depends on your application. A validated device does not automatically make the whole environment secure.

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.

A certificate authority issues certificates. Its private keys can be held in an HSM. The software still needs protection. Someone who controls it might otherwise request unauthorized signatures.

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.

A payment HSM is designed for payment tasks, such as PIN processing. We check the required functions and partner requirements. Not every HSM can perform these tasks.

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.

A digital signature helps check software and its publisher. An HSM can protect the signing key. You must also decide who may approve each software release for signing.

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.

A central system can manage keys for applications and storage. An HSM can protect important keys within this system. We check who may use each key. Bringing your own key to the cloud does not automatically prevent the provider from reading data.