Skip to content

ANKATech whitepapers

Audience: CISOs, CIOs, Enterprise Architects, Risk and Compliance leaders

Reading time: 8 minutes

ANKATech publishes three whitepapers on the architecture behind ANKASecure©. This page summarizes each one and defines the concepts it introduces. The complete whitepapers are available from the ANKATech website after a short registration; ANKASecure© customers also find their full content in the customer documentation.

The Cryptographic Control Plane

The Cryptographic Control Plane — A New Architecture for Continuous Cryptographic Evolution. Introducing CAPA, Crypto Agility Posture Architecture. Version 2, September 2026. Get the whitepaper.

Thesis. Cryptography embedded in application code is the structural problem behind every slow cryptographic transition. Identity, networking and secrets management already moved from capabilities embedded in each system to shared infrastructure governed by policy; cryptography is now reaching the same point. The post-quantum transition is the first large-scale test of that shift, and not the last.

Concepts it introduces:

  • Cryptographic Control Plane — an architectural layer that separates cryptographic policy and lifecycle management from application implementation. Applications express cryptographic intent; infrastructure governs how it is executed. It concerns application and data cryptography, not the cryptography protocols such as TLS manage internally, and it complements PKI rather than replacing it.
  • Centralized Governance, Distributed Trust — policy, lifecycle and control decisions converge in one layer, while keys, Roots of Trust and execution may stay distributed across HSMs, cloud KMS platforms, providers and jurisdictions.
  • CAPA — Crypto Agility Posture Architecture — a framework of five pillars: Crypto-Agility, Cryptographic Sovereignty, Frictionless Modernization, Cryptographic Governance & Compliance, and Enterprise Readiness.
  • The CAPA Cryptographic Maturity Model — six levels, from Embedded Cryptography to Continuous Crypto Evolution. Maturity is measured by what the organization can do today in response to a cryptographic change, and post-quantum cryptography is a dimension that improves at every level rather than a final level.
  • Three parallel migration tracks — greenfield (new systems adopt governed cryptography immediately), brownfield critical (the five to ten most critical applications, analyzed in parallel with the control plane deployment) and brownfield general (the remaining landscape, inventoried and migrated by risk).

The concepts are documented in full in The Cryptographic Control Plane, CAPA and The Cryptographic Maturity Model.

Cryptographic Sovereignty in Third-Party Information Exchange

Cryptographic Sovereignty in Third-Party Information Exchange — Share information with third parties while keeping control of its cryptographic access. Version 3, October 2026, in English and Spanish. Get the whitepaper.

Thesis. When an organization shares protected information with a third party, it usually hands over the key or the cleartext, and control ends at the moment of sharing. In recurring exchanges, one shared key ends up opening every delivery the third party ever received. Cryptographic sovereignty replaces shared keys with shared capabilities: keys never leave the owner's control domain, and third parties are authorized to invoke cryptographic functions under governed, mediated and auditable conditions. This is a problem of today, with today's algorithms, and solving it makes post-quantum readiness across external relationships a consequence rather than a prerequisite.

Concepts it introduces:

  • From sharing keys to sharing capabilities — a third party receives the right to invoke a specific function, over specific material, in a specific exchange context, under explicit constraints. Revocation is unilateral, takes effect at the next invocation and requires no re-encryption.
  • Three properties of sovereign exchange — sovereign control (where authority is anchored), mediated use (how it is exercised) and full auditability (how it is demonstrated). Remove one and sovereignty collapses.
  • Two planes — the transport plane (managed file transfer, SFTP, APIs, messaging, integrations) moves information; the cryptographic control plane decides who may open what travels. Sovereign exchange changes only the second, so existing channels stay in place.
  • The accumulation effect — in recurring exchange under one shared key, exposure grows with every delivery; with per-delivery, single-use authorization it stays bounded to the delivery currently authorized.
  • Five building blocks — Exchange Context (the relationship), Cryptographic Actor (who executes), Capability (what it can do), Cryptographic Asset (with what material) and Constraint Policy (under what conditions).

The principle is documented in Cryptographic sovereignty and CAPA Pillar 2 — Cryptographic Sovereignty.

Crypto Agility Beyond the Quantum Clock

Crypto Agility Beyond the Quantum Clock — Why post-quantum migration is necessary, and why it is not enough. Version 1.1, November 2026. Get the whitepaper.

Thesis. Post-quantum migration prepares organizations for the cryptographic transition they can see coming; crypto agility prepares them for the changes they cannot predict. Cryptographic security is an evolving assessment, as NIST and the IETF have long stated, and recent events (Rainbow, SIKE, the withdrawal of HAWK after AI-assisted cryptanalysis, BSI's advice against new use of Classic McEliece, and a real-scale RSA signing-oracle forgery) show that it moves on its own schedule, often without any quantum computer.

Concepts it introduces:

  • Broken is not the enterprise threshold — enterprises operate on acceptability, a status that standards bodies, regulators and policies assign to a mechanism, for a purpose, at a point in time. Acceptability can be withdrawn before any practical attack exists: cryptographic obsolescence can precede cryptographic failure.
  • The Cryptographic Response Gap — the interval between T0, when the security assessment, applicable standard or acceptable-use status of a mechanism changes for a given use, and T1, when the organization has stopped using it to apply new protection and has handled the information it protected according to policy. The organization cannot control T0; its architecture sets the length of the gap.
  • The 200-application problem — an organization that migrates 200 applications to a new algorithm, with the algorithm still embedded in each, must repeat the whole program when that algorithm stops being acceptable. Migration changes the algorithm; agility changes the architecture of the problem.
  • Key rotation is not algorithm agility — rotating key material and changing the mechanism that serves a use are different capabilities, governed by different guidance.
  • Governed, not negotiated — the answer to the critics of crypto agility: mechanisms decided by policy and enforced centrally, a curated set per use, one well-exercised point of change, and exit as a first-class operation.
  • The controlled exit — adopting new cryptography is only half of crypto agility. A lifecycle of per-operation states (acceptable, not for new deployments, deprecated, legacy use, migration only, disallowed) lets an organization stop new use of a mechanism while it keeps decrypting and verifying what it protected, until that information is re-encrypted or re-signed.

The pillar is documented in CAPA Pillar 1 — Crypto-Agility and Policy-Driven Crypto-Agility Fundamentals.