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
tenantIdclaims, 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:
- The Cryptographic Control Plane
- The CAPA framework
- The Cryptographic Maturity Model
- Deployment Organization Model
- Reference scenarios
For CISOs and security leaders focused on third-party risk
Start with sovereignty, then the broader governance model:
- Cryptographic sovereignty
- Pillar 2 — Cryptographic Sovereignty
- Reference scenarios — particularly card issuance and BPO
- Multi-Tenant Isolation Model
- Envelope Encryption Pattern — where key material actually sits
For PQC migration leads
Start with maturity context, move to the framework, then the technical primitives:
- The Cryptographic Maturity Model
- Pillar 1 — Crypto-Agility
- Pillar 3 — Frictionless Modernization
- Policy-Driven Crypto-Agility
- Hybrid vs Composite Keys
- Composite Algorithm Catalog
- Migration Overview
For Solution Architects designing an integration
Go directly to the organizing model, then to what the platform guarantees:
- Deployment Organization Model
- Entity Reference
- Reference Scenarios
- Multi-Tenant Isolation Model
- Key Identifier (KID) System
- Interoperability & Standards
For Developers integrating with the platform
Start with the SDK and CLI, then learn the operational primitives:
- SDK Overview
- SDK Quick Start Examples
- Crypto CLI
- Developer Hub — the operation-by-operation API reference
- File Operation Patterns — streaming and large payloads
- SDK Flow 18 — composite keys
- Error Reference — what each failure means
For Compliance and audit functions
Start with regulatory alignment and the algorithm evidence:
- Pillar 4 — Cryptographic Governance & Compliance
- Regulatory Compliance Matrix
- Policy Enforcement Guide
- 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.