Crypto & Cipher Agility

A library and API platform that lets your systems apply, rotate, and replace cryptographic algorithms dynamically — without rewrites, without redeploys, without waiting for the next release cycle.

The last cryptographic migration your organisation will ever run.

// before: algorithm hardcoded at write-time
Signature s = Signature.getInstance("SHA256withRSA");
// after: resolved at runtime via policy
Signature s = Agility.resolveSignature("payment_ctx");
MessageDigest md = Agility.resolveDigest("payment_ctx");
Mac mac = Agility.resolveMac("payment_ctx");
// policy pushed over the wire — no files
PATCH /v1/policy/payment_ctx
{ "sign": "KAZ-SIGN", "hash": "SHA3-256",
"mac": "HMAC-SHA256" }
JCE-Compatible · KAZ · NIST PQC · Classical
Built for Developers

A platform you integrate, not a console you log into.

The design assumptions are the ones developers expect: explicit APIs, clear separation between calling code and configuration, policy pushed to the platform over the wire and enforced at runtime — no files in your repository, and behaviour that's deterministic given a policy and an input.

The platform does not ask your application code to know which algorithm is in use. It asks your operational layer to be explicit about what should be in use, and it enforces that choice at runtime.

Register Free Account
// policy pushed over the wire — no files, no redeploy
PATCH /v1/policy/payment_signing
{ "sign": "KAZ-SIGN", // local PQC
"hybrid": "ECDSA-P256", // classical fallback
"hash": "SHA3-256",
"mac": "HMAC-SHA256",
"kdf": "HKDF-SHA256" }
// unchanged across algorithm changes

Signature sig = Agility.resolveSignature("payment_signing");
sig.initSign(privateKey); sig.update(payload);
byte[] signature = sig.sign();

MessageDigest md = Agility.resolveDigest("payment_signing");
byte[] hash = md.digest(payload);

Mac mac = Agility.resolveMac("payload_auth");
mac.init(secretKey); byte[] tag = mac.doFinal(payload);
// ↑ all resolve policy at runtime — no algorithm names in source
The Problem

Crypto hardcoded is crypto frozen.

A standard gets deprecated
A vulnerability is disclosed
A regulator publishes a new directive
A post-quantum transition begins

In most codebases, cryptography is a decision frozen at the moment a function was first written. An algorithm name, a key size, a mode of operation — hardcoded into a call, copied across services, and forgotten until something forces a change.

Then something forces a change. Suddenly the cost of moving isn't a configuration update — it's a multi-quarter engineering program touching every service that ever called an encrypt, sign, or verify function. Not to forget the hashing/digest, Key Derivation Function (KDF), Message Authentication Code (MAC) operations and many more.

Crypto-agility is the architectural answer to this. But agility is not a property you can bolt on after the fact. It has to live in the integration layer — in the libraries developers actually call.

The Platform

What the platform is.

A set of libraries and APIs that abstract cryptographic operations away from specific algorithms. Your application calls an intent. The platform resolves which algorithm to use at runtime, based on policy — not a constant in your source code.

Intent-based operations

Your code calls agility.sign(), agility.encrypt(), agility.exchange(). Not algorithm names. The calling code stays stable across algorithm changes.

Policy over configuration

Algorithm choices, key parameters, and hybrid combinations are declared in policy — externalised from application code so cryptographic decisions become an operational concern, not a release-blocking code change.

Runtime resolution

The algorithm in production can change without the calling code changing. A new policy is published; the next call uses the new algorithm. Classical, post-quantum, or hybrid — selected by configuration.

Smallest possible footprint

Where you currently call a crypto library directly, you call the agility API instead. Everything else — algorithm selection, parameter choice, key handling — is resolved against the policy layer. The cipher agility overhead is as small as 13 bytes.

Architecture

How it fits into your stack.

Three layers with strict separation. A change at the policy layer propagates without touching the API layer your developers wrote against.

LAYER 01
API Layer

What your code calls

Operations are expressed in terms of intent — sign this, exchange a key, encrypt this payload — not in terms of algorithm. This is what makes the calling code stable across algorithm changes.

Agility.resolveSignature("ctx").sign(payload)
LAYER 02
Policy Layer

Where algorithm choices live

Algorithm choices, key parameters, and hybrid combinations are declared here. Policy is externalised from application code so cryptographic decisions become an operational concern, not a code change.

PATCH /v1/policy/ctx · { "sign": "ML-DSA-65" }
LAYER 03
Execution Layer

Where algorithms actually run

Handles the cryptographic primitives themselves and the binding to keys and parameters. The separation is the point — changes here propagate upward without developers touching application code.

KAZ-SIGN · KAZ-KEM · KAZ-KA · ML-DSA · ML-KEM · SLH-DSA · RSA · ECDSA · AES · SHA-2/3 · HMAC · KDF
Algorithm Suite

Every algorithm family. One unified API.

Local PQC, NIST-standardised PQC, and classical algorithms — all accessible through the same intent-based API and governed by the same policy layer. Switch algorithm families at runtime, not at build time.

Platform Native
Local PQC
KAZ-SIGN KAZ-KEM KAZ-KA

Sovereign post-quantum algorithms for local and jurisdiction-specific compliance requirements.

FIPS 203 / 204 / 205
NIST PQC Suite
ML-DSA ML-KEM SLH-DSA

Standardised NIST algorithms referenced by regulators globally. Interoperable and production-ready.

Classical & Symmetric
Classical Suite
RSA ECDSA AES-GCM SHA-2/3 HMAC KDF

Full classical and symmetric suite — encryption, hashing, MAC, and key derivation — for hybrid deployments and backward compatibility.

Capabilities

What you can build with it.

Five capabilities that become available the moment cryptographic choices move out of source code and into policy.

CAP · 01

Algorithm migration without code change

Move from a classical algorithm to a post-quantum one — or to a hybrid of both — by updating policy. Application code stays as it was.

CAP · 02

Hybrid PQC deployments

Run classical and post-quantum algorithms in parallel during transition periods, with policy controlling the combination logic.

CAP · 03

Policy-driven cryptographic governance

Define which algorithms are permitted, in which contexts, for which data classifications — enforced at runtime rather than reviewed in pull requests.

CAP · 04

Controlled rollouts

Stage algorithm changes the way you stage any other configuration change — by environment, by service, by traffic percentage — not as a single all-or-nothing event.

CAP · 05

Forward-compatible architecture

Whatever the next algorithm standard turns out to be, the integration point doesn't move. You change policy. Your code keeps running.

Ready to explore your use case?

Book a discovery call — no deck, engineering-led conversation.

Contact Us
Why This Matters Now

Algorithm landscapes shift. Release cycles don't.

Standards bodies deprecate. Threats evolve. Regulators publish directives on cycles that do not match software release cycles.

The organisations that will move through these transitions cleanly are the ones whose cryptography lives in a layer that can be changed without rebuilding the systems that depend on it.

The ones that will struggle are the ones whose crypto choices are scattered across thousands of source files, each one a small migration project waiting to happen.

Crypto-agility is not a feature you ship once. It is an architectural decision about where cryptographic choices live in your system — in the code, or in policy. This platform makes that decision answerable in policy.

Harvest now, decrypt later

Adversaries collect encrypted data today, decrypting it once quantum computers arrive. The exposure window is open now — before any algorithm is broken.

NIST standards are final. Local PQC is next.

ML-KEM, ML-DSA, and SLH-DSA are standardised and regulators are already referencing FIPS 204/205. Local PQC algorithms — KAZ-SIGN, KAZ-KEM, and KAZ-KA — are imminent, addressing sovereign and jurisdiction-specific requirements. The transition is no longer a future exercise, and the algorithm landscape is still moving.

Regulatory directives are arriving

Government mandates for post-quantum migration are publishing on policy cycles — not engineering cycles. Agility is what closes that gap.

Migration takes longer than you think

For large organisations, crypto migration across existing systems is measured in years. Starting with an agile architecture compresses that timeline significantly.

Free Access

Register a free account. Integrate today.

Register a free account to access libraries that can be integrated immediately and test within your application to test run the agility aspect.

Register Free Account
FREE TIER
Library access & sandbox
Full API access to test algorithm switching, dynamic policy updates, and hybrid combinations in a sandboxed environment.
INCLUDED
Real integrations, real algorithms
KAZ-SIGN, KAZ-KEM, KAZ-KA (local PQC), ML-KEM, ML-DSA, SLH-DSA (NIST PQC), classical asymmetric, AES, ChaCha20, SHA-2/3, HMAC, and KDF primitives — all available immediately.
NEXT STEP
Book a Discovery Call
Once you've explored the libraries, talk to our engineering team to map an agility-first integration to your production environment.

No sales pitch. Engineering-first conversation. We'll confirm via email.