ANKASecure©: the Cryptographic Control Plane, in operation

Executive summary

Most enterprises still treat cryptography as code. An algorithm is chosen when an application is written, embedded in that application, and changed only when the application is changed. The result is a cost structure that every security leader now recognizes: each change to cryptography becomes an engineering project, repeated for every application that depends on it.

That model has run out of time. In October 2026 NIST published the final version of IR 8547, which deprecates quantum-vulnerable public-key cryptography after 2030 and disallows it after 2035 ^[1]. United States federal directives set earlier dates for high-value systems ^[2], and the European Union has set its own milestones for 2030 and 2035 ^[3]. At the same time, classical cryptanalysis keeps retiring algorithms that were considered safe. The question facing organizations is no longer which algorithm to adopt. It is how long it takes them to leave the one they have.

ANKASecure© is a Cryptographic Control Plane that operationalizes this model. It does not proxy a policy to someone else: it executes the cryptographic operation, manages key material and records signed evidence, while the Root of Trust stays in the customer's own HSM or cloud KMS. The reference architecture it implements is described in the companion paper, The Cryptographic Control Plane ^[4], and the capabilities it delivers are organized by the CAPA framework.

This paper describes what ANKASecure© does today:

• One policy for cryptography. Algorithm availability, rotation and key lifecycle are governed by policy, set per deployment and overridable per tenant, enforced before every operation and fail-closed.
• 125+ algorithms in one catalogue, including 30+ post-quantum algorithms and 41 composite hybrid pairings, aligned with 14+ international standards bodies.
• Migration without plaintext exposure. Existing data is re-encrypted and re-signed under new algorithms inside the control plane, in streaming mode at any size, without the originating application.
• Sovereign custody. Each tenant chooses its Root of Trust. The key-encryption key that protects its keys never leaves the customer's HSM or cloud account.
• Governed authority. Third parties receive revocable capability grants with explicit constraints instead of keys.
• Evidence by default. Every operation, refusal, policy change and administrative action is recorded in a signed, hash-chained audit trail that can be verified independently.

These capabilities are packaged into seven solutions, each addressing a concrete business problem, all running on the same platform. Organizations typically enter through one urgent need and extend to the others without adding infrastructure.

1.1 About this version

This document supersedes version 1.0 of the ANKASecure© white paper (February 2026). It has been rewritten from the ground up to reflect the platform as it is delivered today, to align with the terminology of The Cryptographic Control Plane reference architecture and the CAPA framework, and to describe the solutions in which the platform is offered. Where a capability is delivered through ANKATech channel partners rather than by the platform itself, the paper says so.

Why now

2.1 The clock is now written down

For several years the post-quantum transition was discussed as a future planning item. That period is over. The standards are published, the deprecation dates are set, and regulators on both sides of the Atlantic have converted guidance into timelines.

Previous cryptographic transitions have taken ten to twenty years ^[1]. The window between now and 2030 is shorter than the time most organizations need to change cryptography that is embedded in hundreds of applications.

2.2 Harvest now, decrypt later

An adversary does not need a quantum computer today to create exposure today. Encrypted data captured now can be stored and decrypted once a cryptographically relevant quantum computer exists. For data that must stay confidential for ten, twenty or more years (financial records, health information, identity data, intellectual property, government archives), the exposure began when the data was first encrypted with a quantum-vulnerable algorithm, and it grows with every new record written the same way.

This is why key establishment and data encryption are migrated first, and why the problem is not only new data. The data already at rest, encrypted under keys that are quantum-vulnerable, is part of the liability.

2.3 Not every break is quantum

Quantum computing is the most visible driver, but it is not the only one. Algorithms leave service for many reasons, and several recent examples needed no quantum computer at all:

• Rainbow, a signature finalist in the NIST process, fell in 2022 to a classical key-recovery attack that ran on a laptop ^[8].
• SIKE, which had just advanced to the fourth round of the NIST process, was broken by a classical attack within weeks in 2022 ^[9].
• Classic McEliece was standardized by ISO in June 2026 ^[10] and then, in October 2026, advised against for new use by Germany's BSI after significant progress in its cryptanalysis ^[11]. Existing protection did not become unreadable, but new protection had to move elsewhere.

Each of these events forced the same question on every organization using the affected algorithm: how long will it take us to stop using it? The answer depends far less on the algorithm than on the architecture around it.

2.4 The real variable is response time

ANKATech uses the term Cryptographic Response Gap for the interval between T0, the moment an algorithm's acceptability changes for a given use (a deprecation, a published attack, a new regulatory requirement, a customer questionnaire), and T1, the moment remediation is complete across the estate. The gap extends the classic window of exposure, and it is the migration-time term in Mosca's inequality ^[12]: if the time needed to migrate plus the time data must stay secret exceeds the time until the threat materializes, the data is already at risk.

When cryptography is embedded in code, the gap is measured in quarters or years, because closing it requires code changes, regression testing, security validation and release, repeated application by application. A completed post-quantum migration does not change that. It replaces the algorithm, but the next change will cost the same. Crypto-agility is the ability to make the next change cheap.

Migration changes the algorithm. Agility changes what the next change costs.

From architecture to operation

3.1 The Cryptographic Control Plane

Enterprise infrastructure has repeatedly solved the same structural problem in the same way. Credentials embedded in applications became identity infrastructure. Network configuration embedded in devices became software-defined networking. Secrets in configuration files became vaults. In each case, a capability that every application implemented separately was moved into a governed layer, and applications began to consume it instead of implementing it.

The Cryptographic Control Plane applies that pattern to cryptography. It separates cryptographic intent, expressed by applications, from cryptographic execution, governed by policy. It centralizes governance without requiring that execution or key custody be centralized: keys, Roots of Trust and execution domains can remain distributed across HSMs, cloud KMS platforms, regions and jurisdictions, while policy, lifecycle and evidence are coordinated in one place. The architecture is described in full, in vendor-neutral terms, in The Cryptographic Control Plane white paper and at cryptographiccontrolplane.org ^[4].

3.2 CAPA: the capabilities a posture requires

CAPA, the Crypto Agility Posture Architecture, defines the capabilities an organization needs to sustain cryptographic change ^[4]. It is organized in five pillars:

CAPA also defines a six-level maturity model, from embedded cryptography to continuous cryptographic evolution. Maturity is measured by capability, by what the organization can do today in response to a vulnerability or a standard change, not by how much legacy migration remains. Chapter 9 places ANKASecure© on that model.

3.3 Where ANKASecure© fits

ANKASecure© is an implementation of the Cryptographic Control Plane and the originating implementation of CAPA. The relationship between its capabilities and the CAPA pillars is complementary, not one-to-one: a single platform function, such as the policy engine, contributes to several pillars, and each pillar depends on several functions working together.

3.4 Design principles

Six principles shape how the platform is built and how it should be evaluated:

• Execute, do not proxy. ANKASecure© performs encryption, decryption, signing, verification, re-encryption and re-signing itself, and manages key material. Where the trust model requires it, execution can take place in an external HSM, KMS or engine, as policy determines.
• Govern centrally, keep trust distributed. Centralized lifecycle governance does not make ANKASecure© the ultimate Root of Trust. The organization keeps that role in infrastructure it controls.
• Fail closed. An unreadable policy, an unresolvable tenant or an unverified token results in a refusal, never in a permissive default.
• Evidence is not optional. Every operation, refusal and change produces a signed record. Compliance is demonstrated by querying the control plane, not reconstructed from application logs.
• Integrate outward. The customer's HSM, identity provider, SIEM and observability platform remain authoritative. ANKASecure© connects to them rather than replacing them.
• State the scope honestly. The platform governs the operations brought to it. What it does not do is stated explicitly in Chapter 10.

Platform architecture

4.1 Intent and execution

An application calls ANKASecure© with two things: a stable key identifier and the data. It never names an algorithm. The control plane authenticates the caller, resolves the key's metadata and the policy in force, checks the key's lifecycle state and the caller's authority, executes the operation and records the evidence. The response reports which algorithm was used, so the application can log it, but it does not need to know it in advance.

Because the identifier is stable, the key underneath can change. Rotation advances a key to a new material version under the same identifier, potentially with a different algorithm in the same purpose family. New operations use the new version immediately; data protected under earlier versions keeps decrypting and verifying under the version that wrote it.

4.2 Two surfaces per environment

Every installation exposes two separate surfaces. The Runtime surface serves cryptographic operations to applications and workloads. The Management surface serves the console and the administration of tenants, keys, policies and grants. Each surface exposes only its own operations, on its own address. Applications therefore never reach administrative functions, and administrative tooling never sits on the data path.

A new installation ships without an administrator. The first administrator claims the instance with a one-time code, so no default credential ever exists.

4.3 Execution engines

Cryptographic operations run in two dedicated services: one for compact operations on payloads held in memory, and one for streaming operations on large objects. Streaming operations process data in chunks with bounded memory, so a multi-gigabyte archive and a small record use the same operation and the same memory footprint.

Operations are admitted against a memory budget. No single tenant can consume more than half of it; requests beyond the budget receive a retry response instead of degrading the service for everyone. In a multi-tenant deployment this prevents one tenant's load from affecting another's availability.

4.4 Cryptographic catalogue

The catalogue spans 125+ algorithms, including 30+ post-quantum algorithms and 41 composite hybrid pairings, aligned with 14+ international standards bodies: NIST, NSA CNSA 2.0, ETSI, ENISA, BSI, ANSSI, CRYPTREC, KISA, MySEAL 2.0, ISO/IEC, IETF and NESSIE, among others.

Composite keys use AND-decrypt: both the classical and the post-quantum component must succeed. ANKASecure© deliberately does not implement OR-decrypt, which would be only as strong as the weaker component. Composite signatures likewise require both components to verify.

The catalogue is itself governed. When BSI advised against new use of Classic McEliece ^[11], the algorithm was moved to legacy status in the platform: existing keys continued to decrypt, while new protection under that algorithm was no longer offered. This is the same mechanism the platform gives customers for their own policies.

4.5 Output representation

Encrypted and signed outputs use structures based on the JOSE family, JWE and JWS ^[13], with extended algorithm identifiers for mechanisms that standard JOSE registries do not yet define. This gives governed applications a consistent representation even as the underlying algorithm changes, and it means protected data is not locked into a proprietary format.

This should not be read as universal JOSE interoperability. An external implementation can process a representation only if it supports the algorithms, identifiers and profiles used. Where a counterparty requires a specific standard profile, that requirement becomes part of the governed interoperability context.

4.6 Multi-tenancy and isolation

One deployment serves many tenants, each representing a business unit, a subsidiary, a customer or a jurisdiction. Each tenant has its own keystore, its own policies within the deployment's limits, its own audit trail and its own key-encryption key, protected by the Root of Trust it selects. Each tenant can also use its own SIEM, observability backend and identity provider. Tenant data filtering applies to every read, including reads by identifier, and tenant names reject invisible characters that could be used to impersonate another tenant.

Where stronger separation is required, a dedicated single-tenant deployment provides full infrastructure isolation.

4.7 Deployment and operation

ANKASecure© is deployed as SaaS operated by ANKATech, in the customer's private cloud, or on-premise, including air-gapped environments. It is also available through AWS Marketplace with hourly licensing. Custody is an independent decision: any deployment model can be combined with any supported Root of Trust.

• Upgrades in place, with the option to return to the previous version until the upgrade is confirmed.
• Backup and restore with a signed inventory of key custody; a restore rotates the token-signing keys.
• Capacity profiles sized to the host, and installation by domain name or by IP address.
• Operational visibility: health checks, platform log search from the console, distributed tracing of internal calls and telemetry export over OTLP.

Policy, lifecycle and custody

5.1 The policy engine

Cryptographic policy in ANKASecure© has three layers:

• Algorithm availability controls which algorithms may be used, by explicit list, family, category (classical, post-quantum, hybrid), security level, standards body or operation. Hybrid-only profiles are supported.
• Rotation defines permitted transitions and intervals, for example blocking security downgrades or a return from post-quantum to classical, and refusing rotation intervals beyond the maximum cryptoperiod.
• Lifecycle defines which operations each key state allows.

Policies are set per deployment and can be overridden per tenant. The platform ships with 37 templates: 29 for algorithm availability, aligned with NIST, NSA CNSA 2.0, BSI, ANSSI, ETSI, CRYPTREC and other bodies; 6 for rotation; and 2 for lifecycle. Custom policies are also supported.

Enforcement happens before the operation, not after it. Key generation, rotation and every cryptographic operation are checked against the active policy; a violation is refused with a reason, not logged and allowed. Policy changes propagate to every service instance in under a second, without restart or redeployment.

The policy engine also protects itself:

• Tenant policies cannot fall below the deployment's minimum security strength.
• A compliance-locked deployment refuses changes to its own policy.
• An optional quorum requires a second approver for any change that weakens algorithm, rotation or lifecycle policy, or key limits.
• Policy changes are themselves signed audit events.

5.2 Acceptability, not broken or secure

Algorithms rarely go from secure to broken in one step. NIST SP 800-131A ^[14] treats acceptability as a status per operation, and ANKASecure© enforces it the same way:

Before any rotation, the server computes its admissibility against the rotation policy and returns a verdict and a reason code for each candidate algorithm. Operators can see in advance which transitions the policy will permit.

5.3 Key lifecycle

Every key follows a seven-state lifecycle governed by policy. Two distinctions are central:

• Retirement is not destruction. Superseded and retired keys keep decrypting and verifying, while new encryption and signing are refused. Data written under an old key remains readable during and after migration.
• Why a key was revoked matters. A key revoked because its algorithm was deprecated keeps history readable. A key revoked for compromise is sealed.

Destruction is a separate, deliberate step. It requires approval by designated people other than the requester (M of N) and a cooling-off period of 7 to 365 days. A key identifier is never reused. Key state is sealed: a change made outside the platform is rejected.

Keys can carry a usage ceiling and a soft limit that warns before the ceiling is reached, an expiry date and a rule on whether key material may ever be exported. Rotation can be scheduled at deployment, tenant or key level, within the periods set by the applicable compliance pack, or usage-based, triggered at the soft limit or the ceiling. Scheduled rotation executes exactly once, even across restarts and outages. Every limit event produces a signed audit event, a SIEM event and a notification.

5.4 Sovereign custody

Each tenant's Root of Trust is resolved through three rungs, stopping at the first one declared: the tenant's own backend, the managed backend assigned by its licensed edition, or the deployment default. Keys are protected by envelope encryption: data keys are wrapped under a per-tenant key-encryption key (KEK) that never leaves the selected backend.

• Bring your own key. A tenant declares a key in its own AWS KMS, Google Cloud KMS, Azure Key Vault or Azure Managed HSM account, or in an HSM through PKCS#11, under its own credential. ANKASecure© performs a live round trip against the backend before accepting the declaration.
• Dual records. Every wrap and unwrap calls the tenant's backend, so it appears both in ANKASecure©'s signed audit trail and in the provider's own log.
• Hardened KEKs. KEKs generated in an HSM are created read-only. An alert is raised if a tenant's KEK is rejected by its backend.
• Custody that can move. A tenant's custody can be moved to another backend: its KEK rotates online and its keys move during a maintenance window, without recreating the tenant. KEKs held in a managed KMS rotate on the provider's schedule.

ANKATech does not operate the customer's HSM or cloud account. The customer keeps the backend, its credential and its availability.

Authority, evidence and compliance

6.1 Separation of authority

ANKASecure© separates three kinds of authority: the platform, which operates the deployment; the tenant, which owns its keys and policies; and the operator, who executes work on the tenant's behalf. The person who grants a capability is not the person who exercises it.

• People sign in with passkeys, a password with an authenticator, or the organization's identity provider through OIDC, SAML or LDAP. Platform administrators sign in with passkeys only, and in SaaS, local sign-in uses passkeys only. Sensitive changes require identity confirmation, and an emergency access procedure is available.
• Automation authenticates as a non-human identity of its own, never with a person's credentials.
• Workloads authenticate with the token their own platform issues, through workload identity federation. ANKASecure© issues no credential that a workload must store or rotate.
• Support access is consented. In SaaS, ANKATech staff can read a tenant's audit trail only within a support session the tenant has authorized, and changes made in that session are attributed to the platform operator who made them.

6.2 Capability grants and exchange contexts

Permissions to use keys are modeled as capability grants. A grant names an actor, the operations it may perform and the keys in scope. It can carry a constraint policy with four enforced dimensions: a validity window, a total usage cap, a per-minute rate limit, and single use.

Every grant belongs to an exchange context, which names the counterparty, its type, the keys in scope and an owner, and which has its own lifecycle (created, active, suspended, closed). The organization can therefore answer at any moment who exchanges what, with whom, under which limits. Usage is counted when the cryptographic operation actually executes. Revoking a grant or suspending a context blocks the next call immediately, with no re-encryption of the data it governed.

An exchange topology view in the console shows every context and its activity, and a Cryptographic Playground lets an administrator execute a real operation against a grant to test it before a counterparty does.

6.3 Signed evidence

Every cryptographic, administrative and authentication operation is recorded with its algorithm, key, outcome (success, failure or denial) and reason, in a signed, hash-chained audit trail. Each read of protected material is recorded, every completed scheduled task is recorded, and every read of the audit trail is itself recorded. Signed tables are write-once for runtime roles. Audit retention is at least twelve months.

The trail is queryable per tenant, per application, per exchange context, per constraint policy and per actor, and can be exported. Events are forwarded to the customer's SIEM in CEF or OCSF with the signature and canonical preimage preserved, so an auditor can verify them independently of ANKASecure©. Signatures can carry RFC 3161 timestamps ^[15] from any timestamping authority, verifiable offline.

6.4 Posture, compliance packs and CBOM

The console computes the organization's cryptographic posture from the live estate across the CAPA pillars: whether custody is declared and bound, how much of the estate is modernized, how many tenants govern deliberately through declared policy, and how many governed keys conform to the policy in force.

Six compliance packs add framework-specific posture assessments, signed evidence and remediation plans: NIST PQC Transition (following the final NIST IR 8547 ^[1]), NSA CNSA 2.0 ^[7], EU PQC Roadmap ^[3], BSI TR-02102-1 ^[16], ANSSI PQC ^[17] and NIST CSWP 39 ^[18]. Each pack can produce a signed evidence package that includes a Cryptography Bill of Materials (CBOM) in CycloneDX format ^[19], listing the tenant's live keys with algorithm, state, dates and custody, without key material.

ANKASecure© is not a discovery tool. It does not scan the estate for cryptography that has not been brought to it. It complements discovery: the CBOM it produces describes the governed estate precisely and feeds the organization's overall inventory.

6.5 Regulatory alignment

The platform's controls map to the cryptographic requirements of the main regulatory frameworks:

Solutions

The platform is offered as seven solutions. Each starts from a business problem that a specific owner recognizes, and each runs on the same control plane, the same policy and the same evidence. An organization that adopts one solution has already deployed the foundation for the others.

7.1 Crypto-Agility

The problem

Changing an algorithm today means a code change, a regression cycle, security validation and a release, repeated for every application that uses it. Teams defer the change, and estates keep running on algorithms that should have been retired.

How ANKASecure© addresses it

Applications call stable capabilities against stable key identifiers. Availability, rotation and lifecycle policies decide which algorithm serves each call; admissibility is computed before any rotation; retired keys keep historical data readable; re-encryption and re-signing move protected data to the new algorithm without the original applications. Policy changes reach every instance in under a second.

Typical use cases

• An algorithm must be retired after a deprecation, a published attack or a customer's refusal in a security questionnaire.
• Two jurisdictions require different approved algorithm lists for the same application.
• The organization wants to raise its posture before a forcing event arrives.

7.2 Post-Quantum Migration

The problem

Moving to post-quantum algorithms normally requires decrypting existing data first, which creates plaintext exposure and requires changes in the applications that own the data. Meanwhile, every record written with a quantum-vulnerable algorithm adds to the harvest-now, decrypt-later liability.

How ANKASecure© addresses it

The target is declared once, with a policy template such as NIST, CNSA 2.0, BSI or ANSSI, and non-compliant key material is refused everywhere without an application release. Existing PKCS#12 and JKS keystores are imported through a seven-stage validation pipeline. Data is re-encrypted inside the control plane: the data key is unwrapped and re-wrapped, and the payload is never written to storage, logs or the caller (patent pending). Composite hybrid keys hedge against weaknesses in either component.

Typical use cases

• Long-retention data whose confidentiality period extends beyond the safe life of current algorithms.
• A regulatory deadline or procurement requirement naming FIPS 203, 204 and 205.
• A hybrid transition in which classical and post-quantum protection must coexist.

7.3 Enterprise Cryptographic Control

The problem

Cryptographic decisions are made inside each application, so no one can say with certainty which algorithms protect which data. Key managers, certificate managers and discovery tools each cover part of the picture, but none decides whether an operation is allowed. A standard can be adopted on paper with no system able to refuse a violation.

How ANKASecure© addresses it

The three-layer policy engine enforces the standard before every operation and refuses violations with a reason. Authority is explicit, through revocable grants on a role model that separates platform, tenant and operator. Every decision is recorded as signed evidence, and posture is computed from the live estate.

Typical use cases

• Enforcing an internal cryptographic standard across business units.
• Answering an auditor's question about which policy applied to a given operation, by query.
• Governing changes that weaken policy through quorum approval.

7.4 Legacy Cryptography Modernization

The problem

Archives encrypted or signed years ago in PKCS#7 or CMS outlive the applications that wrote them, and sometimes the vendors behind them. Certificates expire long before retention periods end. Decrypt-and-re-encrypt scripts put plaintext on disk and in logs; leaving the data in place leaves the risk in place.

How ANKASecure© addresses it

Keys are imported while still valid, with each certificate's status and migration path reported, and trust anchors are identified before import. Archives are analyzed before they are touched. Envelopes are converted to the JOSE representation in streaming mode, re-encrypted under a fresh content key inside the control plane, and then moved to post-quantum or composite keys under rotation policy. Old keys are retired, not destroyed, so original envelopes remain readable until migration ends. The migration operator holds a re-encryption grant only and never sees content. SHA-1 and MD5 signers are refused unless explicitly allowed.

Typical use cases

• Records whose originating system has been decommissioned.
• Archives tied to a certificate that will expire long before the retention period ends.
• Platform modernization programmes that have stalled at data encrypted under the old scheme.

7.5 Governed Third-Party Exchange

The problem

Outsourcing a process (payroll, claims, KYC, printing, analytics) or exchanging data with other institutions usually means handing a long-lived private key to a counterparty. That key cannot be scoped, metered or taken back without re-encrypting everything it protected, so it is often left in place. A data-processing agreement does not limit a key.

How ANKASecure© addresses it

The relationship is modeled as an exchange context. The counterparty receives a capability grant, not a key, with a validity window, usage cap, rate limit and optional single use. Its workload authenticates with its own platform's token. Every use is recorded with its grant and constraint decision; revocation takes effect on the next call. The principle is simple: share capabilities, not keys. ANKASecure© governs cryptographic access, not data transport.

Typical use cases

• Outsourced processing of sensitive data by a service provider.
• Inter-institutional exchange of protected data within a regulated ecosystem.
• Ending a provider relationship without re-encrypting the data it could access.

7.6 Sovereign Key Custody

The problem

Regulators, boards and customer contracts increasingly require that key material never leave the organization's HSM or jurisdiction. Any platform that holds the Root of Trust is disqualified early. Cloud migrations and subsidiaries with different rules add further constraints.

How ANKASecure© addresses it

Each tenant selects its Root of Trust through three-rung precedence. With BYOK, the tenant declares a key in its own account, validated by a live round trip. The KEK never leaves the backend; every wrap and unwrap appears in both audit records. Deployment model and custody are independent choices, and custody can be moved to a new backend as a governed operation.

Typical use cases

• A compliance clause that requires custody in the organization's own HSM or cloud account.
• A cloud migration in which workloads move but keys must stay under the organization's control.
• Subsidiaries that need different custody models in a single installation.

7.7 Digital Signatures & Long-Term Evidence

The problem

Contracts, regulatory filings and clinical records must verify for a decade or more, but the algorithm that signs them today has a retirement date. A signature proves who signed, not when; without an independent timestamp, "signed before the key was compromised" is only an assertion.

How ANKASecure© addresses it

Policy selects the signature algorithm: ML-DSA, SLH-DSA, FALCON, stateful hash-based schemes, classical families or composite signatures. Signatures are timestamped against any RFC 3161 authority ^[15], with per-tenant policy set to required, optional or disabled, and the token is embedded as a JAdES B-T profile (ETSI TS 119 182-1) ^[23]. When an algorithm is retired, the RESIGN operation re-signs existing signatures under an approved algorithm and records the lineage, so the new signature is verifiably the successor of the old one.

Typical use cases

• Long-retention records with legal or regulatory value.
• Re-anchoring existing signatures before an algorithm deprecation date.
• Establishing proof of time for signed transactions and documents.

Integrations and developer experience

8.1 Integration ecosystem

ANKASecure© integrates with 45 external systems across eight categories. Each integration family has a configuration plane, a runtime plane and a per-tenant override. Each integration is labeled certified when a live round trip has been run end to end against the real vendor product, or experimental when the adapter ships and certification is in progress. Twenty-five of the 45 are certified today, and certification runs continuously.

Notification delivery includes failover and a dead-letter path. In SaaS, each tenant receives only its own telemetry.

8.2 For developers

A cryptographic call needs two fields, the key identifier and the data, and every operation supports FIPS 203, 204 and 205 algorithms when policy selects them. Applications use 29 data-plane operations; the platform exposes 547 operations in total, all of them available outside the console.

• Runtime SDK and CLI for cryptographic operations, and Key Management SDK and CLI for keys, tenants and grants. The Java SDKs are published on Maven Central; the CLIs run on Windows, macOS and Linux.
• REST APIs with OpenAPI 3.0 specifications for every other language, with reference samples in 20 languages.
• Recipes for common tasks, such as rotating from RSA-2048 to ML-KEM-768, signing and verifying with ML-DSA-87, and sign-then-encrypt with nested JWE and JWS.
• SDKs that protect secrets: credentials and key material are masked in messages, exceptions and logs.
• Documentation that answers questions. Customer documentation is versioned per release and can be queried in natural language from AI assistants through an MCP connector, which answers only from the documentation the user is entitled to see.

8.3 For operators

The console, available in English and Spanish, covers tenants, identities, keys, policies, grants, exchange contexts, audit and posture. It shows the next rotation of every key and the cause of each version, activity per application, per exchange context and per actor, and complete records of applications, actors and contexts with owner, contacts, data classification and risk level. Destructive actions require confirmation, and logging out clears cached data in the browser.

Maturity and adoption

9.1 The CAPA maturity model

The CAPA maturity model describes six levels ^[4]. Two principles govern it. Maturity is measured by capability, so a legacy estate in active migration is work in progress, not a deficit. And post-quantum cryptography is not the last level; it is a dimension that improves at every level from the moment a control plane is in place.

Deploying ANKASecure© establishes Level 3 for the systems it governs. Progress to Levels 4 and 5 is a matter of coverage: onboarding more applications, migrating more protected data and bringing more of the estate under the same policy.

9.2 Three ways in, one platform

Organizations typically reach ANKASecure© through one of three entry points, each driven by a different urgency:

• Enterprise cryptographic control: a standard that must be enforced and evidenced.
• Post-quantum readiness: a deadline, a regulator or a customer questionnaire.
• Cryptographic sovereignty: a custody requirement or a third party that needs access without receiving keys.

All three converge on the same control plane. Once the platform governs one need, a second need is a new policy, a new tenant or a new exchange context, not a new infrastructure project.

9.3 A phased path

Positioning and scope

10.1 Where ANKASecure© sits

ANKASecure© does not replace the components organizations already rely on. It operates at a different layer, and it is most valuable when those components remain in place.

10.2 What ANKASecure© does not do

Stating the boundaries is part of the design:

• It governs only the operations brought to it. Applications that have not been onboarded are not covered, and onboarding is real work.
• It does not discover cryptography across the estate on its own; discovery is delivered by channel partners.
• It cannot recover data whose keys are lost, convert archives whose keys have expired, or reach data held by systems that will not delegate the operation.
• It does not protect plaintext that is legitimately delivered to a counterparty, and it does not see what a counterparty does with results.
• It does not operate the customer's HSM or cloud account, and it does not move key material between backends without a governed operation.
• Crypto-agility on the organization's side does not guarantee that external systems support the same algorithms.
• It is not a qualified trust service provider and does not archive documents.
• It enforces acceptability; the people who own cryptographic risk decide what is acceptable. It does not certify compliance.

Conclusion

The post-quantum transition has a schedule, and it will not be the last transition. Organizations that treat it as one more migration project will finish it and find themselves exactly where they started, with cryptography still embedded in code and the next change priced the same as this one.

The alternative is architectural. Move the cryptographic decision out of the application, govern it as policy, keep the Root of Trust where the organization controls it, and record evidence of every operation. That is what a Cryptographic Control Plane does, what CAPA measures, and what ANKASecure© delivers today: one platform that executes, governs and evidences cryptography across classical, post-quantum and hybrid algorithms, deployed as SaaS, in a private cloud or on-premise.

References

1. [1] National Institute of Standards and Technology. NIST IR 8547, Transition to Post-Quantum Cryptography Standards. Final version, 27 October 2026.
2. [2] The White House. Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks, 22 June 2026; and Office of Management and Budget, Memorandum M-26-15, Execution of the Migration to Post-Quantum Cryptography, 24 June 2026.
3. [3] NIS Cooperation Group. A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, version 1.0. June 2025.
4. [4] ANKATech Solutions INC. The Cryptographic Control Plane: A New Architecture for Continuous Cryptographic Evolution, version 2. November 2026. cryptographiccontrolplane.org.
5. [5] National Institute of Standards and Technology. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard; FIPS 204, Module-Lattice-Based Digital Signature Standard; FIPS 205, Stateless Hash-Based Digital Signature Standard. 13 August 2024.
6. [6] Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), and Commission Delegated Regulation (EU) 2024/1774 (regulatory technical standards on the ICT risk management framework).
7. [7] National Security Agency. Announcing the Commercial National Security Algorithm Suite 2.0, September 2022; and The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ, version 2.1, December 2024.
8. [8] W. Beullens. Breaking Rainbow Takes a Weekend on a Laptop. CRYPTO 2022.
9. [9] W. Castryck and T. Decru. An Efficient Key Recovery Attack on SIDH. EUROCRYPT 2023 (IACR ePrint 2022/975, July 2022).
10. [10] ISO/IEC 18033-2:2006/Amd 2:2026, Information technology. Security techniques. Encryption algorithms. Part 2: Asymmetric ciphers. Amendment 2. June 2026.
11. [11] Bundesamt für Sicherheit in der Informationstechnik (BSI). Note on Classic McEliece, advising against its use in new developments. 1 October 2026. bsi.bund.de.
12. [12] M. Mosca. Cybersecurity in an Era with Quantum Computers: Will We Be Ready? IEEE Security & Privacy, 16(5), 2018.
13. [13] IETF. RFC 7516, JSON Web Encryption (JWE), and RFC 7515, JSON Web Signature (JWS). May 2015.
14. [14] National Institute of Standards and Technology. SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths. March 2019.
15. [15] IETF. RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). August 2001.
16. [16] Bundesamt für Sicherheit in der Informationstechnik (BSI). Technical Guideline TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths. Current edition.
17. [17] Agence nationale de la sécurité des systèmes d'information (ANSSI). ANSSI views on the Post-Quantum Cryptography transition. 2022, with 2023 follow-up.
18. [18] National Institute of Standards and Technology. CSWP 39, Considerations for Achieving Crypto Agility: Strategies and Practices. 19 December 2025 (update 1, June 2026).
19. [19] Ecma International. ECMA-424, CycloneDX Bill of Materials Specification.
20. [20] Directive (EU) 2022/2555 (NIS2), and Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024.
21. [21] PCI Security Standards Council. Payment Card Industry Data Security Standard, v4.0.1. June 2024.
22. [22] Regulation (EU) 2016/679, General Data Protection Regulation (GDPR).
23. [23] ETSI TS 119 182-1, JAdES digital signatures; Part 1: Building blocks and JAdES baseline signatures.

About ANKATech ANKATech Solutions INC is a Delaware-incorporated company that builds ANKASecure©, a Cryptographic Control Plane for governing, migrating and evidencing cryptography across classical, post-quantum and hybrid algorithms. ANKATech is the author of The Cryptographic Control Plane reference architecture and the CAPA framework, published under an open license at cryptographiccontrolplane.org. ANKATech is a member of the PKI Consortium and the Cloud Security Alliance, and works with channel partners that deliver cryptographic discovery, assessment and migration services.

www.ankatech.co · contactus@ankatech.co

ANKASecure© is a registered trademark of ANKATech Solutions INC. Patent pending. This document describes capabilities of the platform as delivered at the date of publication and does not constitute a contractual commitment. Compliance determinations remain with each organization and its auditors.