SOVEX
CBDC Data Centers Sovereign AI Tokenization Deep Tech Architecture About Team Request access
Data Centers / Quantum-ready / Crypto-agility

Crypto-agility.

Standards move, and so does the cryptography defending sovereign money — in place, without re-issuing currency or rebuilding the ledger. Algorithms are configuration under governance, not concrete poured into the settlement path.

Cryptography is a replaceable component, not a permanent assumption baked into the system

Agility begins with an architectural rule: no service names a specific algorithm in its business logic, so any primitive can be swapped without touching the logic above it.

01

Algorithm as configuration

Signing and key-establishment schemes are selected through a governed policy layer rather than hard-coded into applications. Changing the primitive is a controlled configuration action, not a code rewrite.

02

Abstraction boundary

Services call cryptographic operations through a stable internal interface that hides the underlying scheme. The ledger and settlement code never depend on the specific algorithm in force.

03

No flag-day migrations

Upgrades are designed to happen while the system runs. There is no scheduled outage where the whole estate stops to change ciphers at once.

04

Standards as the driver

The trigger for change is an evolving external standard, not a vendor release. When a body like NIST advances a parameter set, the architecture is built to follow it deliberately.

Peers agree on the strongest cryptography they both support, and record what they chose

Every session and signature carries an explicit identifier of the scheme in use, so two endpoints can negotiate and later prove exactly what protected an exchange.

01

Explicit algorithm identifiers

Each signed record and session tags the primitive and parameter set that produced it. Nothing relies on an implicit, system-wide default that reviewers must reconstruct.

02

Negotiated cipher selection

Endpoints select from a policy-approved list and settle on the strongest mutually supported option. The list is governed centrally, so weak choices can be removed everywhere at once.

03

Downgrade resistance

Negotiation is authenticated so an attacker cannot force a fallback to a weaker scheme. The agreed suite is bound into the session and cannot be silently renegotiated down.

04

Versioned formats

Ledger and message formats carry version fields that anticipate new algorithms. A future primitive slots into an existing envelope rather than requiring a new one.

Keys rotate, retire, and get re-issued on a schedule the owner controls

Agility depends on being able to move keys as fluidly as algorithms, so lifecycle management is a governed, auditable process rather than an emergency procedure.

01

Scheduled rotation

Signing and encryption keys are rotated on defined intervals with overlap windows so no operation is stranded mid-transition. Rotation is routine, which means it is well-tested when it matters.

02

Owner-governed policy

The state or institution sets rotation cadence, quorum rules, and revocation authority. The operator executes within those bounds and cannot override them.

03

Graceful retirement

A retiring key stops signing new records while remaining available to verify old ones. History stays provable even as the active key set moves forward.

04

Emergency revocation path

A compromised or deprecated key can be revoked and replaced through a defined quorum process. The path is rehearsed as part of routine operation, not improvised under pressure.

Two cryptographic generations run side by side until the old one can be safely retired

Because sovereign systems cannot stop, migration is a period of deliberate coexistence rather than a single cutover.

01

Dual-stack operation

During transition, the system can produce and verify under both the outgoing and incoming schemes. New records adopt the new primitive while old records stay verifiable under the old.

02

Hybrid as default posture

Combining a post-quantum scheme with a classical one is treated as a stable operating mode, not just a transient step. Strength is preserved even if one family is later weakened.

03

Staged rollout

Changes propagate through defined rings of services with verification at each stage before the next begins. A fault surfaces in a bounded slice rather than across the whole estate.

04

Reversible steps

Each migration stage has a defined rollback while both schemes remain active. The system is never left in a state it cannot retreat from.

Every algorithm change is a decision with an owner, a record, and a reason

Crypto-agility without governance is just instability, so each change is authorized, logged, and reproducible after the fact.

01

Change authorization

Moving to a new scheme requires explicit owner authorization under quorum, the same discipline as key operations. No operator can shift the cryptographic baseline unilaterally.

02

Auditable change record

Each transition records what changed, when, under whose authority, and which records it affected. The migration itself becomes a verifiable artifact in the ledger's history.

03

Continuous inventory

A live inventory tracks which algorithm and parameter set protects every asset at any moment. Reviewers can answer what is running without inspecting code.

04

Deprecation discipline

Retired schemes are removed from the approved list so they cannot be selected again by mistake. Weakening a primitive globally is a one-time governed act, not an ongoing risk.

Build it sovereign.

Talk to us about crypto-agility in a sovereign deployment.