Cryptographic sovereignty

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

Reading time: 22 minutes

Prerequisites: Three doors, one solution recommended; The Cryptographic Control Plane for architectural context

The core thesis

Cryptographic keys must never leave the data owner's control domain.

Third parties and internal systems do not own keys. They are authorized to invoke cryptographic capabilities under strict, mediated, and auditable governance.

The principle of cryptographic sovereignty rests on three pillars:

This page describes the principle, the structural problem it addresses, the paradigm shift it represents, and the cross-industry scenarios it solves.

The forces dismantling the traditional model

Four structural forces are dismantling the traditional model for third-party data exchange.

quadrantChart
    title Forces disrupting third-party data exchange
    x-axis Low complexity --> High complexity
    y-axis Low urgency --> High urgency
    quadrant-1 Critical
    quadrant-2 Monitor
    quadrant-3 Emerging
    quadrant-4 Accelerating
    Hyperconnected ecosystems: [0.75, 0.80]
    Growing regulatory pressure: [0.65, 0.90]
    Supply chain risk: [0.85, 0.85]
    Quantum computing horizon: [0.70, 0.60]

Hyperconnected ecosystems. Every enterprise today exchanges sensitive data with dozens or hundreds of third parties: suppliers, BPOs, fintechs, agencies, specialized vendors. The attack surface has multiplied.

Growing regulatory pressure. DORA, PCI-DSS 4.0, GDPR, SOX, data residency laws. The ultimate accountable party is always the data owner — not the third party.

Supply chain risk. The most costly breaches of recent years did not occur at the victim companies, but at their third parties. The perimeter no longer belongs to the enterprise.

Quantum computing on the horizon. Migrating to post-quantum cryptography is not optional. Doing it while maintaining control over multiple third parties multiplies operational complexity by an order of magnitude.

The structural problem: loss of control upon sharing

Under the traditional model, sharing data with a third party means losing control of it.

flowchart LR
    A["🏢 Your organization<br/>(data owner)"] -->|"key delivery /<br/>cleartext data"| B["🤝 Third party<br/>(full control over your data)"]

    B --> C["❌ No visibility into when<br/>or how data is used"]
    B --> D["❌ Cannot revoke access<br/>in real time"]
    B --> E["❌ No auditable evidence<br/>of usage"]
    B --> F["❌ Key lives outside<br/>your domain"]

    style A fill:#d6eaf8,stroke:#1a5276,stroke-width:2px
    style B fill:#fadbd8,stroke:#c0392b,stroke-width:2px
    style C fill:#fef9e7,stroke:#c0392b
    style D fill:#fef9e7,stroke:#c0392b
    style E fill:#fef9e7,stroke:#c0392b
    style F fill:#fef9e7,stroke:#c0392b

Once the key (or cleartext data) leaves the owner's domain, the following become impossible without bilateral coordination with the third party:

• Real-time revocation of access
• Knowing the exact scope of data consumption
• Producing forensic evidence of individual operations
• Limiting use to specific batches, time windows, or operation counts

The risk is structural. Even diligent third parties, following agreements scrupulously, cannot give the data owner what the architecture itself does not provide.

Consequences of losing cryptographic sovereignty

The risks span operational, regulatory, and strategic dimensions.

mindmap
  root((Loss of<br/>cryptographic<br/>sovereignty))
    Operational risk
      Third-party breach = your breach
      Irreversible sensitive data leakage
      Inability to cut access immediately
      Uncontrolled key duplication
    Regulatory risk
      SOX and PCI audit findings
      DORA non-compliance penalties
      Shared GDPR controller liability
      Exposure to civil litigation
    Strategic risk
      Operational dependency on the third party
      High cost of provider switching
      Barrier to new integrations
      Loss of market trust

The accountability problem. Regulatory frameworks make the data owner accountable for what third parties do with their data. The legal responsibility cannot be delegated. Yet the traditional architectural model — sharing keys — places control with the third party. The mismatch between accountability and control is the root of the risk.

The paradigm shift: from sharing keys to sharing capabilities

ANKASecure© introduces a fundamental inversion of the control model.

flowchart TB
    subgraph TRADITIONAL["❌ Traditional model — sharing a key"]
        direction LR
        T1["Data owner"] -->|"delivers key"| T2["Third party"]
        T2 --> T3["Possesses cryptographic material"]
        T2 --> T4["Uses it whenever and<br/>however they want"]
        T2 --> T5["Revocation requires<br/>bilateral coordination"]
        T2 --> T6["Audit depends on<br/>what the third party reports"]
    end

    subgraph ANKASECURE["✅ ANKASecure© model — sharing a capability"]
        direction LR
        A1["Data owner"] -->|"grants capability"| A2["Control Plane"]
        A2 -->|"mediated invocation"| A3["Third party"]
        A3 --> A4["Only what was authorized,<br/>when it was authorized"]
        A2 --> A5["Immediate revocation<br/>without depending on the third party"]
        A2 --> A6["Every execution logged<br/>in owner's domain"]
    end

    TRADITIONAL -.->|"paradigm shift"| ANKASECURE

    style TRADITIONAL fill:#fadbd8,stroke:#c0392b,stroke-width:2px
    style ANKASECURE fill:#d5f5e3,stroke:#1e8449,stroke-width:2px

The solution: ANKASecure© as a Cryptographic Control Plane

ANKASecure© is the control plane that governs how cryptography is used across systems and organizations — without ever exposing the keys that underpin it.

flowchart TB
    subgraph OWNER["Owner's control domain"]
        HSM["🔑 HSM<br/>Keys always here.<br/>Never leave."]
        POL["📋 Policies"]
        AUD["📊 Audit + Revocation"]
    end

    subgraph CCP["ANKASecure© — Cryptographic Control Plane"]
        AUTH["Authentication"]
        AUTHZ["Authorization"]
        REST["Restrictions"]
        MED["Mediation"]
        EV["Evidence"]
    end

    OWNER <--> CCP

    CCP -->|"invokes capability"| P1["🏦 Provider A<br/>e.g. VISA"]
    CCP -->|"invokes capability"| P2["💳 Provider B<br/>e.g. AMEX"]
    CCP -->|"invokes capability"| P3["🏭 BPO / Vendor<br/>e.g. embossing"]

    style OWNER fill:#d6eaf8,stroke:#1a5276,stroke-width:2px
    style CCP fill:#85c1e9,stroke:#1a5276,stroke-width:3px
    style P1 fill:#fdebd0,stroke:#d68910
    style P2 fill:#fdebd0,stroke:#d68910
    style P3 fill:#fdebd0,stroke:#d68910

Four foundational capabilities

For the broader architectural treatment of the control plane, see The Cryptographic Control Plane.

How it works

The key never moves. The capability does — governed, restricted, and audited.

sequenceDiagram
    participant TP as Third party / System
    participant CCP as ANKASecure©<br/>Control Plane
    participant POL as Policy engine
    participant HSM as HSM<br/>(Owner's domain)
    participant AUD as Audit log

    TP->>CCP: Invocation request (capability, context, actor)
    CCP->>POL: Evaluate policy for this actor + context
    POL-->>CCP: Decision: Permit / Deny (with constraints)

    alt Permitted
        CCP->>HSM: Execute cryptographic operation
        HSM-->>CCP: Result (never the raw key)
        CCP->>AUD: Log: actor, context, capability, restrictions, timestamp
        CCP-->>TP: Response (result only)
    else Denied or restricted
        CCP->>AUD: Log: denied invocation with reason
        CCP-->>TP: Rejection with policy code
    end

Critical invariant: The HSM never exposes raw key material to the Control Plane, to the third party, or to any external system. Operations are executed inside the HSM boundary; only the cryptographic result is returned.

The conceptual model behind sovereign exchange

ANKASecure© materializes sovereign control through five conceptual blocks. These map directly to entities in the deployment organization model.

flowchart LR
    EC["1️⃣ Exchange Context<br/>The exchange relationship<br/><br/>Models the third-party exchange:<br/>with whom, for what purpose,<br/>in which direction, with what sensitivity"]
    CA["2️⃣ Cryptographic Actor<br/>Who executes<br/><br/>The operational identity of the<br/>third party or system that actually<br/>invokes cryptographic operations"]
    CAP["3️⃣ Capability<br/>What they can do<br/><br/>The abstract cryptographic function<br/>— encrypt, sign, verify — decoupled<br/>from the material that underpins it"]
    CAS["4️⃣ Cryptographic Asset<br/>With which material<br/><br/>The key or cryptographic material.<br/>Lives in the owner's HSM.<br/>Never delivered — only mediated"]
    CP["5️⃣ Constraint Policy<br/>Under which restrictions<br/><br/>Usage rules: time window, max<br/>invocations, batch scope,<br/>automatic revocation"]

    EC --> CA --> CAP --> CAS --> CP

    style EC fill:#d6eaf8,stroke:#1a5276,stroke-width:2px
    style CA fill:#d5f5e3,stroke:#1e8449,stroke-width:2px
    style CAP fill:#fdebd0,stroke:#d68910,stroke-width:2px
    style CAS fill:#e8daef,stroke:#7d3c98,stroke-width:2px
    style CP fill:#fadbd8,stroke:#c0392b,stroke-width:2px

Together, these five blocks answer a single compound question:

Who can do what, on which material, in which context, under which conditions — with complete evidence.

The composition

erDiagram
    EXCHANGE_CONTEXT ||--o{ CRYPTOGRAPHIC_ACTOR : "authorizes"
    EXCHANGE_CONTEXT ||--o{ CAPABILITY : "permits"
    CAPABILITY ||--|| CRYPTOGRAPHIC_ASSET : "operates on"
    EXCHANGE_CONTEXT ||--o{ CONSTRAINT_POLICY : "governed by"
    CRYPTOGRAPHIC_ACTOR ||--o{ CONSTRAINT_POLICY : "subject to"

    EXCHANGE_CONTEXT {
        string id
        string name
        string counterparty
        string purpose
        string data_direction
        string sensitivity_level
    }
    CRYPTOGRAPHIC_ACTOR {
        string id
        string identity
        string actor_type
        string authentication_method
    }
    CAPABILITY {
        string id
        string function_type
        string algorithm_family
        string operation
    }
    CRYPTOGRAPHIC_ASSET {
        string id
        string asset_type
        string hsm_slot_ref
        string key_family
    }
    CONSTRAINT_POLICY {
        string id
        datetime valid_from
        datetime valid_until
        int max_invocations
        string batch_scope
        bool auto_revoke_on_breach
    }

The full treatment — including the additional entities (Deployment, Tenant, Application, Credential, Capability Grant, Policy, Audit Event) that round out the twelve-entity model — is in the deployment organization model.

Banking scenario: card issuance with multiple embossing providers

A bank issues cards through VISA, AMEX, and a local provider. Each must decrypt sensitive cardholder data to produce the physical card. Sharing keys multiplies risk.

flowchart TB
    BANK["🏦 Bank<br/>Card Issuance Application<br/><br/>🔑 All keys here — always"]

    BANK --> CCP

    subgraph CCP["ANKASecure© Control Plane"]
        EC1["Exchange Context: Embossing-VISA<br/>decrypt · single-use · batch #2847 · 2h window"]
        EC2["Exchange Context: Embossing-AMEX<br/>decrypt · single-use · batch #AX-9012 · 4h window"]
        EC3["Exchange Context: Embossing-Local<br/>decrypt · rate-limit 500/h · daily window"]
    end

    EC1 --> VISA["💳 VISA<br/>visa-embossing-actor"]
    EC2 --> AMEX["💳 AMEX<br/>amex-embossing-actor"]
    EC3 --> LOCAL["🏷️ Local issuer<br/>local-issuer-actor"]

    style BANK fill:#d6eaf8,stroke:#1a5276,stroke-width:2px
    style CCP fill:#85c1e9,stroke:#1a5276,stroke-width:3px
    style VISA fill:#fdebd0,stroke:#d68910
    style AMEX fill:#fdebd0,stroke:#d68910
    style LOCAL fill:#fdebd0,stroke:#d68910

Outcomes for the bank

The fully modeled scenario — entities, attributes, capability grants, constraints — is in Reference scenarios.

Banking scenario: BPO collections and outsourced processing

A BPO operates on behalf of the bank over delinquent customer data. Today, it receives decrypted CSV files. With ANKASecure©, it operates on controlled capabilities — never receiving bulk cleartext.

flowchart LR
    subgraph TODAY["❌ Today — without sovereign control"]
        direction TB
        S1["Bank decrypts the portfolio"]
        S2["Sends CSV files to BPO via SFTP"]
        S3["BPO operates on cleartext data"]
        S4["Bank has no visibility into BPO's data use"]
        S5["Files remain on BPO servers"]
        S6["Revoke = rewrite entire ETL process"]
        S1 --> S2 --> S3 --> S4 --> S5 --> S6
    end

    subgraph ANKA["✅ With ANKASecure©"]
        direction TB
        A1["Bank defines Exchange Context: BPO-Collections"]
        A2["BPO is a controlled Cryptographic Actor"]
        A3["Each individual decryption is an invocation"]
        A4["Restrictions: record-by-record, business hours only"]
        A5["Every operation logged in bank's audit domain"]
        A6["Revocation: immediate from the console"]
        A1 --> A2 --> A3 --> A4 --> A5 --> A6
    end

    style TODAY fill:#fadbd8,stroke:#c0392b,stroke-width:2px
    style ANKA fill:#d5f5e3,stroke:#1e8449,stroke-width:2px

The full modeling — actors, contexts, grants, constraints — is in Reference scenarios.

Beyond banking: cross-industry applicability

The same conceptual model solves sovereign control scenarios across multiple industries.

mindmap
  root((ANKASecure©<br/>Cryptographic<br/>Control Plane))
    Financial services
      Card issuance
      BPO collections
      Regulatory reporting
      Embedded fintechs
      Open banking
    Government & defense
      Inter-agency exchange
      Contractors
      Binational interoperability
      Sovereign signing
    Healthcare
      Shared clinical records
      External laboratories
      Insurers
      Clinical research
    Telecommunications
      Partner data sharing
      Roaming
      MVNOs
      CDR exchange
      IPX interconnection
    Retail & value chains
      EDI with suppliers
      Federated loyalty
      Outsourced logistics
      Marketplaces
    Software & SaaS
      Multi-tenancy
      B2B integrations
      Data processors
      Enterprise BYOK

One conceptual model. One product. Dozens of regulated scenarios where the data owner must retain control.

Business benefits by stakeholder

flowchart TB
    subgraph CEO["👔 For the CEO / Board"]
        C1["Structural reduction of third-party risk"]
        C2["Defensive posture against litigation and penalties"]
        C3["Enabler for new commercial integrations"]
        C4["Competitive differentiator with regulated clients"]
    end

    subgraph CISO["🛡️ For the CISO"]
        CI1["Real cryptographic sovereignty — not declarative"]
        CI2["Reduced attack surface from third parties"]
        CI3["Complete evidence for audits and forensics"]
        CI4["Instant revocation without external coordination"]
    end

    subgraph CTO["⚙️ For the CIO / CTO"]
        CT1["Single control plane for all third parties"]
        CT2["Crypto-agility: migrate algorithms without touching apps"]
        CT3["Native post-quantum readiness"]
        CT4["Standard integration with HSMs and existing ecosystem"]
    end

Quantifiable value

Additionally, the model accelerates post-quantum cryptography adoption without rewriting applications — a migration that without a control plane takes years.

Regulatory compliance alignment

ANKASecure© is natively aligned with the regulatory frameworks that matter most to regulated industries.

flowchart LR
    CCP["ANKASecure©<br/>Cryptographic<br/>Control Plane"]

    CCP --> DORA["📜 DORA<br/>Digital Operational<br/>Resilience Act · EU<br/><br/>Third-party ICT risk management<br/>with evidence of controls"]
    CCP --> PCI["📜 PCI-DSS 4.0<br/>Card industry · Global<br/><br/>Key custody and segregation;<br/>control over service providers"]
    CCP --> SOX["📜 SOX<br/>Sarbanes-Oxley · USA<br/><br/>Controls over financial systems<br/>with complete traceability"]
    CCP --> GDPR["📜 GDPR<br/>Data protection · EU<br/><br/>Controller accountability<br/>over processors"]
    CCP --> CNSA["📜 CNSA 2.0<br/>Post-quantum · USA NSA<br/><br/>Transition to quantum-resistant<br/>algorithms"]

For the regulatory dimension as a CAPA pillar, see Pillar 5 — Regulatory Compliance.

Where to read next

Summary

Cryptographic sovereignty means the data owner retains exclusive custody of cryptographic key material. Third parties never receive keys — they receive the right to invoke capabilities, mediated and audited.

This principle inverts the traditional model of third-party data exchange. The shift from sharing keys to sharing capabilities is what makes governed cross-organization cryptography possible.

The same model that supports internal cryptographic governance, cross-jurisdiction operations, and post-quantum migration also supports sovereign third-party exchange — because all three are facets of the same architectural shift.