---
title: Encryption Profiles | Docs | Lattix
description: KMS backend selection, algorithm policy per classification, rotation cadence, and post-quantum transition controls.
source: "https://lattix.io/docs/configuration/encryption-profiles/"
content-type: text/markdown
---

# Encryption Profiles | Docs | Lattix

Configuration

# Encryption Profiles

KMS backend selection, algorithm policy per classification, rotation cadence, and post-quantum transition controls.

An encryption profile binds a classification to the algorithms, key sources, and lifecycle requirements that apply to objects carrying that classification. The profile is the mechanism by which "all Restricted data must be wrapped under a post-quantum KEM held in our HSM" becomes an enforced rule rather than a documented aspiration.

## What a profile defines

- **Target classification(s).** The tag values that trigger this profile. A profile can apply to a specific tag value, a combination, or (as a fallback) to everything the other profiles don't cover.
- **Key management backend.** Which configured backend (AWS KMS, Google Cloud KMS, Azure Key Vault, Vault Transit, or HSM) holds the KEK used by this profile.
- **KEK algorithm.** Classical (RSA, ECC), post-quantum (ML-KEM-based), or hybrid.
- **DEK algorithm.** The authenticated encryption primitive used for the payload, typically AES-256-GCM.
- **Rotation cadence.** The schedule on which the KEK is rotated (quarterly, annually, event-triggered).
- **Overlap window.** How long a deprecated KEK remains valid for unwrapping existing objects before it's retired.
- **Region and residency.** If the tenant is configured with region-scoped key access, which regions this profile is valid in.

## Recommended profiles for a new tenant

A sensible default set:

**Profile: Public**

- Applies to: `sensitivity=public`
- Algorithm: classical (AES-256-GCM + RSA-OAEP or equivalent)
- Rotation: annually

**Profile: Internal**

- Applies to: `sensitivity=internal`
- Algorithm: classical
- Rotation: quarterly
- Overlap: 30 days

**Profile: Confidential**

- Applies to: `sensitivity=confidential`
- Algorithm: hybrid classical + post-quantum
- Rotation: quarterly
- Overlap: 14 days

**Profile: Restricted**

- Applies to: `sensitivity=restricted`
- Algorithm: post-quantum (ML-KEM-based)
- Backend: dedicated HSM or segregated cloud KMS key
- Rotation: monthly
- Overlap: 7 days

Tighten or loosen based on your regulatory posture and operational tempo. Organizations with active harvest-now-decrypt-later threat models accelerate the post-quantum migration; organizations with minimal long-horizon data exposure can maintain hybrid or classical operation longer.

## Transition patterns

A common transition pattern:

1. Start with classical wrapping and post-quantum support disabled.
2. Enable post-quantum primitives in hybrid mode for the highest classification tier. Monitor for operational issues.
3. Gradually lower the classification threshold for hybrid.
4. After a validation period, switch the highest tier from hybrid to post-quantum-only.
5. Lower the threshold for post-quantum-only over subsequent cycles.

The re-wrap flow described under [Key Management](https://lattix.io/docs/products/key-management/) handles the migration of existing objects. The envelope doesn't change, just its outer wrapping. Consumers on the new stack unwrap transparently.

## Backend selection considerations

**Latency.** Every unwrap makes a call into the configured backend. If the backend is geographically distant from the consuming workloads, latency will be meaningful. Region-scoped backends are available for this reason.

**Residency.** If a classification has jurisdictional residency requirements (EU data staying in EU, etc.), the backend must be region-scoped and the profile must reject unwrap requests from out-of-region principals.

**Separation.** For high-sensitivity data, using a backend distinct from less-sensitive classifications (a dedicated HSM for Restricted, a shared cloud KMS key for Internal) is a reasonable blast-radius reduction. The platform supports arbitrary numbers of backends per tenant.

**Cost.** Cloud KMS operations have per-request costs. Batch operations and caching reduce costs; high-volume, high-sensitivity workloads may warrant the fixed cost of a dedicated HSM.

## Emergency operations

Two emergency operations are available per profile:

**Freeze.** Temporarily suspend all new wrapping under this profile. Existing objects continue to unwrap normally. Useful during investigation of a suspected algorithm or backend issue.

**Rotate-all.** Immediately rotate the KEK for this profile, starting the overlap window. Useful for suspected KEK compromise or as a scheduled hardening exercise.

Both are ledger-recorded and trigger notifications to the security administrator pool.

## Relationship to products and concepts

- Profiles are configured against the [Key Management](https://lattix.io/docs/products/key-management/) product.
- They realize the platform's approach to [cryptographic agility](https://lattix.io/docs/concepts/cryptographic-agility/).
- They are enforced at wrap time by the [Mesh Node](https://lattix.io/docs/products/mesh-node/) and at unwrap time by the Key Access Service in the [hierarchical key model](https://lattix.io/docs/concepts/hierarchical-key-model/).

[Policy Workflow Staging, review, and publication rules for policy changes.](https://lattix.io/docs/configuration/policy-workflow/) [Connectors Per-integration configuration: authorization, discovery scope, classification behavior, egress rules.](https://lattix.io/docs/configuration/connectors/)