Executive Summary
Every enterprise today exchanges sensitive information with dozens or hundreds of third parties: suppliers, business process outsourcers, fintechs, card networks, laboratories, agencies, cloud services and specialized vendors. That exchange is no longer an exception to be managed at the edge of the organization. It is how the organization operates.
The cryptographic model that supports this exchange has not kept pace. When an organization needs a third party to process protected data, it typically does one of two things: it hands over the cryptographic key, or it decrypts the data and hands over the cleartext. In both cases, control over the data ends at the moment of sharing. The owner does not know when or how its cryptographic authority is used, cannot revoke access in real time, has no independent evidence of use, and — in the first case — no longer holds the only copy of the key.
The exposure also accumulates. When the exchange is recurring, as most are, a single shared key ends up protecting every delivery the third party has ever received: a year of deliveries, and anything else encrypted under the same key. The longer the relationship, the larger the blast radius of a single compromise.
Regulation has moved in the opposite direction. DORA, PCI-DSS 4.0, GDPR, SOX and banking and data-protection regimes across jurisdictions all converge on the same principle: the data owner remains the ultimately responsible party, regardless of which third party processes the information. Some supervisors now ask explicitly about third-party cryptographic dependencies. The costliest breaches of recent years did not occur inside the organizations that suffered them; they occurred at their third parties.
The model rests on a single shift: from sharing keys to sharing capabilities. A third party does not receive cryptographic material. It receives the right to invoke a specific cryptographic function, over specific material, in a specific exchange context, under explicit constraints — and every invocation is recorded in the owner's domain. Revocation is immediate and unilateral, and it does not require re-encrypting any data. Evidence is produced by the owner's infrastructure, not reported by the third party.
None of this replaces the way information is exchanged. Files over managed file transfer, payloads over APIs, events over messaging platforms and transactions across application integrations keep travelling through the channels the organization already operates. The model acts on a different layer: who holds the cryptographic authority to open what travels through those channels, and under which conditions it can be opened. Transport and cryptographic control are two planes, and sovereign exchange operates only on the second.
Because the third party invokes a capability rather than holding a key, the owner can rotate keys and change algorithms behind that capability as often as its policy requires, even one key per delivery, without the third party changing a single line of code, and without the owner changing its applications either.
This is a problem of today, not of the quantum era. Losing control of data shared with a third party happens with RSA, with AES and with the algorithms organizations already use. Solving it does not require a post-quantum migration, a complete cryptographic inventory, or the prior decoupling of every application. It requires changing how cryptographic authority is exercised across the boundary of the organization, and that can start with the algorithms and the HSMs already in place. Post-quantum readiness across external relationships then follows as a consequence.
Delivering this model requires an architectural layer that neither a hardware security module, a key management system, nor an API gateway provides on its own: a Cryptographic Control Plane. An HSM stores keys. A proxy transports requests. A control plane governs — deciding who may exercise which cryptographic capability, over what material, in which context and under which constraints, and producing cryptographic evidence of every decision.
The paper describes the forces breaking the traditional exchange model, defines cryptographic sovereignty as a property of the organization rather than of the key, and presents a five-element conceptual model for sovereign exchange: Exchange Context, Cryptographic Actor, Capability, Cryptographic Asset and Constraint Policy. It separates the transport plane, which the organization keeps, from the cryptographic control plane, which it gains. It illustrates the model with banking scenarios that span the main exchange channels (card issuance across multiple embossing providers, outsourced collections, credit origination with a fintech over an existing API, and recurring deliveries over an existing managed file transfer platform) and shows how the same structure applies across financial services, government, healthcare, telecommunications, retail and software.
It then describes the regulatory alignment the model produces, the value it delivers to the board, the CISO and the CIO, an adoption path from pilot to platform, and how ANKASecure© implements the model as a Cryptographic Control Plane.
This document is a companion to The Cryptographic Control Plane whitepaper, which introduces the architecture and the CAPA framework (Crypto Agility Posture Architecture). Cryptographic sovereignty is the second of CAPA's five pillars. This paper develops the pillar in the context where it matters most: the moment an organization's data crosses an organizational boundary.
Chapter 2The Third-Party Exchange Problem
For most of the history of enterprise security, the boundary of control coincided with the boundary of the organization. Data that stayed inside was protected by the organization's own controls; data that left was, by definition, exposed. Cryptography was the mechanism that allowed data to leave while remaining protected in transit and at rest — but only until it reached a party that had to use it.
That party needed a key. And the key, once handed over, carried with it every property of control.
2.1 Four forces breaking the traditional exchange model
Four concurrent developments have turned this long-standing limitation into a structural risk.
Hyperconnected ecosystems
A typical enterprise today exchanges sensitive data with dozens or hundreds of external parties. A bank issues cards through multiple networks and embossing providers, outsources collections and customer service, reports to regulators, integrates embedded fintechs and participates in open-banking schemes. A hospital shares clinical records with laboratories, insurers and research partners. A telecommunications operator exchanges call records with roaming partners, MVNOs and interconnection providers. Each relationship implies that protected information is processed outside the owner's domain.
Growing regulatory pressure
DORA in the European Union, PCI-DSS 4.0 in the card industry, SOX in the United States, GDPR and its national equivalents, data-residency laws and banking supervisors from the Gulf to Asia and the Americas all assign ultimate responsibility to the data owner. Outsourcing a process does not outsource the liability. Regulators increasingly expect the owner to demonstrate — with evidence — how third parties are controlled, not merely that a contract exists.
Supply-chain risk
The costliest breaches of recent years did not occur at the organizations whose data was exposed, but at their third parties: processors, software providers, service partners. The attack surface of an organization is now the union of the attack surfaces of everyone who holds its data or its keys. The perimeter is no longer the organization's to defend alone.
Quantum cryptography on the horizon
The transition to post-quantum cryptography is not optional. But an organization that has distributed keys and cleartext data to many third parties cannot migrate on its own timeline. Every algorithm change must be coordinated bilaterally with every counterparty, multiplying the operational complexity of a transition that is already demanding within a single organization.
2.2 What happens today when information is shared
The traditional exchange model has two variants, and both end the same way, whatever the channel: files over SFTP or managed file transfer, payloads over APIs, events over messaging platforms or transactions across application integrations.
In the first, the owner shares the cryptographic key. The third party can now decrypt, sign or verify at will, for as long as the key remains valid, over any data protected with it. The owner has no visibility into when the key is used, cannot revoke it without coordinating a replacement with the third party, and must trust the third party's own controls to prevent duplication or misuse.
In the second, the owner relies on the protection of the channel alone. The information is decrypted before it leaves, or travels protected only by the transport, and it arrives in cleartext at the third party's application: a file delivered over SFTP, an API payload received over TLS, a message read from a queue. The third party now holds unprotected sensitive information on its own infrastructure. The owner has no independent record of when it was opened or how often, and revoking access means changing the entire data pipeline.
In both variants the consequence is identical: control ends at the moment of sharing.
- The owner does not know when, how often or under which conditions the information is opened.
- The owner cannot revoke access in real time.
- The owner has no auditable evidence of use produced within its own domain.
- The key — or the cleartext — lives outside the owner's control domain.
Where traditional exchange leaves gaps
Neither traditional strategy is wrong; each solves the problem it was designed for. Transport protection gets information to the third party safely, and encryption keeps it unreadable in transit and at rest. Neither decides when, under which conditions and how often the third party may open it.
| Question | Transport protection (SFTP/MFT, APIs over TLS, messaging) | Encryption to the third party (PGP, shared keys) | Sovereign exchange |
|---|---|---|---|
| Who holds the authority to decrypt? | The third party: it receives cleartext | The third party: it holds the key | The owner; the third party only invokes |
| Can access be revoked without the third party's cooperation? | Only for future deliveries; what was delivered stays readable | No: keys must be replaced on both sides | Yes, at the next invocation |
| Can use be limited (once, a time window, a batch)? | No | No | Yes, per invocation |
| Is there evidence of use in the owner's domain? | Of the delivery, not of its use | No: decryption happens at the third party | Yes, signed and with full context |
| Does exposure grow over time? | Yes: cleartext accumulates | Yes: one key opens everything | No: bounded to what is authorized |
| Can the algorithm change without a bilateral project? | Not applicable: no cryptographic control over the information | No | Yes, by policy |
| Is the relationship with the third party modeled? | Only as a connection or endpoint | No | Yes: an Exchange Context |
| Does the owner control when and under which conditions cleartext is obtained? | No | No | Yes: every decryption is an authorized, recorded invocation |
The last row summarizes the difference. In the traditional strategies the third party decides when it decrypts; in sovereign exchange the owner's policy decides.
2.3 The accumulation effect of recurring exchange
Most third-party exchanges are not one-off events. They are recurring: a provider receives a new file twice a month, a processor receives a batch every week, a partner receives daily transactions. In the traditional model, the key is handed over once and then reused for every delivery that follows.
Consider an organization that sends protected data to a provider twice a month under a key shared on day zero. After one year, the provider holds 24 deliveries, all protected under the same key, and the key it holds opens every one of them, at any time, as many times as it wants. The same key also opens anything else that was ever encrypted with it, inside or outside that relationship.
The exposure therefore grows with the life of the relationship. A compromise of the third party in month twelve does not expose one delivery; it exposes a year of deliveries, and every other piece of data the key protects. Revoking that key requires generating a new one, distributing it and coordinating its activation on both sides, while the deliveries already received remain readable with the old one.
2.4 What is at stake
Loss of cryptographic sovereignty is not an abstract weakness. It materializes as three categories of risk.
| Operational risk | Regulatory risk | Strategic risk |
|---|---|---|
| A breach at the third party is the owner's breach. | Audit findings under SOX and PCI-DSS on key custody and segregation. | Operational dependency on the third party. |
| Irreversible leakage of sensitive data. | Sanctions for DORA non-compliance in ICT third-party risk management. | High cost of switching providers. |
| Inability to cut access immediately when an incident occurs. | Shared liability under GDPR and equivalent regimes. | Barrier to new integrations and partnerships. |
| Uncontrolled duplication of key material. | Exposure to civil litigation. | Loss of market trust. |
Each of these risks is a direct consequence of one architectural fact: the cryptographic authority over the data was transferred along with the data. Restoring control therefore requires not better contracts or more monitoring, but a different model of how cryptographic authority is exercised across organizational boundaries.
2.5 A problem of today, not of the quantum era
After several years of post-quantum attention, it is easy to file every cryptographic risk under the same heading. This one does not belong there. A key handed to a provider is just as exposed whether it is classical or post-quantum, and cleartext sent over SFTP is exposed regardless of the algorithm that protected it before it was decrypted.
Consequently, solving the third-party exchange problem does not depend on a post-quantum migration, on completing a cryptographic inventory of the entire landscape, or on first decoupling every application from its cryptography. It depends on changing who holds cryptographic authority at the boundary of the organization. Organizations can address it now, with the algorithms and the key infrastructure they already operate, and treat post-quantum readiness across their external relationships as a benefit that follows rather than a precondition.
Chapter 3The Principle of Cryptographic Sovereignty
This is the thesis of the paper, and everything that follows is a consequence of it.
3.1 Sovereignty as a property of the organization, not of the key
The CAPA framework defines cryptographic sovereignty as the ability of an organization to retain ultimate authority and control over its cryptographic trust, its cryptographic choices and the use of its cryptographic capabilities, regardless of where its data, infrastructure or business processes operate. Its core principle: retain control of cryptographic trust, choice and authority wherever your data operates.
The definition is deliberately broader than key ownership. Owning a key is necessary but not sufficient. An organization that owns a key and then hands a copy to a processor still owns the key — and has lost sovereignty over its use. Sovereignty concerns authority: who may exercise a cryptographic capability, under what conditions, for how long, and who can withdraw that authority.
When protected information is shared with third parties, sovereignty therefore extends beyond custody. It governs who may exercise cryptographic operations, under what constraints, and when that authority can be revoked — without the cooperation of the party whose authority is being withdrawn.
3.2 Three properties of sovereign exchange
A third-party exchange preserves cryptographic sovereignty when it exhibits three properties simultaneously.
Sovereign control
Key material remains in the owner's control domain, always protected by an HSM, KMS or equivalent Root of Trust that the owner administers. No copy is transferred to the counterparty. This is the custodial property: it determines where cryptographic authority is anchored.
Mediated use
The third party never executes cryptographic operations directly with the owner's material. It invokes a capability, and the invocation is evaluated, authorized and executed within the owner's domain. This is the operational property: it determines how cryptographic authority is exercised.
Full auditability
Every invocation is recorded with its complete context — which actor, which capability, which material, which exchange relationship, which constraints applied — by the owner's infrastructure. Evidence does not depend on what the third party reports. This is the evidentiary property: it determines how cryptographic authority is demonstrated.
Remove any one of the three and sovereignty collapses. Control without mediation is a key stored in a vault and then copied out. Mediation without evidence is a service whose use cannot be proven. Evidence without control is a log of decisions the owner could not have prevented.
3.3 Sovereignty does not require centralization
It is important to distinguish sovereignty from consolidation. An organization may deliberately distribute keys and Roots of Trust across multiple HSMs, KMS platforms, providers, regions or organizational domains — for resilience, risk isolation, jurisdictional or business reasons. Sovereignty does not require collapsing that distribution into a single repository. It requires that, wherever trust is anchored, the authority to use it remains with the owner and is exercised through governed mediation.
This is the principle the Cryptographic Control Plane whitepaper expresses as centralized governance, distributed trust: policy, lifecycle and control decisions converge in one layer, while keys, Roots of Trust and execution stay where the organization needs them.
3.4 Sovereignty over choice
Sovereignty also covers the organization's freedom to choose its own cryptography. Today, when a partner, a card network or an industry ecosystem requires a specific algorithm, format or standard, that requirement often becomes the de facto internal standard for every system that touches the exchange. In a sovereign model, the external interoperability requirement is satisfied for that interaction, while the organization's internal cryptographic posture remains its own decision.
3.5 A practical test
CAPA proposes a simple test for this pillar: can the organization govern policy across all its trust domains without moving keys, and revoke a third party's cryptographic authority without re-encrypting the data? An organization that must re-encrypt data, or coordinate a key replacement with the counterparty, in order to withdraw authority has transferred that authority. An organization that can withdraw it unilaterally, at the next invocation, has retained it.
3.6 Control over when information becomes cleartext
Sovereignty over third-party exchange is exercised at a precise moment: when protected information becomes cleartext. Every decryption is an authorized invocation, bound to an exchange context, limited by time windows, usage caps and rate limits, and recorded as evidence in the owner's domain. The owner therefore controls how, when and under which conditions a third party can obtain information in cleartext.
Authorization can be withdrawn at any time and takes effect at the next invocation. Third parties obtain only the information they are authorized to decrypt, when they need it, one record or one delivery at a time, instead of a year of information opened by a single key. Information already decrypted remains subject to the contractual and data-protection obligations that govern the relationship.
Chapter 4The Paradigm Shift: From Sharing Keys to Sharing Capabilities
The traditional model and the sovereign model differ in a single decision: what is shared.
4.1 The traditional model: sharing the key
When the key is shared, the third party owns cryptographic material. It can use that material whenever it wants and for whatever it wants, within the technical limits of the key. Revoking the key requires bilateral coordination — a new key must be generated, distributed and activated, and the old one retired, on both sides. Auditing depends on what the third party reports, because the operations occur on the third party's infrastructure.
4.2 The sovereign model: sharing a capability
When a capability is shared, the third party owns nothing cryptographic. It is granted the right to invoke a function — encrypt, decrypt, sign, verify — under the owner's governance. It can do only what was authorized, when it was authorized, over the material and within the scope that was authorized. Revocation is immediate and does not depend on the third party: the owner withdraws the authorization and the capability ceases to exist. Every execution is recorded in the owner's domain, because that is where it occurs.
| Traditional model — I share the key | Sovereign model — I share a capability | |
|---|---|---|
| What the third party holds | Cryptographic material. | An authorization to invoke a function. |
| What it can do | Anything the key permits, at any time. | Only what was authorized, when it was authorized. |
| Recurring deliveries | One key opens every delivery ever received. | Each delivery is authorized separately, for its own window. |
| Key rotation | Requires generating, distributing and activating a new key on both sides. | Governed by the owner's policy, as often as required, invisible to the third party. |
| Algorithm change | A bilateral project with every counterparty. | A policy change in the owner's domain; no code changes on either side. |
| Revocation | Requires bilateral coordination and key replacement. | Immediate and unilateral, from the owner's domain, without re-encrypting data. |
| Evidence | Depends on what the third party reports. | Produced by the owner's infrastructure for every execution. |
| Blast radius of a compromise | Every use of the key, past and future. | The authorized scope, for the authorized window. |
4.3 Why this is an architectural change, not a procedural one
It is tempting to read the sovereign model as a stricter contract or a tighter key-rotation policy. It is neither. Procedural controls operate on a key that has already left the owner's domain; they attempt to limit the consequences of a transfer that has already happened. The sovereign model prevents the transfer.
That prevention requires infrastructure: a component that sits between the third party and the owner's cryptographic material, understands the exchange relationship, evaluates each request against policy, executes or coordinates the operation within the owner's domain, and records the result. That component is a Cryptographic Control Plane.
4.4 Two planes: transport and cryptographic control
Third-party exchange involves two distinct jobs. The transport plane moves information from the owner to the third party: managed file transfer, SFTP, APIs, messaging platforms and application integrations. The cryptographic control plane decides who may open what travels, under which conditions, with which evidence. The two are complementary, and sovereign exchange changes only the second.
Steps 2 and 3 are the exchange as it works today. Steps 1 and 4 are the only new element: the owner's application calls ANKASecure© to protect the information, and the third party's application invokes it to decrypt, under the owner's policy. Neither call travels through the channel.
A Cryptographic Control Plane does not sit in the middle of the exchange. It does not route, transform, schedule or deliver information, guarantee delivery or translate protocols; all of that remains the work of the channel. It connects at the endpoints: the owner protects information before it is sent, and the third party invokes a governed cryptographic capability when it needs to use it.
| Existing mechanism | What it solves (transport plane) | What it leaves open | What sovereign exchange adds |
|---|---|---|---|
| Managed file transfer and SFTP | Reliable delivery of files and batches | The file is decrypted with a key the third party holds, or arrives in cleartext | The third party opens each delivery by invoking a bounded capability |
| APIs and integration services | Exchange of payloads and records between systems | The payload arrives in cleartext at the third party's application | Protected fields or records, opened per invocation |
| Messaging platforms | Distribution of events and messages | Consumers read messages in cleartext or with their own keys | Protected messages whose use is authorized per consumer |
| Direct application integrations (EDI, connectors) | Point-to-point connectivity | Each integration manages its own keys | One cryptographic access policy across all of them |
| Other compatible mechanisms | Transport specific to each case | Depends on the mechanism | Applies when the integration invokes the capabilities and the format is supported |
4.5 Information is not only files
A file is one possible representation of protected information, not the defining one. Organizations share files and batches, individual records, API payloads in JSON or XML, messages and events, and transactions between applications. The same sovereign model applies to all of them.
| Scenario | Information involved | Existing channel |
|---|---|---|
| Payroll processing | Files or batches of records | SFTP / managed file transfer |
| Fintech integration | JSON payloads, transactions | REST APIs |
| Outsourced services | Customer records | APIs / enterprise integration |
| Event processing | Messages or events | Queues / messaging |
| Exchange with laboratories | Documents, results, records | APIs / clinical platforms |
The control plane can govern operations over these kinds of information provided that the integration incorporates its capabilities and that the specific formats and flows are supported. The owner's application protects the information before it is sent, and the third party adapts its integration once to invoke the capability instead of decrypting with a key of its own. After that initial integration, key rotation and algorithm changes require no further change on either side.
Chapter 5The Role of the Cryptographic Control Plane
The Cryptographic Control Plane whitepaper defines the control plane as a dedicated infrastructure layer that decouples cryptographic policy, lifecycle management and execution from application implementation. Applications express intent; infrastructure governs execution.
Third-party exchange is the case in which that separation is most valuable, because the party expressing intent is not under the owner's administrative control. The control plane becomes the boundary at which the owner's authority is exercised over requests originating outside its domain.
5.1 What existing components provide, and what is missing
HSMs and KMS platforms are foundational components of enterprise cryptographic infrastructure, and nothing in this model replaces them or moves custody away from them. But organizations often assume that existing components already provide sovereign exchange. Each provides part of it, and none provides the whole.
| Capability | Traditional HSM / KMS | Encryption libraries and schemes (e.g., HPKE, Tink) | API gateway / proxy | Cryptographic Control Plane |
|---|---|---|---|---|
| Sovereign key custody | Yes | No: the recipient holds the private key | No | Yes |
| Exchange context as a first-class object | No | No | Partial | Yes, native |
| Granular usage constraints | Limited | No | Not cryptographic | Yes, per invocation |
| Immediate multi-party revocation | Partial | No: delivered ciphertext remains decryptable | Partial | Yes, from the plane |
| Evidence with full context | Limited | No: decryption occurs at the recipient | Traffic only | Yes, cryptographic |
| Crypto-agility and native PQC | Provider-dependent | At library level; requires coordinated changes on both sides | Not applicable | Yes, by design |
An HSM protects the key and executes operations on it, but it has no notion of an exchange relationship: it authenticates a client and performs the operation. A KMS manages the key's lifecycle and access, but its access model is designed for the owner's own systems, not for governing counterparties with distinct purposes, windows and limits. An API gateway can authenticate and rate-limit requests, but it is not cryptographic: it transports the request and has no authority over the material or the operation.
Modern encryption schemes and libraries, such as HPKE (RFC 9180) and Google's Tink, are valuable building blocks that make encryption safer and easier to implement. But they answer a different question. HPKE encrypts data to the holder of a private key; in a third-party exchange, that holder is the third party, which can decrypt every delivery it receives, at any time, outside the owner's view. Combined with a cloud KMS and identity policies, these tools can keep the wrapping key in the owner's domain and log its use, but they do not model the exchange relationship, cannot enforce per-delivery constraints such as single use, remain bound to one provider's identity and key infrastructure, and leave algorithm changes as coordinated engineering work on both sides. Encryption libraries define how data is protected. A Cryptographic Control Plane governs who may use that protection, for what, and for how long.
5.2 Four functions of the control plane in sovereign exchange
Sovereign custody
Keys are always protected by the owner's HSM or KMS and never leave the owner's control. The control plane does not require that custody be moved to it; it requires that custody never move to the third party.
Cryptographic mediation
Each cryptographic operation is invoked by the consumer and executed under the control plane's governance — never executed directly by the consumer with the owner's material. Mediation is what converts a shared key into a shared capability.
Policy-based governance
Who may invoke, what they may invoke, over what material, in what context and under what constraints — all of it is expressed as policy, evaluated at each invocation. Policy is the mechanism by which the owner's intent is enforced without the owner's participation in each operation.
Cryptographic evidence
Every invocation is recorded with its full context and forensic traceability. Evidence is generated where the operation occurs — the owner's domain — and is therefore independent of the counterparty.
5.3 How it works: the key never moves, the capability does
Consider an owner's control domain containing the control plane, the owner's HSM and the owner's policies. Three external parties — two card networks and an embossing vendor, for instance — each need to perform cryptographic operations on the owner's data.
Each party invokes a capability. The invocation passes through five stages within the owner's domain:
- Authentication — the invoking actor is identified as a known cryptographic actor.
- Authorization — the actor is confirmed to hold a valid grant for the requested capability, over the requested material, in the applicable exchange context.
- Restrictions — the constraints attached to the grant are evaluated: time window, invocation limits, data scope, rate, operational conditions.
- Mediation — the operation is executed within the owner's domain, using material that never leaves the owner's control and remains protected by the owner's Root of Trust.
- Evidence — the invocation, its context and its outcome are recorded in the owner's audit trail.
The cryptographic key never leaves the owner's control domain. Its protection remains anchored to the owner's Root of Trust, whether the operation executes within an HSM or KMS or within the control plane under that protection. What moves across the organizational boundary is a request and a result — never the material that connects them.
Revocation operates on the same path: withdrawing a grant, suspending an actor or closing an exchange context takes effect at the next invocation, without any action by the third party and without re-encrypting any data.
5.4 Execution and Roots of Trust
Mediation should not be read as implying that the control plane is merely a proxy that forwards every operation to an HSM. A Cryptographic Control Plane may execute cryptographic operations directly through its own engines while relying on the owner's HSM, KMS or other trust infrastructure to protect key material, establish Roots of Trust, or perform operations that must remain within those trust boundaries. Execution occurs in the execution domain appropriate to the operation, the policy, the key architecture and the trust boundary.
For sovereign exchange this distinction matters. Centralized governance of third-party access does not require that the control plane become the ultimate Root of Trust. Key material may be generated, managed and used by the control plane while its protection remains anchored to cryptographic infrastructure controlled by the owner. The owner retains the Root of Trust; the control plane exercises governed operations on its behalf. This is one of the clearest manifestations of cryptographic sovereignty: the organization can allow a control plane to operate its cryptography without ceding authority over it.
Chapter 6The Sovereign Exchange Model: Five Building Blocks
Governing third-party exchange requires a vocabulary. Traditional key management speaks of keys and permissions; that vocabulary cannot express a relationship with a counterparty, a purpose, a direction of exchange or a usage limit. The sovereign exchange model introduces five conceptual building blocks that, together, describe who can do what, over what material, in what context and under what conditions.
| Building block | Answers | Description | |
|---|---|---|---|
| 1 | Exchange Context | The exchange relationship | Models the exchange with a third party: with whom, for what purpose, in what direction, with what sensitivity. |
| 2 | Cryptographic Actor | Who executes | The operational identity of the third party or system that actually invokes cryptographic operations. |
| 3 | Capability | What it can do | The abstract cryptographic function — encrypt, decrypt, sign, verify — decoupled from the material that underpins it. |
| 4 | Cryptographic Asset | With what material | The key or cryptographic material. Protected by the owner's HSM or KMS. Never handed over — only its use is mediated. |
| 5 | Constraint Policy | Under what constraints | The usage rules: time window, maximum invocations, batch scope, rate limits, single use, automatic revocation. |
6.1 Exchange Context
The Exchange Context is the object that traditional cryptographic infrastructure lacks. It represents the relationship itself: the counterparty, the business purpose, the direction of the exchange (inbound, outbound or bidirectional), the sensitivity of the data involved and the regulatory regime that applies. Every other building block is bound to a context. A card network's embossing relationship and a BPO's collections relationship are distinct contexts, each with its own actors, capabilities, assets and constraints, even when the same underlying data is involved.
Making the context explicit is what allows the owner to reason about exchange at the level regulators and auditors expect: not "which keys exist" but "which relationships exist, what each is permitted to do, and what evidence supports it".
6.2 Cryptographic Actor
The Cryptographic Actor is the operational identity that invokes operations: a third party's integration system, a specific service, a workload. It is distinct from the counterparty as an organization. One counterparty may operate several actors; an actor is always bound to an exchange context. Authentication establishes which actor is invoking; authorization is evaluated per actor, per context.
6.3 Capability
A Capability is an abstract cryptographic function, decoupled from the material that implements it. A grant of the "decrypt" capability in a given context does not expose which algorithm, key or key version performs the decryption; those are governed by the owner and may change over time without any change to the grant. This decoupling is what makes sovereign exchange crypto-agile: the owner can migrate the underlying mechanism — including to post-quantum algorithms — while third parties continue to invoke the same capability.
6.4 Cryptographic Asset
The Cryptographic Asset is the key or cryptographic material. It is always protected by the owner's HSM, KMS or Root of Trust and is never handed over; only its use is mediated. An asset may be bound to one or many contexts, but the binding grants use, not possession. Rotation, versioning and retirement of the asset are lifecycle decisions of the owner and are invisible to the actors that invoke capabilities over it.
6.5 Constraint Policy
The Constraint Policy expresses the conditions under which a grant is valid: a time window, a maximum number of invocations, a batch or record scope, a rate limit, business-hours restrictions, single-use semantics, automatic revocation on expiry. Constraints are evaluated at each invocation, in the owner's domain. They are what turn a standing authorization into an operationally bounded one — the difference between "this provider may decrypt" and "this provider may decrypt this batch, once, within the next two hours".
6.6 How the blocks fit together
A single invocation touches all five. An actor, in a context, invokes a capability over an asset, subject to a constraint policy. Authorization succeeds only when every binding is valid; execution occurs within the owner's domain; the record captures all five elements. Together they answer the question that governs sovereign exchange: who can do what, over what material, in what context, under what conditions — with full evidence.
6.7 Rotation and algorithm evolution behind a stable capability
Because the capability is decoupled from the asset, the owner can change the asset as often as its policy requires. A new key every month, a new key per delivery, or a new algorithm every quarter are lifecycle decisions taken in the owner's domain. The third party keeps invoking the same capability through the same integration; it does not need to know, and cannot know, which key or algorithm fulfills each invocation. The owner's applications do not change either, because they also consume the capability rather than a specific mechanism.
This turns key rotation and algorithm transitions across external relationships from bilateral projects into policy decisions, and combined with single-use constraints it bounds the impact of any compromise to the delivery that was authorized, rather than to the history of the relationship.
Prefer the PDF? Download it with your corporate email.
Sovereign Exchange in Practice
The model is best understood through the scenarios it was designed for. Four are drawn from banking, where the concentration of regulated data, third-party processing and cryptographic dependency is highest, and they are chosen to cover the main exchange channels: batch files, record-level processing, API integrations and recurring deliveries over managed file transfer. In every case the existing channel stays in place. A final section shows how the same structure applies across industries.
7.1 Card issuance with multiple embossing providers
A bank issues payment cards through several providers — two international card networks and a local issuer. Each provider must decrypt sensitive cardholder data in order to produce the physical or digital card. In the traditional model, the bank shares a key with each provider, or shares decrypted files. Every provider becomes a holder of the bank's cryptographic authority, and the compromise of any one of them exposes the material for all.
In the sovereign model, the bank defines one Exchange Context per provider, each with its own actor, capability grant and constraints:
| Exchange Context | Cryptographic Actor | Capability and constraints |
|---|---|---|
| Embossing — Network A | network-a-embossing-actor | decrypt · single use · batch #2847 · 2-hour window |
| Embossing — Network B | network-b-embossing-actor | decrypt · single use · batch #AX-9012 · 4-hour window |
| Embossing — Local issuer | local-issuer-actor | decrypt · rate limit 500/hour · daily window |
All keys remain under the bank's control, protected by its HSM. The card-issuance application prepares each batch; each provider invokes the decrypt capability for its own batch, within its own window, through the control plane. What the bank gains:
- Total isolation between providers. Network A never sees Network B's material. If one provider is compromised, the impact is surgical.
- No key exposure. No provider ever receives a key. They only execute capabilities the bank permits.
- Immediate revocation without coordination. If a provider changes or an incident occurs, the cut is instantaneous from the control plane.
- Audit-ready evidence. Every invocation is recorded: which actor, which context, which capability, which constraints.
- Per-provider policies. Each provider has different rules; the model separates them natively without duplicating infrastructure.
- Per-batch operational control. Each batch is authorized individually with its own window and usage limit.
7.2 Collections BPO and outsourced processing
A business process outsourcer operates on behalf of the bank over the data of customers who are behind on their payments. Today, the bank decrypts that list of customers, sends CSV files to the BPO through SFTP, and the BPO operates on cleartext data on its own servers. The bank has no record of which records were opened or when; the cleartext files remain on the BPO's infrastructure; revoking access means redesigning the entire ETL process.
| Today — without sovereign control | With a Cryptographic Control Plane |
|---|---|
| The bank decrypts the list of customers behind on payments. | The bank defines an Exchange Context: BPO — Collections. |
| CSV files are sent to the BPO via SFTP. | The BPO is a controlled Cryptographic Actor. |
| The BPO operates on cleartext data. | Each individual decryption is an invocation. |
| The bank has no record of which records were opened, or when. | Constraints: record by record, business hours only. |
| Cleartext files accumulate on the BPO's servers. | Every operation is recorded in the bank's audit trail. |
| Revocation means changing the entire ETL process. | Revocation is immediate from the console. |
The BPO continues to perform its function, and the SFTP channel can stay in place. What changes is what travels through it: protected information instead of cleartext files. The BPO opens one record at a time through governed capabilities, within the conditions the bank set, and the bank holds the evidence.
7.3 Credit origination with a fintech over an existing API
A bank sends customer data to a partner fintech through a REST API for credit scoring. Sensitive fields (identification, income, account) are protected only by TLS and arrive in cleartext at the fintech's application. If the alliance ends or the fintech suffers an incident, the bank has no way to stop further use of what it sent, and no evidence of which fields were consulted.
In the sovereign model, the API, its contracts and its infrastructure do not change. The bank's application encrypts the sensitive fields inside the JSON payload before sending it. The fintech's service invokes the decrypt capability only when it needs a field to evaluate a request.
Steps 2 and 3 are the exchange as it works today. Steps 1, 4 and 5 are new: fields are protected inside the payload and opened through governed invocation.
| Element | Example setting |
|---|---|
| Exchange Context | Fintech — credit origination |
| Cryptographic Actor | The fintech's scoring service, authenticated with its own workload identity (OIDC) |
| Capability | decrypt over the protected fields of the payload |
| Constraint Policy | Validity window equal to the term of the alliance · per-minute rate limit · usage cap |
| Revocation | Close the context when the alliance ends or on an incident; effective at the next invocation |
The bank decides when and under which conditions the fintech obtains each field in cleartext: only what it needs for the request in progress, within the term of the alliance, with evidence of every decryption. The fintech never holds a bank key, and an alliance that ends loses cryptographic access immediately, without coordinating anything with the fintech.
7.4 Recurring deliveries over an existing managed file transfer platform
A bank sends protected data to a provider twice a month, for instance for payroll, claims or KYC processing. In the traditional model described in section 2.3, a single shared key opens every delivery of the year.
The deliveries keep travelling through the bank's existing managed file transfer platform, on the same schedule and with the same transport encryption. What changes is what travels and who decides when it can be opened.
The managed file transfer platform ensures each delivery arrives. The control plane decides when, under which conditions and how often it can be opened.
In the sovereign model, the bank defines one Exchange Context for the relationship and a policy for the material behind it: a new key every month, and an algorithm reviewed every quarter, moving progressively from classical algorithms to hybrid and post-quantum mechanisms. Each delivery is authorized with a single-use decrypt grant valid for a 48-hour window. Over one year, that policy produces twelve keys and four algorithms, and once the provider's integration invokes the capability, requires no further code changes, neither in the bank's systems nor in the provider's integration. The provider makes the same “decrypt” call all year.
| Policy element | Example setting | Effect |
|---|---|---|
| Key rotation | New key every month (or one per delivery) | A compromised key covers at most one month of deliveries, and with single-use grants, not even that. |
| Algorithm | Reviewed every quarter: RSA, elliptic curve, hybrid, ML-KEM | Algorithm transitions, including post-quantum, happen without bilateral projects. |
| Grant per delivery | decrypt · single use · 48-hour window | Each delivery can be decrypted once; deliveries already processed cannot be decrypted again. |
| Revocation | Withdraw the grant or close the context | Effective at the next invocation, without new keys to distribute or data to re-encrypt. |
The result inverts the accumulation effect. Instead of a relationship whose exposure grows with every delivery, the bank operates one whose exposure is bounded, at any moment, to the delivery currently authorized. If the provider is compromised, there is no key to steal, and deliveries already processed cannot be opened again.
7.5 Beyond banking
The scenarios above are instances of a general pattern: a data owner, a counterparty that must perform cryptographic operations over the owner's data, and a regulatory expectation that the owner remains in control. That pattern recurs across industries, and across channels: the information may travel as files, API payloads, messages or transactions.
| Industry | Sovereign exchange scenarios |
|---|---|
| Financial services | Card issuance · Collections BPO · Recurring outsourced processing · Regulatory reporting · Embedded fintechs · Open banking |
| Government and defense | Inter-agency exchange · Contractors · Binational interoperability · Sovereign signing |
| Healthcare | Shared clinical records · External laboratories · Insurers · Clinical research |
| Telecommunications | Data sharing with partners · Roaming · MVNOs · CDR exchange · IPX interconnection |
| Retail and value chains | EDI with suppliers · Federated loyalty · Outsourced logistics · Marketplaces |
| Software and SaaS | Multi-tenancy · B2B integrations · Data processors · BYOK for enterprise clients |
One conceptual model covers all of them. The building blocks do not change; only the contexts, actors and constraints do.
Chapter 8Regulatory Alignment
Sovereign exchange is not designed around any single regulation. It is designed around the principle those regulations share across jurisdictions: the data owner is responsible for how third parties use its data and must be able to demonstrate control. When that principle is implemented architecturally, alignment with specific frameworks follows.
| Framework | Scope | What sovereign exchange provides |
|---|---|---|
| DORA | Digital Operational Resilience Act · EU | ICT third-party risk management with evidence of controls over every provider that processes protected data. |
| PCI-DSS 4.0 | Card industry · Global | Key custody and segregation; demonstrable control over service providers that handle cardholder data. |
| SOX | Sarbanes-Oxley · USA | Controls over financial systems with full traceability of who accessed protected information and under what authorization. |
| GDPR and national equivalents | Data protection · EU and other jurisdictions (e.g., Colombia's Law 1581) | The controller's responsibility over processors, supported by evidence produced in the controller's own domain. |
| SAMA Circular 482021280 | Saudi Central Bank · Financial institutions in Saudi Arabia | Assessment of cryptographic resilience, constraints, challenges and third-party dependencies for priority cryptographic assets; reduced dependency because counterparties hold no keys. |
| CNSA 2.0 | Post-quantum · USA (NSA) | Transition to quantum-resistant algorithms without renegotiating cryptographic material with each counterparty. |
| CNBV / SFC / BCRA | Banking regulators · Latin America | Continuity, information-security and outsourcing requirements for regulated financial institutions. |
Three aspects deserve emphasis. First, evidence. Most frameworks ask the owner to demonstrate control, not merely to assert it. Evidence generated by the owner's infrastructure for every cryptographic operation — independent of the third party's own reporting — is qualitatively different from contractual attestations. Second, revocability. Frameworks that address third-party risk expect the owner to be able to terminate access when a provider is compromised or a relationship ends. Immediate, unilateral revocation is a structural property of the sovereign model, not a procedure that depends on the counterparty's cooperation. Third, dependency. Supervisors have begun to ask explicitly about third-party dependencies in cryptography. The Saudi Central Bank's circular on quantum computing risks, in force since August 2026, requires financial institutions to identify, for their priority cryptographic assets, the constraints, challenges and dependencies on third parties that affect their cryptographic resilience. An exchange model in which counterparties never hold keys removes a whole class of such dependencies.
Chapter 9Business Value
The value of sovereign exchange reaches three audiences, each with a different concern.
| For the CEO and the board | For the CISO | For the CIO / CTO |
|---|---|---|
| Structural reduction of third-party risk. | Real cryptographic sovereignty, not declarative. | A single control plane for all third parties. |
| Defensive posture against litigation and sanctions. | Reduced attack surface from third parties, bounded to the authorized scope. | Crypto-agility: rotate keys and migrate algorithms without touching applications or counterparties. |
| Enabler of new commercial integrations. | Complete evidence for audits and forensics. | Native post-quantum readiness. |
| Competitive differentiator for regulated clients. | Instant revocation without external coordination or re-encryption. | Standard integration with HSMs and the existing ecosystem. |
9.1 Where the return materializes
The value model of sovereign exchange can be summarized in four indicators.
| Indicator | Measure | Meaning |
|---|---|---|
| −70% | Onboarding time | Time to bring a new third party into the cryptographic ecosystem: an exchange context is defined, not a key exchanged and a pipeline built. |
| 0 | Keys shared | With providers, BPOs or external integrations. Key exposure is eliminated rather than reduced. |
| < 1 minute | Effective revocation | Upon incident, without coordinating with the third party and without re-encrypting data. |
| 100% | Auditable evidence | Of every cryptographic operation, with full context, generated in the owner's domain. |
9.2 Post-quantum readiness as a consequence, not a prerequisite
Sovereign exchange solves a problem that exists today with today's algorithms, and organizations can adopt it before starting, or while running, their post-quantum programs. But because third parties invoke capabilities rather than hold keys, the algorithm and key behind a capability can later change without any change on the third party's side. A post-quantum migration that, in the traditional model, requires bilateral coordination with every counterparty becomes a policy change in the owner's domain. The sovereign exchange model therefore accelerates post-quantum adoption across the organization's external relationships — the part of the migration that is hardest to schedule and coordinate — without rewriting applications or renegotiating cryptographic material.
Chapter 10Adoption Path
Sovereign exchange does not require a wholesale replacement of existing exchange relationships, a post-quantum roadmap, or a complete cryptographic inventory. It starts from a list every organization already has: its third parties. Procurement, risk and security teams know which counterparties receive keys or files today. It is adopted one exchange context at a time, starting where the pain is most acute or the regulatory urgency highest, using the algorithms and key infrastructure already in place, and expanded progressively.
Adoption does not replace the organization's exchange channels either. Managed file transfer, APIs, messaging and integrations stay in place. The owner's application protects information before it is sent, and each third party adapts its integration once to invoke the capability instead of decrypting with a key of its own.
| Stage | Duration | Scope |
|---|---|---|
| 1 · Discovery | 2–4 weeks | Inventory of third-party exchanges (not of the full cryptographic landscape). Identification of the most acute pain case for the pilot: highest risk, most regulatory pressure, or most frequent revocation need. |
| 2 · Pilot | 6–8 weeks | One Exchange Context in production. Typically the highest-risk or most regulatory-urgent case. Keys anchored in the existing HSM; evidence flowing to the owner's audit infrastructure. |
| 3 · Expansion | 3–6 months | Progressive onboarding of remaining third parties. Integration with the existing HSM/KMS and identity provider. Per-context policies replacing per-counterparty key exchanges. |
| 4 · Platform | 6–12 months | The control plane governs all cryptography in exchanges. Key rotation and post-quantum migration enabled by policy across external relationships. |
The adoption path aligns with the modernization program described in the Cryptographic Control Plane whitepaper, but does not depend on it. Third-party exchanges are a natural candidate for the brownfield-critical track: they concentrate regulatory exposure, they are well delimited, and each context migrated removes a shared key or a cleartext transfer from the landscape. They can also be addressed on their own, as the first governed use of a control plane.
Chapter 11ANKASecure© and Sovereign Exchange
The preceding chapters describe an architectural model that can be implemented in more than one way. ANKASecure© is an implementation of the Cryptographic Control Plane that provides governed third-party exchange as a native capability: it replaces long-lived private keys handed to providers with revocable capability grants.
11.1 The five building blocks as first-class objects
In ANKASecure©, Exchange Context, Cryptographic Actor, Capability, Cryptographic Asset and Constraint Policy are first-class objects of the platform, not conventions layered over a key store. An exchange relationship is defined once, as a context that models the counterparty, the key scope and the operational authority granted; actors are enrolled into it; capability grants bind actors to assets under constraint policies; and every invocation is evaluated against those bindings before execution. Revocation acts on the same objects — a grant, an actor or an entire context — and takes effect at the next invocation.
ANKASecure© cryptographic exchange topology for an operating context: exchanges between business applications and counterparties, classified by sensitivity and direction.
The topology view shows what ANKASecure© governs: exchange relationships between the organization's applications and its counterparties, whether those relationships run over files, APIs, messages or regulatory reporting channels. The channel is not the object being governed; the relationship is.
11.2 Capability grants and enforced constraints
Capability grants in ANKASecure© are enforced with four constraints: a time window, a usage cap, a per-minute rate limit and a single-use option. Together they implement scenarios such as “decrypt this delivery, once, within the next 48 hours”.
11.3 Workload identity federation
Counterparties authenticate with their own workload identity, through OIDC tokens issued by their own identity infrastructure. No ANKASecure© credentials are exchanged with the counterparty, which removes another class of shared secrets from the relationship.
11.4 Custody, execution and Roots of Trust
ANKASecure© is not a policy proxy. It provides cryptographic execution and key-lifecycle capabilities directly, while integrating with external HSMs, KMS platforms and PKCS#11 environments for key protection, trust anchoring, or operations that must remain within those infrastructures. Depending on the operation and the trust model, execution may occur within ANKASecure© itself or through the owner's HSM or KMS.
In the sovereign exchange model this means that centralized governance of third-party access does not make ANKASecure© the ultimate Root of Trust. Key material may be generated, managed and used by ANKASecure© while its protection remains anchored to cryptographic infrastructure controlled by the organization. The owner retains the Root of Trust; the control plane performs governed operations on its behalf; the third party never holds either.
11.5 Revocation, evidence and crypto-agility
Revocation is immediate and does not require re-encrypting protected data. Every operation, grant decision and constraint enforcement is recorded in a signed audit trail, with its complete context — actor, context, capability, asset, constraints and outcome — producing evidence that is independent of the counterparty and ready for audit and forensic use.
Because capabilities are decoupled from the material and mechanisms behind them, ANKASecure©'s crypto-agility applies to exchange relationships as it does to internal applications. Keys can be rotated as often as policy requires, and the algorithm and key behind a granted capability can evolve — including toward hybrid and post-quantum mechanisms based on NIST FIPS 203, 204 and 205 — through policy, without any change to the grant or to the third party's integration.
11.6 Three doors, one architectural decision
Organizations arrive at ANKASecure© through one of three concerns. Whichever door they enter, they receive all three capabilities, because all three are properties of the same control plane.
| Enterprise crypto control | Post-quantum readiness | Cryptographic sovereignty |
|---|---|---|
| "How do I govern cryptography enterprise-wide without touching code?" | "How do I migrate to PQC without rebuilding every application?" | "How do I share data with third parties without surrendering my keys?" |
| Governance from a control plane. | PQC by policy, not by engineering. | Mediated capabilities, not shared keys. |
| Also: PQC crypto-agility and sovereign third-party exchange. | Also: enterprise governance and sovereign third-party exchange. | Also: enterprise governance and PQC crypto-agility. |
11.7 Getting started
- Technical discovery session — mapping the organization's critical third-party exchanges and its most pressing pain point.
- Demonstration and reference architecture — ANKASecure© working end to end on a case analogous to the organization's own.
- Scoped pilot plan — a specific Exchange Context for a 6–8 week pilot, with keys anchored in the organization's existing HSM.
Conclusion
Organizations have accepted for decades that sharing data with a third party meant sharing control over it. That acceptance was not a design choice; it was a limitation of the available architecture. A key, once handed over, carried the owner's cryptographic authority with it, and no contract, monitoring regime or rotation schedule could bring that authority back. In recurring relationships, that authority extended to every delivery the third party ever received.
Cryptographic sovereignty removes the limitation. Keys never leave the owner's control domain. Third parties are authorized to invoke capabilities — specific functions, over specific material, in a specific exchange context, under explicit constraints — and every invocation is executed and recorded within the owner's domain. Control does not end at the moment of sharing; it is exercised at every decryption.
None of this requires replacing how information moves. Files, API payloads, messages and transactions keep travelling through the channels the organization already operates; the control plane governs the cryptographic access to what travels through them.
The shift from sharing keys to sharing capabilities requires a Cryptographic Control Plane: a layer that governs, rather than stores or transports. With it, the owner gains sovereign custody, mediated use, policy-based governance and cryptographic evidence over every external relationship — and, as a consequence of the same architecture, the ability to rotate keys and evolve the cryptography behind those relationships, including toward post-quantum mechanisms, without renegotiating anything with anyone.
None of this needs to wait for a post-quantum program. The exposure exists today, with today's algorithms, and so does the solution.
The five building blocks — Exchange Context, Cryptographic Actor, Capability, Cryptographic Asset and Constraint Policy — give organizations a vocabulary for governing third-party exchange at the level regulators, auditors and boards now expect. ANKASecure© implements that vocabulary as a Cryptographic Control Plane. The architectural decision is the same whether an organization arrives through enterprise cryptographic control, post-quantum readiness or sovereignty over its third-party exchanges: cryptography governed as infrastructure, with the Root of Trust where the organization requires it.