An algorithm has to go
Deprecated, broken, or refused by a customer questionnaire. The incident has a clock, and your honest answer is a release calendar across every application that touches it.
ANKASecure© makes a cryptographic change a policy operation rather than an application project. Applications reference a key by a stable identifier and never name an algorithm, so the algorithm, key version and parameters behind that identifier can change while historical data continues to decrypt under the version that wrote it. The permitted set of algorithms is an availability policy applied deployment-wide or per tenant, with twenty-nine templates including jurisdictional sets aligned to BSI, ANSSI, ETSI, CNSA 2.0, CRYPTREC and KCMVP, over a catalogue of more than 120 algorithms of which 33 are post-quantum. Before a change is made, the platform computes rotation admissibility per candidate and returns a reason code — security downgrade, requires hybrid, purpose violation — using the same rule that executes. A policy change propagates to the enforcement point per tenant in under a second without a restart, and every subsequent operation is recorded with the policy that decided it in a signed, tamper-evident audit trail. This applies to applications already onboarded to the control plane; onboarding is real work, and what changes is the economics of every transition after it.
Every cryptographic change costs you a project per application.
Nobody asks for crypto-agility by name. What they live with is this: when an algorithm has to change it is a code change, a regression cycle, a security validation and a release — multiplied by every application that uses it. So the change is deferred, and the estate keeps running on what it should already have left behind. ANKASecure© turns that change into a policy operation.
CISOHead of cryptographyEnterprise architect
Is this you
Three ways this lands on your desk
Two jurisdictions, two approved lists
A subsidiary under BSI needs hybrid. A federal contract names CNSA 2.0. An operation in Japan runs on CRYPTREC. Today that means separate stacks, or exceptions nobody wants to sign.
You want to raise the level and cannot justify a release
No vulnerability, no incident — just a posture you would rather have. Without a forcing event the change never reaches a sprint, and the gap between what you run and what you would choose keeps widening.
Who signs this: A CISO or head of cryptography who will be asked how fast the organization can move, and an enterprise architect who knows what a change across two hundred applications actually costs. If the answer to “how long to leave this algorithm?” is measured in quarters, this is the conversation.
How it works
Four moves, none of them a release
The application never names an algorithm, so changing the algorithm is not a change to the application. What moves is policy, and the platform can tell you in advance whether the move is allowed.
The application references a name, not a mechanism
It asks for a key by its stable identifier. Which algorithm, which key version and which parameters sit behind that identifier are the platform’s business, and they can change underneath it while historical data keeps decrypting.
- stable KID
- material versions
The change is a policy decision, not a code change
The permitted set of algorithms is a policy, applied deployment-wide or per tenant. Twenty-nine templates ship with the product, including jurisdictional ones — BSI, ANSSI, ETSI, CNSA 2.0, CRYPTREC, KCMVP — over a catalogue of 120+ algorithms, 33 of them post-quantum.
- availability policy
- 29 templates
- deployment or tenant plane
The server tells you whether the move is admissible, before you make it
Ask for the rotation admissibility of a key and the platform returns a verdict per candidate with a reason code — security downgrade, requires hybrid, purpose violation. It is the same rule that runs at execution, so the preview and the outcome cannot disagree.
- rotation admissibility
- reasonCode
It takes effect in under a second, and the evidence shows it applied
A policy change reaches the enforcement point per tenant without a restart. Every operation afterwards is recorded with the policy that decided it, signed, in a chain that would show any edit. The change is not a claim; it is a queryable fact.
- sub-second propagation
- signed audit trail
The algorithm is a setting. This is the setting.
Twenty-nine templates in the catalogue — NIST_APPROVED, EU_COMPLIANT for ENISA, GDPR, NIS2 and eIDAS 2.0, HIGH_SECURITY for levels 3 and 5 — applied deployment-wide and overridable per tenant. Changing the template changes what the next operation may use.
Fifteen minutes
What you will actually watch
Live, on a real deployment, with an algorithm of the kind you are stuck on. Nothing in this list is a mock-up or a roadmap item.
An application encrypting under a classical algorithm, referencing its key by name.
The admissibility verdict for that key: which candidates are allowed, which are refused, and the reason code for each.
The policy changes centrally. No application is touched. No release is cut.
The same application, unchanged and not restarted, now writing under the new mechanism.
A candidate the policy refuses: the operation is denied with its reason, never silently downgraded.
The audit trail: which policy decided which operation, signed — the evidence an auditor asks for.
What it rests on
The capabilities underneath, with their state
Shipping
Stable key identifiers
The application references a kid; material versions move underneath it and historical data keeps decrypting under the version that wrote it.
Shipping
Algorithm availability policy, two planes
Deployment-wide or per tenant, enforced on every operation, fail-closed: an unreadable policy denies rather than permits.
Shipping
Twenty-nine policy templates
Jurisdictional and standards-aligned sets over a catalogue of 120+ algorithms, 33 of them post-quantum.
Shipping
Server-computed rotation admissibility
A verdict per candidate with a reason code, produced by the same rule that runs when the rotation executes.
Shipping
Sub-second policy propagation
A change reaches the enforcement point per tenant without a restart or a redeploy.
Shipping
Signed audit trail
Which policy decided which operation, tamper-evident, forwardable to your SIEM with the signature preserved.
The framework
Where this sits in CAPA
The Cryptographic Control Plane reference architecture describes each pillar through the scenarios it must handle and one practical test. This solution is two of the three scenarios of the first pillar — responding to an algorithm vulnerability, and evolving the cryptographic strategy without an application release.
01
Primary pillar
Crypto-Agility
Scenario realised
Responding to an algorithm vulnerability
Practical test
“Can the cryptographic strategy change without requiring an application change or release?”
04
Supporting pillar
Cryptographic Governance & Compliance
Scenario realised
Enforcing a new enterprise security requirement
Practical test
“Can the organization prove, by querying the control plane, which policy applied to a given operation, and change that policy centrally?”
L2–L3L4–L5
Maturity move
From a cryptographic change that needs a release to one that is a policy operation — and from there to an organization that can state how long a transition takes, because it has already done one and has the evidence.
What this does not do
It does not apply to applications that have not been onboarded. The reference architecture is explicit about this and so are we: onboarding is real work. What changes is the economics of every transition after it — the first application is a project, the next change is not.
It does not make a representation universally interoperable. An external system can read what you produce only when it supports that operation’s algorithms, identifiers and profiles; agility on your side is not adoption on theirs.
It does not rewrite data already written. Moving existing ciphertext onto a new algorithm is re-encryption — that is the post-quantum migration conversation, and it uses the same control plane.
After this
The same installation already does these
No new deployment and no second contract for the platform. Once cryptography is a policy operation, the rest is a change of policy.
How long would it take you to leave one algorithm?
Bring the one you would most like to be rid of. Fifteen minutes on a live deployment: the admissibility verdict, the policy change, and the same application writing under the new mechanism without a release.
Book the demo