TRUST & SECURITY

Who holds the keys, and who can see what

ANKASecure© runs as a managed service or inside your own perimeter. This page states, for each deployment model, who operates the platform, where the root of trust lives and what ANKATech can and cannot see, followed by the controls the platform enforces in every model.

DEPLOYMENT MODELS

Three ways to run it, one custody boundary

The deployment model is chosen when the environment is created and cannot change afterwards. What separates the models is who operates them: ANKATech in SaaS, your own team in private cloud and on-premise.

Operated by ANKATech

SaaS

Who operates it: ANKATech runs the platform; you administer your tenant.
Where it runs: ANKATech infrastructure, shared by tenants and isolated per tenant.
Root of trust: A key-encryption key per tenant in a backend ANKATech manages, whose assurance level depends on the edition, up to a dedicated cloud HSM. On editions that include it, you bring your own Cloud KMS key instead: AWS KMS (also in a key store on your own CloudHSM cluster), Google Cloud KMS or Azure Key Vault.
What ANKATech can see: Service health, tenant count, key counts and usage volumes. Not your keys, applications, users, policies or audit log content. ANKATech cannot act inside your tenant unless your administrator grants time-boxed support access (24 hours at most), and even then it cannot import or destroy keys.
Connection to ANKATech: The service itself.

Operated by you

Private cloud

Who operates it: Your team runs the whole platform.
Where it runs: Your own cloud account (AWS, Azure, Google Cloud).
Root of trust: Your HSM or Cloud KMS. Key-encryption keys never leave it.
What ANKATech can see: Nothing: no plaintext, ciphertext, keys, audit logs, tenants or users.
Connection to ANKATech: None required: no inbound access, no telemetry, no call-home. The licence is a signed file verified locally.

Operated by you

On-premise

Who operates it: Your team runs the whole platform.
Where it runs: Your datacenter, connected or air-gapped.
Root of trust: Your HSM (Thales Luna, Entrust nShield and other PKCS#11 devices) or Cloud KMS. Key-encryption keys never leave it.
What ANKATech can see: Nothing: no plaintext, ciphertext, keys, audit logs, tenants or users.
Connection to ANKATech: None required: no inbound access, no telemetry, no call-home. The licence is a signed file verified locally, so an air-gapped site needs no online activation.

Private cloud and on-premise behave identically: every platform decision that depends on the deployment model treats them the same way. Only the location of your infrastructure differs. In both, your own platform administrators can administer every tenant, but they still cannot extract key material from the HSM or alter historical audit records.

SECURITY ARCHITECTURE

Controls the platform enforces in every model

These are properties of the code, not of an operating procedure: they hold whoever runs the deployment.

Keys wrapped under your root of trust

Every key is stored wrapped with AES-256-GCM under a key-encryption key that stays in the HSM or Cloud KMS: PKCS#11 devices, AWS KMS, Google Cloud KMS or Azure Key Vault. The wrapping binds the tenant, so a wrapped key cannot be replayed into another tenant.

Tenant isolation that fails closed

The tenant comes from the verified token, never from the request, and every query is scoped to it. Authorization data shared between services is signed with Ed25519; a missing, expired or unverifiable value denies the operation instead of falling back to a default.

Mutual TLS between services

Every internal hop is mutual TLS: each service presents its own certificate and admits only the peers it expects. Connections to the database use TLS 1.3 with full server verification.

Signed, tamper-evident audit

Every cryptographic and administrative operation emits an audit event signed with HMAC-SHA256 by the service that produced it and verified before it is stored. Events can be forwarded to your SIEM in CEF or OCSF over Syslog, Splunk HEC, Microsoft Sentinel or webhook.

Hybrid keys that need both halves

Composite keys pair a classical and a post-quantum algorithm with AND-decrypt: an attacker must break both. ANKASecure© deliberately does not implement the OR variant, which is only as strong as its weaker half. Sensitive payloads can also travel inside an ML-KEM session.

Signed releases and licences

Each release publishes its container images by digest in a signed release manifest, and an installed environment deploys exactly those digests. The licence is signed with a composite ML-DSA-65 and Ed25519 key and verified locally against a public key built into the platform.

STANDARDS

Aligned with published standards

FIPS 203

ML-KEM

FIPS 204

ML-DSA

FIPS 205

SLH-DSA

CNSA 2.0

Algorithm alignment

See the algorithm catalogue →

COMMON QUESTIONS

What security teams ask first

Stored wrapped under a key-encryption key that never leaves an HSM or Cloud KMS. In private cloud and on-premise that HSM or KMS is yours. In SaaS it is a backend ANKATech manages, with one key-encryption key per tenant, and on editions that include it you bring your own Cloud KMS key.

Review the architecture with our engineers

Bring your security questions and your deployment constraints; we walk through custody, isolation and audit against your model.

Talk to engineering