Core Concepts

Cryptographic Agility

How Lattix helps administrators manage cryptographic transition for protected data over time — tenant profiles, key lifecycles, observable migration events, and rewrap campaigns.

Long-lived sensitive data outlasts any single cryptographic standard. Lattix is designed so protected data can continue to move across systems, clouds, edge nodes, and partner environments while its cryptographic protections evolve over time.

Rather than treating cryptographic change as a one-time cutover, Lattix manages it through tenant-controlled profiles, key lifecycles, and observable migration events. Administrators can strengthen protection for new and existing data without changing the object-centric security model.

How it works

Lattix separates payload protection from key protection and policy metadata.

  • The payload remains encrypted as a protected object.
  • Access to that object is governed through wrapped key material, policy-bound metadata, and signed control artifacts.
  • As cryptographic requirements change, administrators can introduce new profiles, rotate keys, rewrap protected objects, and retire older key material without redesigning how data is distributed or enforced.

This makes cryptographic transition operationally manageable for long-lived data, archives, and high-assurance environments.

Protected object migration

Protected object migration between cryptographic profiles. A single protected object keeps its ciphertext and DEK unchanged while its wrapped key material and crypto profile are rebound from Profile A to Profile B under administrator control./ PROTECTED OBJECT MIGRATIONPROFILE Acurrent cryptographic posture◆ PAYLOAD CIPHERTEXTsymmetric AEAD · unchanged across migration◆ DEKper-object content key · unchanged◆ WRAPPED KEY MATERIALunder Profile A key material◆ CRYPTO PROFILE METADATAprofile A · epoch referenceREWRAPadmin-initiated · auditablePROFILE Bnew cryptographic posture◆ PAYLOAD CIPHERTEXTsame bits · not re-encrypted◆ DEKsame content key◆ WRAPPED KEY MATERIALrebound under Profile B key material◆ CRYPTO PROFILE METADATAprofile B · new epoch referencePAYLOAD UNCHANGED · DEK UNCHANGED · ONLY THE WRAP & PROFILE LAYERS MOVE

Only the wrap and profile layers migrate. The payload stays where it is and is not re-encrypted. That is what makes migration across archives and long-lived protected data operationally feasible.

What administrators control

Administrators define cryptographic profiles at the tenant level and apply them to different classes of data and workloads.

A profile can specify:

  • which cryptographic algorithms are allowed
  • which profile is the default
  • which profile is the minimum permitted
  • when older key material becomes deprecated
  • when new key epochs begin
  • when rewrap campaigns should run
  • whether downgrade to weaker profiles is allowed

This lets different data classes move at different speeds while preserving a consistent security model. Short-lived workflows can stay on a simpler profile; long-lived or highly sensitive data can be required to sit on a stronger one; a migration window can run between them without fracturing the model.

What administrators can see

Every major cryptographic lifecycle event is observable and trackable. Visibility is a first-class property of the system, not a post-hoc audit function.

Cryptographic lifecycle with administrator visibility. A horizontal lifecycle runs from Generate to Active to Deprecated to Retired, and underneath each phase is a list of the specific events administrators can observe: epoch created, profile changed, rewrap started, rewrap in progress, rewrap completed, downgrade blocked, and related key and signature events./ CRYPTOGRAPHIC LIFECYCLE · OBSERVABLE EVENTSGENERATEprofile authored · key createdACTIVEnew wrappings use this profileDEPRECATEDunwrap only · no new wrapsRETIREDno longer usedOBSERVABLE ADMINISTRATOR EVENTSevery event below writes a signed record to the immutable ledgerKEYS & EPOCHS◦ key generation◦ key activation◦ key deprecation◦ key retirement◦ new epoch created◦ signature profile changeMIGRATION◦ profile change◦ rewrap campaign started◦ rewrap in progress◦ rewrap completed◦ overlap window opened / closed◦ key-policy changeACCESS & GUARDRAILS◦ unwrap under active profile◦ unwrap under deprecated profile◦ downgrade attempt blocked◦ signature verification failure◦ expired-epoch access refused◦ profile-violation denialEVIDENCE IS CONTINUOUSAdministrators can track cryptographic transition as an operational activity rather than reconstructing it from scattered logs.

Every event shown above writes a signed record to the Immutable Ledger. A rewrap campaign is observable as it runs; a blocked downgrade attempt is visible and attributable; a deprecated epoch's residual use is quantifiable. Cryptographic transition becomes an operational activity that administrators can track in real time, not an archaeology exercise after the fact.

Post-Quantum Cryptography

Lattix supports post-quantum cryptography as part of its broader cryptographic-agility model.

This matters for long-lived sensitive data exposed to the harvest-now-decrypt-later risk: data captured today may remain valuable when future adversaries have stronger cryptanalytic capabilities. Administrators can apply stronger cryptographic profiles to the key-protection and signing layers around protected data while preserving the same object-centric operating model.

Why this matters

A major advantage of the protected-object model is that cryptographic improvements can be applied through managed key rotation, key epochs, and rewrap workflows rather than requiring wholesale redistribution of data. That makes large-scale migration feasible for the data most likely to remain sensitive over long periods.

Supported cryptographic profiles

Supported cryptographic profiles may include standardized classical, hybrid, and post-quantum algorithms — including ML-KEM for post-quantum key encapsulation and key protection, and ML-DSA for post-quantum digital signatures — based on tenant configuration and deployment profile.

Profiles can combine:

  • Classical algorithms where required for compatibility during transition periods.
  • Post-quantum algorithms (ML-KEM, ML-DSA) for key encapsulation, key protection, and signatures.
  • Hybrid profiles for staged migration where policy requires both classical and post-quantum protection until cutover.

Payload confidentiality remains anchored in symmetric encryption. Post-quantum transition primarily affects the asymmetric layers used for key protection, key encapsulation, and signatures. Specific supported algorithms track the standards published by the relevant standards bodies and may evolve over time through the same profile, epoch, and rewrap controls described above.

Relationship to the rest of the platform

Cryptographic agility works through the same Lattix building blocks already used elsewhere:

  • The Hierarchical Key Model provides the structure for key material, epochs, and rotation.
  • The Trusted Data Format protected object carries the crypto profile metadata that binds cryptographic requirements to the data.
  • The Key Access Service enforces governed access to wrapped key material under the active profile.
  • Policies and ABAC express tenant- and data-specific profile requirements as part of object governance.
  • The Immutable Ledger records every cryptographic lifecycle event listed above.
  • Cross-fabric trust preserves source-origin cryptographic requirements as protected data moves between trusted organizations.