Key Management

The Key Management surface in the Mesh Dashboard is where a tenant configures the backends that hold key encryption keys, manages the lifecycle of those keys, and performs rotations. The underlying concepts — DEKs, KEKs, and the Key Access Service — are covered in Core Concepts → Hierarchical Key Model.

Supported backends

A tenant selects a key management backend during onboarding and can add additional backends later if needed (for example, to support a new region or regulatory jurisdiction). The platform integrates with:

• AWS KMS
• Google Cloud KMS
• Azure Key Vault
• HashiCorp Vault Transit engine

Organizations running their own hardware security modules connect them through the same integration layer — the Key Access Service treats a customer HSM as just another backend.

The KEK itself never leaves the configured backend. Wrapping and unwrapping of DEKs happens on the Key Access Service, which delegates the cryptographic operation to the backend. The platform never sees or stores cleartext KEK material.

The key inventory

The Key Management page shows every key the tenant currently has provisioned, grouped by:

• Scope — tenant-level, policy-level, epoch-level.
• Algorithm — classical (RSA, ECC), post-quantum (ML-KEM-based), or hybrid.
• Lifecycle state — active, deprecated, or retired.
• Rotation cadence — the configured schedule, if any.
• Creation and next-rotation dates.

Each entry links to a detail view showing the key's provenance (which backend holds it), the operations performed under it, and any anchored events on the ledger.

Rotation

Rotation happens through the Key Management surface. A rotation operation:

1. Generates a successor key in the configured backend.
2. Moves the current key from active to deprecated.
3. Begins wrapping new DEKs under the successor.
4. Maintains the deprecated key as usable for unwrapping existing objects until the end of the configured overlap window.
5. Retires the deprecated key at the end of the overlap window.

Administrators can configure rotations as scheduled (quarterly, annually) or triggered (manually, or automatically on a policy event). The rotation status of every key is visible in the inventory — how many objects are still wrapped under a deprecated KEK, how close a retirement date is, whether any objects would become inaccessible at retirement.

Post-quantum profiles

A tenant can define an encryption profile that binds a classification to a set of required algorithms. For example:

• Objects classified as Restricted must be wrapped under a post-quantum KEM.
• Objects classified as Confidential may be wrapped under hybrid classical/PQ.
• Objects classified as Internal may remain under classical wrapping during the transition.

Profiles are enforced at wrap time by the Mesh Node — an attempt to wrap a Restricted object under a classical-only key is rejected.

Profile configuration is covered in detail under Configuration → Encryption Profiles.

Emergency revocation

For compromise scenarios, the Key Management surface supports an emergency revocation of a KEK. When invoked:

• The KEK is immediately moved to retired.
• All cached DEK releases derived from the retired KEK are invalidated across the fabric.
• Every subsequent unwrap attempt for an object wrapped under the retired KEK is denied and logged.

Emergency revocation is an irreversible operation. Use it when a compromise is known or strongly suspected. The intended post-revocation flow is to generate a new KEK, re-wrap the affected objects (through a re-wrap job that the Mesh Node can perform in bulk), and resume normal operations.

Relationship to concepts

• The Key Management surface operates on the hierarchical key model.
• Encryption profiles enforce the tenant's post-quantum transition strategy.
• Every key lifecycle event is recorded on the Immutable Ledger.