Note: Cosmian has become part of Eviden. The Cosmian KMS is now the Eviden KMS.
The Cosmian KMS is a high-performance, source-available FIPS 140-3 compliant server application written in Rust.
Online documentation.

Built-in Web UI for administration and operations.
The Cosmian KMS presents some unique features, such as:
The Cosmian KMS is both a Key Management System and a Public Key Infrastructure. As a KMS, it is designed to manage the lifecycle of keys and provide scalable cryptographic services such as on-the-fly key generation, encryption, and decryption operations.
The Cosmian KMS supports all the standard NIST cryptographic algorithms as well as advanced post-quantum cryptography algorithms such as Covercrypt, and FF1 format-preserving encryption in non-FIPS mode. Please refer to the list of supported algorithms.
As a PKI it can manage root and intermediate certificates, sign and verify certificates, use their public keys to encrypt and decrypt data. Certificates can be exported under various formats, including PKCS#12 modern and legacy flavor, to be used in various applications, such as in S/MIME encrypted emails.
The Cosmian KMS has extensive online documentation.
Pre-built binaries are available for Linux, MacOS, and Windows, as well as Docker images. To run the server binary, OpenSSL must be available in your path (see "building the KMS" below for details); other binaries do not have this requirement.
Using Docker to quick-start a Cosmian KMS server on http://localhost:9998 that stores its data inside the container, run the following command:
docker run -p 9998:9998 --name kms ghcr.io/cosmian/kms:latest
Then, use the CLI to issue commands to the KMS. The CLI, called cosmian, can be either:
cargo install ckmsbuilt and launched from the GitHub project by running
sh
cargo build --bin ckms
Create a 256-bit symmetric key
```sh ➜ ckms sym keys create --number-of-bits 256 --algorithm aes --tag my-key-file ... The symmetric key was successfully generated. Unique identifier: 87e9e2a8-4538-4701-aa8c-e3af94e44a9e
Tags: - my-key-file ```
Encrypt the image.png file with AES GCM using the key
sh
➜ ckms sym encrypt --tag my-key-file --output-file image.enc image.png
...
The encrypted file is available at "image.enc"
Decrypt the image.enc file using the key
sh
➜ ckms sym decrypt --tag my-key-file --output-file image2.png image.enc
...
The decrypted file is available at "image2.png"
See the documentation for more.
--features non-fips for extended algorithms.ckms):sbom/server/fips/static/bom.cdx.jsonsbom/server/fips/static/bom.spdx.jsonsbom/server/fips/static/vulns.csvsbom/ckms/fips/static/bom.cdx.jsonsbom/README.mdcbom/cbom.cdx.json — generated by .mise/scripts/sbom/generate_cbom.pyObservability built-in with OpenTelemetry metrics/traces. See OTLP_METRICS.md.
[TOC]
| HSM | Status |
|---|---|
| Proteccio (Bull Atos) | ✅ |
| Crypt2pay | ✅ |
| Utimaco SecurityServer | ✅ |
| CardContact SmartCard-HSM / Nitrokey HSM 2 | ✅ |
| SoftHSM2 (testing) | ✅ |
| AWS CloudHSM | 🚧 |
| Azure Dedicated HSM | 🚧 |
| GCP Cloud HSM | 🚧 |
Legend: ✅ implemented · 🚧 not yet implemented
Cloud providers offer mechanisms that let you hold cryptographic keys outside their infrastructure. There are three distinct delegation models:
| Term | Meaning |
|---|---|
| XKS | AWS External Key Store — every encrypt/decrypt is proxied live to your KMS; the key material never enters AWS. |
| EKM | GCP External Key Manager — same live-proxy model; Google never holds the key material. |
| DKE | Microsoft Double Key Encryption — one key lives in Azure/M365, the second key lives exclusively in your KMS; both are required to decrypt. |
| HYOK | Hold Your Own Key (Oracle) — OCI Vault External KMS; every encrypt/decrypt is proxied live to your KMS; the key material never enters OCI. |
| BYOK | Bring Your Own Key — you generate key material and import it into the provider's KMS; the provider then holds a copy. |
| CMK | Customer-Managed Key — the provider generates and stores the key in their KMS, but you control lifecycle (rotate, disable, delete). |
AWS XKS is a single proxy API that AWS KMS calls on behalf of every service — S3, EBS, RDS, DynamoDB, Secrets Manager, etc. all route through the same endpoint. Implementing the XKS Proxy API once gives Cosmian KMS live-proxy coverage for all XKS-capable AWS services with no per-service work.
| Delegation model | Description | Status |
|---|---|---|
| XKS (live proxy) | Key material never enters AWS; every encrypt/decrypt is proxied to Cosmian KMS — covers all AWS services that support KMS encryption (S3, EBS, RDS, DynamoDB, Secrets Manager, SQS, SNS, Redshift, OpenSearch, EMR, Glue, Lambda…) — docs | ✅ |
| BYOK | Key material generated by you and imported once into AWS KMS; AWS holds a copy |