IBM Research and ANKATech converge on the same answer: cryptography needs a control plane

In July 2026, IBM Research published a technical note arguing that cryptography needs its own abstraction layer, a way for applications to declare cryptographic intent instead of hardcoding algorithms. ANKATech has been building that layer since 2025. When an independent research team reaches the same architectural conclusion from a different starting point, it stops being a vendor position and starts being an industry direction.

Here is what that convergence looks like, and why it matters for teams planning the post-quantum transition.

What IBM Research argued

The paper starts from an observation most engineering teams recognize immediately. Filesystems and networking abstracted away their implementation details decades ago. Cryptography never did. Algorithm choices remain scattered across application code, service by service, and developers still write and maintain large volumes of security sensitive code by hand for operations as routine as signing and decryption.

The proposal has three parts.

First, an intent based API built on a vocabulary of scopes, meaning classes of cryptographic intent such as digital signature or authenticated encryption. An application declares that it needs a signature. It does not name the algorithm. Any algorithm that satisfies the scope becomes interchangeable.

Second, a separation borrowed from software defined networking: a control plane holding central policy over which algorithms are permitted, and a data plane enforcing those decisions at runtime. The consequence is organizational as much as technical, because the algorithm decision moves from application developers to security operations.

Third, backend interchangeability. Software libraries, hardware accelerators, cloud services and trusted execution environments all sit behind a single interface. That is what turns an algorithm change into an operational action rather than a release cycle.

What ANKASecure© and CAPA deliver

That is the architecture ANKASecure© implements in production today. It operates as an orchestration layer between enterprise applications and cryptographic execution, whether that execution happens in software libraries, HSMs or cloud KMS. Applications declare cryptographic intent by key ID. ANKASecure© resolves the algorithm, applies lifecycle policy and governance, and executes. The application never touches cryptography directly.

The control plane is a policy engine with regional presets covering NIST, NSA CNSA 2.0, ANSSI and BSI, propagating changes across the estate in under one second, with a full audit trail of who requested what, under which algorithm, and with what result. Moving from RSA to ML-KEM (FIPS 203) becomes a policy update rather than a code change. Historical data can be re-encrypted or re-signed under the new algorithm without exposing plaintext, a capability currently patent pending in the USPTO.

The platform covers 125+ algorithms across 21+ families, spanning classical, post-quantum and hybrid composite, including ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205) and Falcon-512/1024, against 14+ international standards across four regulatory regions.

We did not keep the architecture proprietary. Alongside the product, ANKATech published the Cryptographic Control Plane (CCP) Standard, an open specification that defines what any conformant cryptographic control plane must provide: a standardized abstraction layer, policy driven algorithm governance separate from code, algorithm lifecycle management without redeployment, centralized key lifecycle orchestration, and complete cryptographic audit and traceability. ANKATech is the founding contributor. The specification is at version 0.9, published as a working draft, and open for community contribution on conformance testing, open source implementation and alignment with existing frameworks such as NIST SP 800-57.

The CCP Standard also formalizes CAPA, Crypto Agile Posture Architecture. CAPA defines five pillars, crypto agility, cryptographic sovereignty, frictionless modernization, policy driven governance and regulatory compliance, together with a six level maturity model running from L1, where cryptography is hardcoded and uninventoried, to L6, where cryptographic governance is continuous. Most organizations we assess sit at L1 or L2. The strategic target is L5. IBM Research described the destination architecture. CAPA describes how organizations get there in stages.

Why this matters now

The post-quantum transition is the reason this argument lands in 2026 rather than 2016. The architectural gap has always existed, but it was never worth the cost of fixing on its own. PQC changes that calculation. Systems are being rearchitected anyway, budgets are approved, and deadlines under CNSA 2.0 and DORA make the work non optional.

That creates a fork.

An organization can migrate to post-quantum algorithms the way it migrated to every previous generation, hardcoded, application by application, and reproduce exactly the same technical debt with new primitives. On ANKATech's internal estimate, a 200 application estate spends roughly $840,000 and several months of engineering on each such migration, and migrations of this kind recur every three to five years.

Or it can spend the same budget introducing the abstraction layer once, and make the next algorithm change a policy decision rather than a program.

IBM Research called the PQC transition a rare opportunity to correct the architecture. We agree. The window closes as soon as the first wave of PQC migrations ships hardcoded.