- A new arXiv paper (2606.13445) argues that algorithm transition is largely a software engineering problem, not a cryptography problem — and most APIs in production today were built around specific algorithms, with no clean path to migrate keys.
- The proposed intent-based design rests on five architectural characteristics (Abstraction, Stability, Temporal Flexibility, Separation, Extensibility) and three key evolution operations (rotation, transformation, migration), implementable with Protocol Buffers patterns.
- For your security posture: if your application code names algorithms directly, every future crypto change — PQC and beyond — is a code-rewrite project. Decoupling intent from algorithm turns that into an operational policy change.
Why Your Codebase Is the Real PQC Bottleneck
Picture the migration meeting your team has not yet had. NIST finalized its first post-quantum standards — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) — on August 13, 2024. The mandate is clear. So an architect pulls up the service mesh and asks a simple question: “How many places do we call RSA or ECDSA by name?” The answer comes back in the thousands, scattered across microservices, client SDKs, stored key metadata, and serialized protocol fields.
That is the moment cryptographic agility stops being an abstract virtue and becomes a line item. The arXiv paper Intent-Based Cryptographic API Design for Cryptographic Agility (2606.13445) makes the uncomfortable diagnosis explicit: most cryptographic APIs in use today were designed around specific algorithms and expect explicit use of those algorithms. They provide little or no support for policy-based algorithm selection, and offer no straightforward way to migrate existing keys to newer algorithms.
The attack surface here is not a broken cipher. It is organizational inertia. Every hardcoded algorithm identifier is a hidden migration cost that compounds across your portfolio. When a cipher is deprecated — whether by a quantum advance, a newly discovered weakness, or a compliance deadline — the work is not cryptographic. It is the grind of finding, editing, testing, and redeploying application code that should never have known the algorithm’s name in the first place.
The Technical Deep-Dive: Designing for Substitution
The paper’s core claim reframes the entire problem:
“Algorithm transition is largely a software engineering problem.” — Intent-Based Cryptographic API Design for Cryptographic Agility (arXiv:2606.13445)
If transition is a software problem, then the fix lives in API design, not in picking the next cipher. The authors derive their design from five fundamental architectural characteristics:
- Abstraction — application code expresses what it needs cryptographically, not which algorithm delivers it.
- Stability — keys are referenced by stable identifiers that survive algorithm changes.
- Temporal Flexibility — the system anticipates that today’s algorithm choice is provisional.
- Separation — key creation is decoupled from algorithm identity, and policy is decoupled from code.
- Extensibility — new algorithms and providers slot in without breaking existing callers.
Intent Vocabulary: Decoupling Keys from Algorithms
The mechanism is an intent vocabulary based on scopes. Instead of requesting “a 256-bit ECDSA signing key,” an application requests a key for a purpose within an applicable scope. That indirection is what lets the platform perform transparent substitutions of algorithms underneath the same intent. The caller never learns — and never needs to learn — that ECDSA quietly became ML-DSA.
Key Evolution: Rotation, Transformation, Migration
Because keys are represented by stable identifiers, the design supports three key evolution operations:
- Rotation — replacing key material while preserving identity.
- Transformation — changing a key’s underlying algorithm in place.
- Migration — moving between algorithms and providers while tracking both the original key identity and its evolution history.
That last detail matters for audit and compliance: the approach facilitates migration between algorithms and providers while preserving lineage, so you can prove what a key was, what it became, and when.
Governance Without Prescription
Cryptographic governance is enabled by an abstract policy API that does not prescribe the policy format. Your organization decides what “acceptable” means — minimum key strength, approved providers, mandated PQC posture — and the platform enforces it at selection time. The paper notes these principles can be implemented using Protocol Buffers API design patterns, grounding an abstract idea in a concrete, widely deployed serialization framework.
Algorithm-Bound vs. Intent-Based APIs
| Dimension | Traditional Algorithm-Bound API | Intent-Based Agile API |
|---|---|---|
| Caller specifies | Exact algorithm (e.g. ECDSA-P256) | Intent + scope (purpose) |
| Algorithm change | Edit + redeploy application code | Transparent substitution, no code change |
| Key reference | Tied to algorithm/material | Stable identifier across evolution |
| Migration support | None / manual re-issuance | Rotation, transformation, migration built in |
| Policy selection | Hardcoded in application | Abstract policy API, format-agnostic |
| Audit lineage | Lost on re-issuance | Original identity + evolution history tracked |
| New algorithm onboarding | Breaking change | Extensible by design |
The decisive shift: “With this approach, updating cryptography becomes an operational process without the need to rewrite application code.” That single property converts every future crypto transition from an engineering project into a change-management ticket.
Industry Context: The Migration Burden Nobody Budgeted For
The regulatory clock is already running. With FIPS 203/204/205 finalized in August 2024, and U.S. federal guidance (NIST IR 8547, in draft) signaling a phased deprecation of quantum-vulnerable algorithms, the question for enterprises is no longer whether to migrate but how many times they will have to. PQC standards are young; parameter sets and preferred algorithms will continue to evolve. An organization that migrates from RSA to ML-KEM by rewriting code has not solved its problem — it has rehearsed it once and will pay again at the next change.
This is where intent-based design separates the prepared from the exposed. The market is bifurcating into two camps: teams treating PQC as a one-time fire drill, and teams treating cryptographic agility as a permanent architectural property. The paper’s companion assessment framework — referenced as a tool to identify the barriers to cryptographic agility — exists precisely because most organizations cannot yet answer “where is our crypto, and how fast can we change it?”
The economic asymmetry is stark. The cost of inaction is not a single migration bill; it is that bill multiplied by every future algorithm transition, plus the breach risk during each prolonged code-rewrite window. The cost of adopting agile API patterns is front-loaded engineering discipline that amortizes across every transition thereafter.
The BeQuantum Perspective
Here is how organizations like ours are operationalizing this. The paper describes the design principles; the hard part is enforcing them across a live estate where keys already exist and applications already name algorithms.
BeQuantum’s PQC Layer treats the intent vocabulary as a control plane rather than a library. Application services request signing or key-establishment by purpose and scope; the layer resolves that intent against an organizational policy and selects a compliant algorithm — classical, post-quantum, or hybrid — without the calling service ever embedding an algorithm identifier. When a parameter set is deprecated, the substitution happens at the policy layer.
The Digital Notary addresses the lineage requirement the paper raises. Because key evolution operations (rotation, transformation, migration) must preserve both original identity and evolution history, every transition is anchored to a tamper-evident record. That gives auditors a verifiable chain: this key was ECDSA, became ML-DSA on this date, under this policy version. For IceCase hardware deployments, the same stable-identifier model lets keys evolve in the field while the hardware root of trust remains fixed.
The point is not a product. It is that the paper’s claim — crypto updates as an operational process — only holds if the abstraction, the policy plane, and the lineage tracking are all enforced together. Any one of them missing, and you are back to editing code.
What You Should Do Next
- Within 90 days, run a crypto-agility assessment. Inventory every place application code names an algorithm directly — TLS configs, signing services, SDKs, serialized key metadata. You cannot decouple what you have not located. The paper’s framing of barriers is a useful checklist here.
- Within two quarters, pilot an intent abstraction on one high-churn service. Pick a service that signs or encrypts frequently. Replace direct algorithm calls with a purpose-scoped request routed through a policy layer. Measure the delta in effort to swap an algorithm before and after.
- Mandate stable key identifiers and lineage tracking now. Even ahead of full PQC rollout, require that new keys carry stable identifiers and that any rotation preserves evolution history. This is the cheapest insurance against the next transition, not just this one.
FAQ
Q: What is cryptographic agility in plain terms? A: Cryptographic agility is the ability to change the cryptographic algorithms a system uses — switching ciphers, key types, or providers — without rewriting application code. The intent-based approach in arXiv:2606.13445 achieves it by having code express what it needs cryptographically, while the platform decides which algorithm fulfills it.
Q: Does adopting an intent-based API mean I no longer have to migrate to post-quantum algorithms? A: No. You still adopt PQC algorithms like ML-KEM and ML-DSA. The difference is that the migration becomes an operational policy change rather than a code-rewrite project, and the next transition after PQC costs you far less because the abstraction is already in place.
Q: Why does the paper recommend Protocol Buffers? A: The design principles — abstraction, stability, separation — map cleanly onto Protocol Buffers API design patterns, giving teams a concrete, widely deployed way to implement an intent vocabulary and an extensible, format-agnostic policy interface rather than inventing a new wire format.
[IMAGE: A single skeleton key dissolving into modular interlocking blocks that reassemble into a new key, rendered in dark cyan light against black — symbolizing algorithm substitution without identity loss]
Last updated: 2026-06-13. Primary source: Intent-Based Cryptographic API Design for Cryptographic Agility, arXiv:2606.13445.
