The fundamentals of the Managed KMS offering
The service Managed KMS (Key Management Service) is a fully managed cryptographic key lifecycle management platform deployed on Cloud Temple's sovereign SecNumCloud infrastructure. Based on Cosmian KMS - French open-source reference solution - and anchored in a Thales Luna HSM hardware root of trust (FIPS 140-3 Level 3), this service offers the highest level of protection for your cryptographic keys.
Managed KMS addresses the fundamental challenge of data sovereignty: encryption is necessary, but the security of encryption depends entirely on key protection. This service ensures that your master keys never leave the HSM in the clear, that their lifecycle is audited, and that access is governed by granular policies - all on a SecNumCloud-qualified French 100% infrastructure.
Compatible with industry standards (KMIP 2.1, PKCS#11, REST API), it integrates natively with the entire Temple and third-party Cloud application ecosystem, with no proprietary lock-in.
Our compliance procedures
Our Managed KMS offering is HDS and ISO 27 001 certified
The benefits of Cloud Temple's Managed KMS offering
Total sovereignty
Dual technological and geographical control
Guarantee that your keys and data remain under French control, with Cosmian KMS and Cloud Temple (SecNumCloud), without dependence on foreign suppliers.
Enhanced physical security
Root of inviolable trust
Protect master keys in a FIPS 140-3 Level 3 certified HSM, ensuring that cryptographic material never leaves the HSM in the clear, even for administrators.
Interoperability and flexibility
Open standards and various key models
Support KMIP 2.1 for easy integration with your applications and enable BYOK, HYOK or internal generation, depending on your control and governance needs.
Simplified operation
Zero Ops with Cloud Temple integration
Benefit from fully managed deployment, HA, updates and monitoring, with native integration to Object Storage, Managed Kubernetes, Managed SIEM and Isolated Private Network.
Key features of our Managed KMS
Key lifecycle management
Secure key creation, activation, deactivation, revocation and destruction according to the KMIP 2.1 standard. Status: Pre-Active → Active → Deactivated → Compromised → Destroyed.
HSM root of trust (Thales Luna)
Master KEKs (Key Encryption Keys) are generated and stored in the Thales Luna HSM (FIPS 140-3 Level 3). Application keys are “wrapped” by the HSM KEK.
Supported key types
AES-128/192/256, RSA-2048/3072/4096, EC (P-256, P-384, P-521), Ed25519, Ed448, X25519, ChaCha20.
Cryptographic operations
Encryption/decryption (AES-GCM, AES-CBC, RSA-OAEP, ECIES), signature/verification (ECDSA, EdDSA, RSA-PSS), wrapping/unwrapping (Key Wrapping RFC 3394).
API REST & KMIP 2.1
Native JSON REST interface + support for the KMIP 2.1 protocol (OASIS standard) for interoperability with KMIP-compatible applications.
PKCS#11 Interface
PKCS#11 interface for applications using this industry standard (software HSM, OpenSSL integrations, Java JCA/JCE).
BYOK (Bring Your Own Key)
Import of external key material into the KMS with wrapping by KEK HSM. Full control of key origin.
HYOK (Hold Your Own Key)
The keys remain under the exclusive control of the customer (in their own HSM or perimeter); the KMS only acts as a proxy for cryptographic operations.
Automatic key rotation
Key-configurable rotation policies (lifetime, fixed-date rotation). Transparent rekeying without application interruption.
Access control (ABAC)
Attribute-Based Access Control: granular policies by client, application, operation and perimeter.
Strong authentication
OIDC/JWT (integration with existing identity providers) and client TLS certificate authentication (mTLS).
Unchanging audit trail
Logging of all cryptographic operations (who, what, when, on which key) with signed timestamps. Export to centralised log sinks.
Technical specifications
Do you have a sovereign encryption or cryptographic compliance project? Let's talk.
Do you want to centralise the governance of your keys (BYOK/HYOK), protect your Kubernetes secrets (etcd) or comply with strict regulatory requirements (LPM, NIS2, DORA, PCI-DSS) with a tamper-proof hardware root of trust? Our security architects can help you scale your Cosmian KMS cluster and your Thales Luna HSM infrastructure on our SecNumCloud-qualified cloud.
Tell us what's at stake in your project using this form: we'll get back to you quickly to design the cryptographic foundation that's right for your applications.
Use cases
No, the separation of responsibilities is strict.
The architecture ensures that Cloud Temple only has access to the control plane (the infrastructure). The cryptographic material of your master keys (KEK) never leaves the Thales Luna HSM unencrypted, even for our administrators or during backups. Your application keys (DEK) are “wrapped” (encrypted) by the HSM. You retain exclusive control over the data plan.
No, the network is totally isolated.
The endpoints of the REST API, the KMIP 2.1 protocol and the PKCS#11 interface are accessible exclusively from your Cloud Temple private network. No public exposure is possible, which drastically reduces the attack surface.
The hardware root of trust and the SLA.
In a production environment (multi-AZ), the service is based on a true hardware root of trust: a dedicated Thales Luna Network HSM certified to FIPS 140-3 Level 3, with an SLA of 99.90%. In a Dev/Test environment (mono-AZ), to optimise costs, the cryptographic backend is based on a software HSM (SoftHSM2) or shared access, and is not subject to any availability commitment (SLA).
The destruction of a key is definitive and irreversible.
To avoid any industrial tragedy, a destruction operation requires a “double approval” process. This is crucial because if you destroy a master key (KEK) in the HSM, all the data encrypted by the application keys (DEK) protected by this KEK will become permanently inaccessible.
Yes, “Hold Your Own Key” mode is supported.
Managed KMS allows you to leave your keys under your exclusive control, for example in your own HSM hosted on-premises. In this case, the Cloud Temple KMS acts only as a proxy for cryptographic operations. Please note, however, that this mode requires your HSM to be accessible from the Cloud Temple network (via IPsec VPN or dedicated interconnection).
Continuous reversibility, without proprietary locking.
Because the service is based on the KMIP 2.1 (OASIS) open standard, your keys remain your property and can be exported at any time, in self-service, in KMIP/JSON format. You can then re-import them into any other compatible KMS on the market. On termination, we carry out a secure cryptographic destruction (zero-fill HSM and database) within 7 days, and issue a certificate of destruction.