Skip to content

Platform overview

Audience: anyone arriving at the ANKASecure© documentation for the first time.

Reading time: 10 minutes for orientation; deeper reading paths follow.

What this page does: orients the reader, shows the architectural shape of the platform at a glance, and points to the canonical pages that cover each topic in depth. It is intentionally short — the detailed treatment lives in dedicated pages, kept up to date where work actually happens.


What ANKASecure© is

ANKASecure© is a Cryptographic Control Plane — an architectural layer that governs cryptographic behavior across enterprise systems and inter-organization data exchanges. The platform decouples cryptographic operations from the applications that consume them, exposing them as governed, controlled, and auditable capabilities.

The platform addresses three concerns that converge on the same architectural shift:

Concern What the buyer wants What ANKASecure© provides
🎯 Enterprise crypto control Govern cryptography across many systems without rewriting applications A control plane that abstracts algorithm selection from application code
⚛️ Post-quantum readiness Migrate to PQC without rebuilding every application Algorithm transition by policy update, hybrid coexistence, streaming re-encryption
🛡️ Cryptographic sovereignty Share data with third parties without surrendering keys Mediated capability invocation; keys never leave the data owner's domain

Every buyer entering through one door receives the capabilities the other two doors describe — because all three are facets of the same architectural object.

For the conceptual treatment, see The Cryptographic Control Plane and the CAPA framework, which develops the same three concerns as five pillars.


Architecture at a glance

flowchart TB
    subgraph CLIENT["🧩 Client layer"]
        SDK["Java SDK"]
        CLI["CLIs<br/>(Crypto, Platform, Tenant)"]
        APPS["Custom applications<br/>(REST API)"]
    end

    subgraph EDGE["🌐 Edge layer"]
        NGINX["Edge NGINX<br/>SSL termination · subdomain routing · rate limiting"]
    end

    subgraph SERVICES["🏛️ Microservices"]
        CORE["Core API<br/>cryptographic operations"]
        ADMIN["Admin API<br/>tenant / user / policy"]
        AUTH["Auth API<br/>JWT issuance"]
        PQC["PQC Handshake<br/>quantum-safe key exchange"]
        AUDIT["Audit API<br/>audit trail queries"]
        EVENTS["Event Processor<br/>Kafka routing"]
        LIC["License Server"]
        DOCS["Doc Aggregator"]
        CONSOLE["Admin Console<br/>(React SPA)"]
    end

    subgraph INFRA["⚙️ Infrastructure"]
        PG["PostgreSQL"]
        REDIS["Redis / Valkey"]
        KAFKA["Apache Kafka"]
        OS["OpenSearch"]
    end

    subgraph SEC["🔐 Cryptographic substrate"]
        HSM["HSM<br/>(PKCS#11, multi-vendor)"]
        POLICIES["Policy engine<br/>(hierarchical, real-time sync)"]
    end

    SDK --> NGINX
    CLI --> NGINX
    APPS --> NGINX

    NGINX --> CORE
    NGINX --> ADMIN
    NGINX --> AUTH
    NGINX --> PQC
    NGINX --> AUDIT
    NGINX --> CONSOLE

    CORE --> HSM
    CORE --> POLICIES
    CORE --> PG
    CORE --> REDIS
    ADMIN --> PG
    ADMIN --> POLICIES
    AUTH --> PG
    AUTH --> REDIS

    SERVICES --> KAFKA
    SERVICES --> OS

    style NGINX fill:#fdebd0,stroke:#d68910,stroke-width:2px
    style CORE fill:#85c1e9,stroke:#1a5276,stroke-width:3px
    style HSM fill:#d5f5e3,stroke:#1e8449,stroke-width:2px
    style POLICIES fill:#fadbd8,stroke:#c0392b,stroke-width:2px

Architecture principles:

  • Stateless services — all state in PostgreSQL (persistent) or Redis (ephemeral); enables horizontal scaling
  • Encrypted communication — TLS 1.3 client → edge, mTLS service-to-service, optional PQC transport on top
  • Multi-tenant isolation — per-tenant keystores, JWT tenantId claims, namespaced caches, encrypted overlay networks per environment
  • Secrets management — Docker Swarm secrets, stdin-injected, encrypted at rest in Raft, mounted via the ConfigTree pattern
  • Integrity over availability — multi-level caches with a disk fallback for policy reads; the authorization projections and the key-encryption-key label are signed by the administration service alone and verified with its public keys, and an operation is refused rather than served under an unverifiable or missing value

For the reasoning behind this shape — why cryptography is a governed plane rather than a library each application links — see The Cryptographic Control Plane.


Components at a glance

Microservices

Service Purpose
Core API Cryptographic operations, key management
Admin API Tenant, user, application, policy management
Auth API Authentication and JWT issuance
PQC Handshake API Quantum-resistant key exchange
Audit API Unified audit trail queries
License Server License validation and usage reporting
Doc Aggregator OpenAPI documentation hub
Event Processor Event routing and the audit pipeline

You do not address these services individually. A client — the SDK, a CLI, or your own HTTP code — talks to the edge, and the edge routes. The contract you actually program against is the one published in the OpenAPI specifications and documented operation by operation on the Developer Hub.

Frontend

The Admin Console is a React single-page application. It is where a tenant administrator manages keys, policies, applications and credentials, and it is the only place that knows which environment you signed in to — so it is also where you read the base URL and the credentials your integration will use.

Client tooling

Tool Reference
Java SDK SDK Overview
Crypto CLI Crypto CLI
Key Management CLI Key management of one tenant from the command line

Infrastructure layer

Layer Used for
PostgreSQL Tenant, user and key metadata; audit data
Redis / Valkey Sessions, caches, KEK metadata
Kafka Event streaming, audit pipeline
OpenSearch Log aggregation and search
HSM (PKCS#11) Cryptographic material custody

None of this is yours to run when you integrate with an existing deployment. It matters for one reason: it is why key material never leaves the custody boundary, and why an audit record exists for every operation you perform.


Reading paths by role

Documentation is organized by topic, not by reader. The right path depends on what you need.

For Enterprise Architects and CIOs/CTOs

Start with the conceptual narrative, then the governance model, then the organizing model:

  1. The Cryptographic Control Plane
  2. The CAPA framework
  3. The Cryptographic Maturity Model
  4. Deployment Organization Model
  5. Reference scenarios

For CISOs and security leaders focused on third-party risk

Start with sovereignty, then the broader governance model:

  1. Cryptographic sovereignty
  2. Pillar 2 — Cryptographic Sovereignty
  3. Reference scenarios — particularly card issuance and BPO
  4. Multi-Tenant Isolation Model
  5. Envelope Encryption Pattern — where key material actually sits

For PQC migration leads

Start with maturity context, move to the framework, then the technical primitives:

  1. The Cryptographic Maturity Model
  2. Pillar 1 — Crypto-Agility
  3. Pillar 3 — Frictionless Modernization
  4. Policy-Driven Crypto-Agility
  5. Hybrid vs Composite Keys
  6. Composite Algorithm Catalog
  7. Migration Overview

For Solution Architects designing an integration

Go directly to the organizing model, then to what the platform guarantees:

  1. Deployment Organization Model
  2. Entity Reference
  3. Reference Scenarios
  4. Multi-Tenant Isolation Model
  5. Key Identifier (KID) System
  6. Interoperability & Standards

For Developers integrating with the platform

Start with the SDK and CLI, then learn the operational primitives:

  1. SDK Overview
  2. SDK Quick Start Examples
  3. Crypto CLI
  4. Developer Hub — the operation-by-operation API reference
  5. File Operation Patterns — streaming and large payloads
  6. SDK Flow 18 — composite keys
  7. Error Reference — what each failure means

For Compliance and audit functions

Start with regulatory alignment and the algorithm evidence:

  1. Pillar 4 — Cryptographic Governance & Compliance
  2. Regulatory Compliance Matrix
  3. Policy Enforcement Guide
  4. Algorithm Reference

Installing and operating a deployment

Installation, environment lifecycle, monitoring and backup are not covered on this site. They belong to the operations documentation that accompanies a licensed deployment, because the procedures depend on the deployment model that was chosen. If you are integrating with a deployment somebody else runs, everything you need is here.


Common questions

For frequently asked questions across architecture, capabilities, lifecycle, HSM, compliance, performance, deployment, migration, integration, and policy, see Frequently asked questions.


Where to go from here

Goal Next step
Learn the vocabulary Key Concepts
Browse foundational concepts Foundational Concepts
Decide how to organise deployments and tenants Deployment Organization Model
Write your first call SDK Quick Start or the Developer Hub
Generate a client from the contract OpenAPI specifications
Move existing material onto the platform Migration Overview
Understand a failure you just got Error Reference
Look up a specific question Frequently asked questions

Document status: ACTIVE — this page is a slim landing that orients the reader and links to canonical sources. Detailed content lives in the topic-specific pages referenced above.