– Encryption

KMS now supports asymmetric encryption and digital signatures

Wed, 07 Oct 2026 05:00:00 +0000

Exoscale Key Management Service (KMS) now supports asymmetric keys for encryption and digital signatures. They’re available through the API, CLI, Portal and SDKs.

What’s new

RSA encryption: Create RSA-3072 or RSA-4096 key pairs and export the public key to whoever needs to send you data. They can encrypt without a KMS account, and decryption happens only inside KMS, with the private key never leaving it.
Digital signatures: Sign data with RSA-PSS, ECDSA, Ed25519 or ML-DSA keys. Signing always happens in KMS. You can verify signatures in KMS as well, or export the public key and verify with your own tools, offline if needed.
Post-quantum signatures: ML-DSA-65 and ML-DSA-87 implement FIPS 204, the Module-Lattice-Based Digital Signature standard NIST published in 2024. Unlike RSA and ECDSA, ML-DSA is designed to resist forgery by future quantum computers. That makes it a fit for signatures that must remain verifiable for many years. ML-DSA-65 targets NIST security category 3, and ML-DSA-87 targets category 5.

These additions let you use KMS for application encryption, signing workflows, and integrations that require public-key cryptography, without exposing private key material.

See how to sign and verify data with KMS →

Encryption at Rest for Compute and Block Storage

Tue, 02 Jun 2026 15:30:00 +0000

Exoscale now transparently encrypts stored data for Compute and Block Storage workloads using AES-256 in XTS mode at the hypervisor layer. Combined with existing TLS-based encryption in transit, Exoscale now provides encryption by default for data at rest and in transit across the platform.

What’s new:

Encryption at rest by default — all newly created Compute instances and Block Storage volumes are encrypted automatically.
Unique encryption keys — each volume receives a unique encryption key managed by Exoscale.
Encrypted snapshots — snapshots inherit the encryption of their parent volume.
Protected templates and instance snapshots — instance snapshots and templates stored on Object Storage remain protected through bucket-level encryption.

What this means in practice:

New workloads benefit from encryption everywhere by default across compute, storage, snapshots, templates, APIs, and network communication.
Encryption happens automatically at the platform layer, without requiring changes to applications, operating systems, or operational workflows.
Stored and transmitted data now follow a more consistent end-to-end protection model across Exoscale services.

Existing Compute instances remain unencrypted for the time being. In the near future, we will clearly communicate how to encrypt unencrypted instances.

Existing Block Storage volumes are not re-encrypted in place. To encrypt existing Block Storage data, create a new encrypted volume and copy the data across.

Explore how Encryption at Rest works on Exoscale.

SOS: Block SSE-C Encryption per Bucket

Fri, 29 May 2026 15:30:00 +0000

You can now block specific server-side encryption types on your SOS buckets, starting with SSE-C (Server-Side Encryption with Customer-Provided Keys).

When SSE-C is blocked on a bucket, any upload request that includes a customer-provided encryption key is rejected. This gives bucket owners a way to enforce their encryption policy at the bucket level, for example to ensure all objects use SSE-SOS so that data remains readable through replication and other server-side features that are incompatible with SSE-C.

Starting in 30 days, all newly created SOS buckets will have SSE-C blocked by default. Existing SSE-C encrypted objects will still remain accessible for retrieval. If you want to re-encrypt them, you will have to upload them again with the new settings configured. It is always possible to block or unblock SSE-C by updating your bucket’s SSE configuration.

For configuration details, refer to the SOS documentation.