Frequently asked questions

Audience: anyone evaluating, integrating with, or operating ANKASecure©.

How to use this page: browse by category or search the page (Ctrl+F). Each answer points to the canonical documentation for deeper detail.

Categories

1. Platform and architecture essentials
2. Cryptographic capabilities
3. Key management and lifecycle
4. HSM integration
5. Compliance and regulatory
6. Performance and scalability
7. Deployment and operations
8. Migration and interoperability
9. SDK, CLI, and integration
10. Policy engine

1. Platform and architecture essentials

What is ANKASecure© and how does it differ from AWS KMS or Azure Key Vault?

ANKASecure© is a complete post-quantum cryptography platform — microservices, SDKs, CLIs, and admin tooling — versus AWS KMS / Azure Key Vault which are key management services.

Key differences:

• Composite hybrid keys — production-ready AND-decrypt (AWS/Azure roadmap only)
• Regional algorithms — China (GMT), Russia (GOST), South Korea (KISA), Japan (CRYPTREC)
• Deployment — on-premise option (AWS/Azure cloud-only)
• APIs — standards-based (RFC 7516/7515) versus proprietary
• Streaming — unlimited file sizes (vs API-imposed size limits)

Use ANKASecure© for: PQC migration today (not roadmap), regional market access, on-premise requirements, avoiding vendor lock-in.

How many algorithms does ANKASecure© support and what standards does it cover?

Comprehensive algorithm catalog covering simple primitives and composite hybrid combinations across PQC KEMs, PQC signatures, classical PKI, symmetric AEAD, and MAC families. Standards coverage spans the major international and national bodies: NIST, ISO/IEC, IETF, ENISA, BSI, ANSSI, ETSI, CRYPTREC, GMT, KISA, MySEAL, NSA, GOST, NCA-NCS.

The complete current catalog is queryable at runtime via GET /api/key-management/supported-algorithms and documented in Algorithm Reference.

What is crypto-agility and why does it matter?

Crypto-agility is the ability to change cryptographic algorithms without modifying application code.

How it works: applications reference key identifiers (KID) like production-key-001, while the platform resolves the actual algorithm (RSA-2048, ML-KEM-768, etc.) via configuration.

Benefits:

• Immediate response to vulnerabilities — algorithm change is a policy update, not a coordinated engineering effort
• Frictionless modernization — algorithm upgrades absorb into routine operations
• Single source of truth — uniform cryptographic posture across the enterprise vs divergent per-team implementations
• Continuous regulatory alignment — adapt to evolving mandates without redesign

For the deeper treatment, see Pillar 1 — Crypto-Agility and Policy-Driven Crypto-Agility.

Can you explain the high-level architecture in simple terms?

ANKASecure© uses a microservices architecture with eight Spring Boot microservices, the React-based Admin Console, and a shared infrastructure layer:

All services communicate via encrypted overlay networks; state is external (PostgreSQL / Redis), enabling horizontal scaling.

For full detail, see Component Architecture and Platform Architecture.

Is ANKASecure© a library, a service, or something else?

ANKASecure© is a complete platform.

Deployment modes: SaaS (ANKATech-managed), Enterprise on-premise (full customer control, air-gapped supported), Hybrid (data on-premise, management in cloud).

Unlike libraries (OpenSSL, Bouncy Castle): ANKASecure© provides turnkey infrastructure. Unlike cloud services (AWS KMS): on-premise option and standards-based APIs (no vendor lock-in).

What are the five pillars and why do they matter?

The CAPA framework (Crypto Agility Posture Architecture) defines five foundational pillars:

1. Crypto-Agility — change algorithms without code changes
2. Cryptographic Sovereignty — complete key lifecycle and policy control; keys never leave the data owner's domain
3. Frictionless Modernization — introduce new mechanisms without disrupting existing systems
4. Policy-Driven Governance — centralized policies enforced at runtime
5. Regulatory Compliance — alignment with evolving regulatory frameworks

Together they enable the operation of a Cryptographic Control Plane capable of supporting continuous cryptographic evolution. See The CAPA framework for the dedicated treatment.

2. Cryptographic capabilities

What is streaming encryption and what are the limits?

Streaming encryption processes files in 8 KB chunks with constant memory regardless of file size — tested with multi-TB files.

Key characteristics:

• Endpoints — POST /api/crypto/stream/encrypt, /api/crypto/stream/decrypt
• Memory — constant; no file-size limit
• Format — detached JWE (General-JSON header < 1 KB plus binary ciphertext, no Base64 expansion)
• Throughput — network/disk-bound

Streaming versus compact:

For full detail, see Streaming Operations.

How does re-encryption work without exposing plaintext?

Re-encryption uses a streaming algorithm that never exposes the full plaintext:

while (chunk = read(8KB)) {
    plaintext_chunk = decrypt(chunk, oldKid);
    ciphertext_chunk = encrypt(plaintext_chunk, newKid);
    write(ciphertext_chunk);
    zeroize(plaintext_chunk);
}

Security characteristics:

• Ephemeral plaintext — 8 KB chunks only, very short lifespan
• Immediate zeroization — Arrays.fill(0) after each chunk encryption
• Never persisted — not written to disk, logged, or transmitted

Benefits:

• Reduced attack surface compared to traditional decrypt-to-temp-file workflows
• Unlimited file sizes (tested multi-TB)
• Zero-downtime — background re-encryption while applications remain operational

See Streaming Operations and Crypto Lifecycle.

What are composite / hybrid keys and when should I use them?

Composite keys combine classical (X25519, P-256/384/521) with post-quantum (ML-KEM, ML-DSA) algorithms.

Two modes:

• COMPOSITE_KEM_COMBINE (encryption) — AND-decrypt requires BOTH secrets, providing significantly stronger security than OR-decrypt
• COMPOSITE_SIGNATURE (signatures) — dual verification (classical and PQC must both verify)

When to use:

• Federal contracts (GSA PQC mandate)
• Long-term data (financial transactions, medical records, 10–20+ year retention)
• Critical infrastructure
• Defense-in-depth security

When not to use:

• Performance-critical streaming (composite has overhead vs simple keys)
• Short-lived data (session tokens, temporary credentials)
• Non-compliance scenarios where simple keys are sufficient

Compliance: NIST CSWP 39 §3.2.4, GSA PQC §6.3, FIPS 186-5, NSA CNSA 2.0.

For deeper treatment: Composite Hybrid Keys Architecture, Hybrid vs Composite Keys, and Composite Hybrid Keys API.

Are ANKASecure©'s formats JOSE-compliant and interoperable?

Compliance varies by key type:

Interoperability:

• ANKASecure© ↔ ANKASecure© — full
• ANKASecure© → standard JOSE library — parse-only (cannot decrypt composite without SDK)
• Standard → ANKASecure© — full

Mitigation strategies for interop with non-ANKASecure© systems: provide the SDK to partners, export individual components as standard JWKs via the migration API, or use custom unprotected-header fields (anka_*) that are ignored by standard libraries while providing self-documenting compliance metadata.

For more on interoperability patterns, see Interoperability & Standards and JOSE Technical Reference.

What AEAD and integrity guarantees does ANKASecure© provide?

All encryption uses AEAD (Authenticated Encryption with Associated Data): AES-256-GCM with a 16-byte authentication tag.

AAD binding includes:

• tenantId — prevents cross-tenant attacks
• kid — prevents key swapping
• algorithm — prevents algorithm confusion
• keyOps — enforces usage policy
• createdAt — replay attack detection

Integrity guarantees: any ciphertext modification fails tag validation and aborts decryption; different tenantId produces tag mismatch; NIST SP 800-38D wire format is followed.

For composite keys, each component is independently wrapped with unique AAD, preventing component-level attacks.

Can I query the available algorithms dynamically?

Yes. GET /api/key-management/supported-algorithms returns the full catalog with metadata: kty, alg, keyOps, status (RECOMMENDED / LEGACY), sunsetDate, advisory, securityLevel (NIST L1/L3/L5), standards (ratifying bodies), category (CLASSICAL / POST_QUANTUM).

CLI filtering supports: --kty, --alg, --category, --status, --key-ops, --security-level, --standards, --composite-mode, --composite-only, --format.

Use cases: runtime algorithm selection without hardcoding, verification of availability before key generation, discovery of PQC migration paths through the advisory field, and policy-aware applications.

3. Key management and lifecycle

How does key rotation work without re-encrypting all data?

ANKASecure© uses a ROTATED state with automatic redirection:

1. Generate a successor key (same or different algorithm)
2. Original key: status → ROTATED, nextKid → successor
3. Successor key: status → ACTIVE, previousKid → original

Behavior:

Benefits: zero downtime (no re-encryption required), historical data continues to decrypt with the original key, new data uses the successor immediately.

Optional: POST /api/crypto/reencrypt converts old JWEs to the new algorithm in the background, enabling retirement of the original key.

The previousKid/nextKid chain provides a complete rotation audit trail. See Crypto Lifecycle for the state machine.

What are the key states and when do transitions occur?

Common transitions: ACTIVE → ROTATED, ACTIVE → EXPIRED, ROTATED → ARCHIVED, EXPIRED → ROTATED (emergency), REVOKED → ARCHIVED.

Notable property: REVOKED allows decrypt and verify (some competitors block all operations on revocation, causing data loss).

How is composite key lifecycle managed?

Composite keys follow the same states as simple keys but with additional validation constraints:

1. Mode immutability — COMPOSITE_KEM_COMBINE cannot change to COMPOSITE_SIGNATURE during rotation
2. Algorithm preservation — component algorithms must match exactly across rotations
3. Component count — must match (typically 2)
4. Atomic rotation — all components rotate together; no individual component rotation

Rotation endpoint: POST /api/key-management/keys/{kid}/rotations with composite-specific validation.

Result: both components rotate atomically, maintaining quantum resistance throughout the lifecycle.

Can I import legacy keys from old systems?

Yes. POST /api/migration/keystores imports PKCS#12 (.p12, .pfx) and JKS (.jks) keystores.

Process:

1. Base64-encode the keystore file
2. Provide the password (optional for unprotected stores)
3. Select validation mode (STRICT / IMPORT_ONLY / SKIP)
4. Choose KID generation strategy (AUTO appends alias, MANUAL uses explicit mappings)

Format detection is automatic via magic bytes. Multi-key bundles are extracted into individual keys with collision detection. All imported keys are wrapped with the HSM KEK (same security as native keys), tagged origin=IMPORTED, and marked restricted=true if expired (in IMPORT_ONLY mode).

What happens to keys with expired certificates?

Behavior depends on validation mode:

IMPORT_ONLY use cases: SOX, SEC Rule 17a-4, and similar regulations require ability to decrypt records even after the issuing certificate has expired. Medical records (50+ year retention) and financial archives (10–20 year retention) are typical scenarios.

Defense-in-depth: keyOps (JWT metadata) plus Policy (lifecycle rules) plus Status (EXPIRED enum) — triple enforcement.

4. HSM integration

Which HSM vendors are supported?

ANKASecure© supports multiple HSM vendors via a vendor-agnostic PKCS#11 interface (Java 25 FFM API):

Auto-detection: library path pattern matching identifies common providers. Manual override available via the pkcs11.hsm-type configuration.

For deeper HSM-vendor and integration detail, refer to the HSM Integration documentation in the security section.

Software HSM versus hardware HSM: trade-offs?

Recommendation: SoftHSM for development (identical API, dev-prod parity); hardware HSM for production. Migration path SoftHSM → CloudHSM staging → Luna production requires no application code changes — only the pkcs11.module-path configuration changes.

Can SoftHSM be used in production?

Not recommended for compliance scenarios. SoftHSM lacks FIPS 140-2 certification, has no physical tamper protection (keys live in /var/lib/softhsm/tokens/), uses a software RNG, and has extractable keys.

Acceptable for: non-compliance scenarios (internal applications without regulatory requirements), cost-sensitive deployments, and rapid deployment without hardware procurement.

For compliance-bound deployments, use Luna / CloudHSM / nShield. PCI-DSS Requirement 3.6 mandates a hardware HSM.

How are KEKs managed and how does the cache hierarchy work?

Per-tenant KEKs are generated in the HSM with CKA_EXTRACTABLE=false. One KEK per tenant ensures cryptographic isolation.

Three-level cache hierarchy:

Zero hard dependencies: L3 always works; the system never fails due to cache unavailability. If Redis is unavailable, the platform operates in degraded mode without outage.

Real-time propagation: Admin API provisions KEK → publishes to Redis → invalidates Core API L1 cache.

For deeper treatment of envelope encryption and KEK management, refer to the HSM Integration documentation in the security section.

How does ANKASecure© support FIPS 140 requirements?

ANKASecure©'s software is not FIPS 140 certified (it is a Java application, not itself a cryptographic module).

FIPS path for customers:

1. Use FIPS-certified HSMs (Luna, CloudHSM, nShield) — all have FIPS 140-2 Level 3 certificates
2. Use FIPS-approved algorithms (ML-KEM FIPS 203, ML-DSA FIPS 204, SLH-DSA FIPS 205, AES-GCM FIPS 197, RSA/ECDSA FIPS 186-5)
3. Use the Bouncy Castle FIPS edition

Customers requiring FIPS-aligned operation should deploy with FIPS-certified HSMs and enforce FIPS-approved algorithms via policy templates such as NIST_APPROVED.

5. Compliance and regulatory

What standards does ANKASecure© align with?

NIST: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), FIPS 186-5 (P-curves), CSWP 39 (composite cryptography), SP 800-227 (hybrid KEM), SP 800-56C Rev. 2 (HKDF/CatKDF/CasKDF).

FIPS: FIPS 140-2 Level 3 (HSM support), FIPS 197 (AES-256).

ETSI: QSC TR 103 808 (HQC), TS 103 744 (CatKDF/CasKDF for EU telecom 5G/6G).

Regional: BSI TR-02102-1 (Germany), ANSSI RGS v2 (France), ISO/IEC, OWASP REST API Security, GMT (China), CRYPTREC (Japan), KISA (South Korea), GOST (Russia).

For the regulatory dimension as a CAPA pillar, see Pillar 5 — Regulatory Compliance. For the algorithm-level mapping, see Algorithm Reference. For compliance region configuration, see Compliance Region Configuration.

Is ANKASecure© FedRAMP authorized?

ANKASecure© is not currently FedRAMP authorized. Current federal compliance posture:

Federal customers can deploy ANKASecure© today via enterprise on-premise (customer data center, customer controls the FedRAMP compliance boundary), FIPS-certified HSMs, and FIPS-approved algorithms enforced via the US_NSA_CNSA_ALIGNED policy template.

How does ANKASecure© support PCI-DSS, HIPAA, and GDPR?

PCI-DSS — Requirement 3.6 (cryptographic key management) via FIPS 140-2 Level 3 HSMs; Requirement 3 (protect stored cardholder data) via AES-256-GCM; Requirement 4 (protect transmitted data) via TLS 1.3 plus optional PQC transport.

HIPAA — §164.312(a)(2)(iv) (Technical Safeguards) via quantum-resistant algorithms; §164.308(b)(4) (PHI safeguards) via HSM key protection; multi-tenant isolation (cryptographic, not just access control).

GDPR — Article 32 (state-of-the-art encryption) via NIST PQC algorithms; Article 25 (data protection by design) via envelope encryption; soft-delete supports the right to erasure while preserving audit.

Audit trail: all operations logged with correlation IDs; multi-category logging with appropriate retention.

What about Common Criteria certification?

ANKASecure© is not currently Common Criteria certified. Customers requiring Common Criteria coverage can deploy ANKASecure© with Common Criteria-certified HSMs (Thales Luna has CC EAL4+ for the cryptographic module; nShield CC certifications are available). The HSM provides CC-certified key storage; ANKASecure© provides application-level cryptographic operations.

Which standards does ANKASecure© currently align with?

Current and production-deployed:

• NIST FIPS 203/204/205 (ML-KEM / ML-DSA / SLH-DSA)
• NIST CSWP 39 (composite keys)
• GSA PQC Buyer's Guide
• FIPS 186-5 (P-curves)
• NSA CNSA 2.0 (P-384 NSS)
• OWASP REST API Security
• ETSI QSC TR 103 808 (HQC)
• BSI TR-02102-1
• ANSSI RGS v2
• GMT (China), CRYPTREC (Japan), KISA (South Korea), GOST (Russia)

6. Performance and scalability

What is the throughput for different algorithm families?

Order-of-magnitude characteristics (vary by hardware and payload):

Performance bottleneck typically: network and serialization overhead vs pure crypto.

For up-to-date measured benchmarks, see Performance Benchmarks.

How many concurrent requests can ANKASecure© handle?

Concurrency is implemented with Java 25 Virtual Threads (Project Loom). Virtual threads:

• Park automatically during blocking I/O, releasing carrier threads
• Have very low memory footprint (approximately 1 KB per VT vs 1–2 MB traditional)
• Enable thousands of concurrent in-flight requests on a small carrier-thread pool

Bottleneck: typically the database (PostgreSQL single replica) — not virtual threads.

Horizontal scaling: add Core API replicas; near-linear gains until database saturation.

What is the performance for streaming large files?

Streaming operations have constant memory regardless of file size (tested multi-TB).

• Throughput — network/disk-bound (not CPU-bound)
• Latency — linear with file size

For comparison, compact operations require approximately 2× file size in memory, making them unsuitable for files larger than approximately 100 MB.

Streaming enables: database backups, video files, log archives, VM images, S3-to-S3 direct transformations, and similar large-data scenarios.

Does performance differ between ARM64 and AMD64 architectures?

Key observations: ARM64 ChaCha20 outperforms AES-GCM (no AES-NI dependency), PQC algorithms are platform-independent, and overall parity is approximately 95–105% for mixed workloads.

Recommendation: AMD64 for general workloads, ARM64 for cost-sensitive cloud (Graviton vs x86), and ARM64 for ChaCha20-heavy workloads (mobile backends, IoT gateways, VPN servers).

Multi-arch Docker images: a single stack.yml deploys to AMD64 or ARM64 automatically.

What are the resource requirements for production?

For up-to-date sizing requirements, see System Requirements. At a high level, a complete stack (microservices plus infrastructure) needs sufficient CPU and memory to run the full set comfortably with headroom for traffic spikes; dual-stack and triple-stack configurations exist for multi-environment deployments.

7. Deployment and operations

What deployment models are available?

Migration paths: SaaS → Enterprise (export, deploy, import), Enterprise → Hybrid (establish cloud connectivity).

Decision drivers: data residency, custom HSM requirement, ops team size, time-to-production constraints.

For full detail, see Deployment Models.

How does the Docker Swarm architecture work?

Docker Swarm orchestrates the full set of services across encrypted overlay networks:

• Manager node — single or multiple for HA
• Services — each microservice is a Docker Swarm service with replicas
• Networks — encrypted IPSec overlay per environment, complete isolation between dev / staging / prod
• Secrets — Docker Swarm secrets, stdin-injected, encrypted at rest in Raft, never disk
• Volumes — persistent (PostgreSQL, Redis, OpenSearch, keystores, logs)

Common operations: docker stack deploy -c stack.yml {env}, docker service scale {env}_core-api=3, envctl.sh {env} up --force for zero-downtime rolling updates.

For deeper treatment, see Platform Architecture.

Can ANKASecure© run on multi-architecture clusters?

Yes. Docker multi-arch images support heterogeneous clusters: an AMD64 manager with ARM64 workers, for example. Swarm schedules services based on architecture constraints in stack.yml. Performance is approximately equivalent across architectures for mixed workloads.

How are monitoring and alerting configured?

Metrics — Micrometer OTLP registry → OTel Collector → any OTLP-compatible backend (Grafana Cloud, Datadog, New Relic, Dynatrace).

Logging — Structured JSON (Logback + Logstash encoder), multi-category (app, audit, usage, license, auth), Fluent Bit ingestion to OpenSearch, daily indexes with retention tiers.

Health checks — Spring Boot Actuator probes via /actuator/health/liveness and /actuator/health/readiness on per-service management ports.

Correlation IDs — UUID per request via X-Correlation-ID header, propagated across microservices for distributed debugging.

For full observability detail, see OpenTelemetry.

What is the backup and restore procedure?

Backup is via backup-env.sh {env} /backups/, producing a compressed tarball that includes PostgreSQL dump, Redis RDB snapshot, configuration, keystores (PKCS#12 encrypted), and audit logs. Docker Swarm secrets are deliberately excluded for security (preventing secret recovery from backup theft).

Restore is via restore-env.sh {env} /backups/{file}.tar.gz and includes secret regeneration; applications must re-authenticate with the new JWT keys.

Backup schedule defaults to daily automated cron; retention is configurable. Disaster recovery (decompress, regenerate secrets, re-deploy stack, verify health) takes approximately 30–60 minutes for a full environment.

8. Migration and interoperability

Can I import PKCS#12 and JKS keystores?

Yes. POST /api/migration/keystores supports both PKCS#12 (.p12, .pfx) and JKS (.jks) with automatic format detection. Multi-key bundles are extracted into individual keys with collision detection. Certificate chains (Root CA, Intermediate CA, End Entity) are imported. A staged validation pipeline runs structural, key-binding, temporal, CA expiration, chain signature, optional PKIX trust anchor, and extension checks. All imported keys are HSM-protected with the same envelope encryption as native keys.

How do I convert legacy PKCS#7 / S/MIME files to modern JOSE?

Two-phase approach.

Phase 1 — Import keys: POST /api/migration/keystores imports the PKCS#12 containing signer / recipient private keys.

Phase 2 — Analyze and convert: POST /api/migration/analyze-pkcs7 introspects structure (SignedData, EnvelopedData, SignedAndEnvelopedData), and POST /api/migration/convert-pkcs7-to-jose transforms to JWE/JWS preserving classical algorithms.

Optional Phase 3 — PQC upgrade: POST /api/crypto/resign (RSA → ML-DSA), POST /api/crypto/reencrypt (RSA → ML-KEM).

Streaming variants (analyze-pkcs7-stream, convert-pkcs7-stream) handle larger files.

What are realistic migration timelines for RSA → PQC?

Timeline depends on deployment size:

Decision factors: application count, risk tolerance, uptime requirements, compliance deadlines.

ANKASecure©'s contribution: zero code changes (configuration-driven), and the actual platform-side migration is a policy update of minutes — the timelines above reflect organizational validation and testing, not platform limitations.

For the framework that organizes this migration, see The Cryptographic Maturity Model and Pillar 3 — Frictionless Modernization.

Can ANKASecure© coexist with our existing KMS (AWS, Azure, HashiCorp Vault)?

Yes. ANKASecure© complements existing KMS rather than replacing them. Patterns:

• Dual-KMS — ANKASecure© for PQC operations, existing KMS for classical
• Gradual migration — new applications use ANKASecure©, legacy continues with existing KMS
• Interoperability — utility operations (verify signatures from KMS, encrypt for KMS recipients) without requiring keystore import
• Unified — migrate all keys to ANKASecure©, retire the old KMS

Coexistence is sustainable indefinitely; organizations frequently run dual-KMS for years during gradual migration.

What about migrating S/MIME email archives to PQC?

S/MIME uses PKCS#7 format. Process:

1. Extract S/MIME signing keys from email-client keystores; import via POST /api/migration/keystores
2. For each email: analyze-pkcs7 introspects, convert-pkcs7-to-jose transforms to JWS Compact
3. Optional: resign to replace RSA with ML-DSA-65
4. For large archives, use streaming variants and a checkpoint/resume pattern

9. SDK, CLI, and integration

Which SDKs and tools are available?

Current:

• Java SDK — Maven Central (co.ankatech.secureclient:AnkaSecureSDK), Android support
• Crypto CLI — encryption, signatures, key management, streaming, PKCS#7 migration; multi-platform installers (Windows .exe/.zip, macOS .dmg, Linux .sh/.deb)
• Platform Admin CLI — super-admin, cross-tenant, deployment policies; interactive mode
• Tenant Admin CLI — tenant-scoped users / apps / credentials / policy overrides; automatic tenant scoping

REST APIs: OpenAPI 3.0, Swagger UI at /swagger-ui.html.

Non-JVM applications integrate via the REST API directly using the OpenAPI 3.0 specification.

For deeper treatment, see SDK & CLI Overview, SDK, and CLI Tools.

What are the CLI modes (interactive, guided, batch)?

Interactive mode (--interactive or -i) — menu-driven with index-based selection (no UUID copy-pasting), multi-step wizards, breadcrumb navigation, type-to-confirm safety on destructive actions. Significantly reduces learning curve and eliminates syntax errors.

Guided mode (Crypto CLI specific) — step-by-step prompts for complex operations such as composite key generation; selects regulatory templates and configures limits.

Batch mode (default, command-line syntax) — traditional CLI suitable for automation; JSON output for piping to jq.

All commands are accessible in all modes.

How do I integrate with REST APIs programmatically?

Java applications — use the SDK (thread-safe sharing across thousands of threads, automatic token refresh, optional transparent PQC transport):

AnkaSecureSdk factory = new AnkaSecureSdk(props);
AuthenticatedSdk sdk = factory.authenticateApplication(clientId, clientSecret);
EncryptResult result = sdk.encrypt("my-key", plaintext);

Other JVM languages (Kotlin, Scala) — OpenAPI Generator produces type-safe clients from /v3/api-docs.

Non-JVM (Python, Go, JavaScript, .NET, etc.) — REST API integration: POST /api/authenticate/app to obtain a JWT, then Authorization: Bearer for crypto endpoints. OpenAPI Generator can produce typed clients from /v3/api-docs.

Is there RapidAPI marketplace integration?

Yes. ANKASecure© is available on RapidAPI, with JIT tenant provisioning (automatic tenant creation on first request from a RapidAPI user via the X-RapidAPI-User header), proxy authentication via X-RapidAPI-Proxy-Secret, and per-user usage tracking.

Sign up on RapidAPI → automatic ANKASecure© tenant created → immediate API access. See RapidAPI Integration.

What administrative tools exist for multi-tenant management?

Profile isolation: Platform CLI in ~/.ankasecure-admin/platform/, Tenant CLI in ~/.ankasecure-admin/tenant/ — both can be logged in simultaneously without conflict.

10. Policy engine

How does the multi-level policy system work?

Two-level policy hierarchy with simple fallback resolution:

Resolution: try the tenant policy → if found, use it (full override); else try the deployment policy; else null (permissive default).

Validation at creation: a tenant policy must be a subset of the deployment policy (more restrictive, never less). This prevents security weakening — a tenant cannot enable algorithms that the deployment forbids.

Synchronization: dual caching with Redis Pub/Sub invalidation propagating in milliseconds.

What policy templates are available and how do I select one?

Templates are organized in three families:

Core: DEFAULT, POST_QUANTUM, CLASSICAL, NIST_APPROVED, HIGH_SECURITY, PQC_TRANSITION.

Regional: EU_ALIGNED, CHINA_GMT, JAPAN_CRYPTREC, KOREA_KISA, GOST, US_NSA_CNSA, BSI_TR02102, ANSSI_RGS, ETSI_QSC, GLOBAL_ISO, SAUDI_NCA, MALAYSIA_MYSEAL, IETF_RFC, FINANCE.

Hybrid enforcement: BSI_HYBRID_ENFORCED, ANSSI_HYBRID_ENFORCED, ETSI_HYBRID_ENFORCED, EU_UNIFIED_HYBRID, NIST, ENISA.

Selection guidance:

Application: CLI ankasecure-platform deployment algorithm-policy set --template BSI_HYBRID_ENFORCED or REST PUT /api/admin/platform/deployment/policies/algorithm-availability.

For the policy management API, see Policy Management.

How are policies enforced and what happens on violation?

Enforcement runs at every operation:

1. Extract tenantId from JWT claim
2. PolicyService.getEffectiveAlgorithmPolicy(tenantId) queries the multi-level cache
3. Validate the requested algorithm against policy: explicit algorithms, allowed families, required security levels, mandatory standards
4. On denial: HTTP 403 Forbidden with explanatory message

Example violations:

Policy bypass is impossible — enforcement runs in Core API for every operation. The only override path is updating the policy itself via the Admin API with proper authorization.

How fast do policy changes propagate across the platform?

Real-time propagation via Redis Pub/Sub:

1. Admin API updates PostgreSQL
2. Writes Redis SET ankasecure:policy:{type}:{tenantId} EX 3600
3. Publishes policy:invalidate
4. Core API subscribers receive in milliseconds, invalidate L1 Caffeine cache
5. Next request fetches from L2 Redis

Sync modes:

Single tenant policy update: sub-second propagation. Full platform sync: tens of seconds depending on tenant count.

For the policy sync architecture, see Policy Sync Behavior.

Where to read next