ANKASecure© lets each tenant choose the Root of Trust that wraps its keys, through a three-rung precedence resolved per tenant: the tenant’s own backend, the managed backend its licensed edition assigns, or the deployment default. A tenant can bring its own AWS KMS, GCP KMS, Azure Key Vault or Azure Managed HSM key in its own account under its own credential, or an AWS CloudHSM or other PKCS#11 HSM; ANKASecure© exercises a live round trip before accepting the declaration, and the key-encryption key that wraps the tenant’s data keys never leaves that backend. Custody is independent of the deployment model — SaaS, private cloud or on-premise including air-gapped — and every wrap and unwrap appears both in ANKASecure©’s signed audit trail and in the provider’s own log. The reference architecture makes distributed Roots of Trust a conformance requirement.

Your keys never leave your HSM. That is a configuration, not a promise.

Every vendor says your keys stay yours. ANKASecure© makes it a setting you can read: each tenant declares the backend that wraps its keys — its own HSM, or its own cloud KMS account under its own credential — and the key-encryption key never leaves that backend. The proof is in your provider’s own log, not in a slide.

CISOHead of infrastructureHead of cryptography
See the 15-minute demoHow it works

Is this you

Three ways this lands on your desk

A clause says the keys stay

A regulator, a board policy or a customer contract requires that key material never leave your HSM or your jurisdiction. Any platform that needs to hold the Root of Trust is disqualified before the evaluation starts.

A cloud migration is blocked on custody

The workloads can move. The keys cannot, or must move into an account the company controls. The migration waits on an answer to who wraps what, and where.

Subsidiaries with different rules

One entity keeps an HSM on premises, another is cloud-only, a third is in a jurisdiction with its own list. One platform has to hold all three without making them share a failure domain.

Who signs this: A CISO or head of cryptography who owns the custody requirement, and a head of infrastructure who owns the HSM or the cloud account it names. If a vendor evaluation stopped at “where does the Root of Trust live?”, this is the conversation.

How it works

Four moves, none of them a migration of your keys

The tenant chooses the Root of Trust. ANKASecure© wraps under it and never holds it.

  1. Choose the Root of Trust, per tenant

    Three rungs, resolved per tenant and stopping at the first one declared: the tenant’s own backend, the managed backend its licensed edition assigns, or the deployment default. A subsidiary that brings its own HSM and one that does not live in the same installation.

    • tenant BYOK
    • edition-assigned
    • deployment default

  2. Bring your own backend

    Declare your HSM or your cloud KMS key — in your account, under your credential. ANKASecure© runs a live round trip against it before accepting the declaration. From then on the key-encryption key that wraps the tenant’s data keys lives there and only there.

    • AWS KMS
    • AWS CloudHSM
    • GCP KMS
    • Azure Key Vault
    • Azure Managed HSM
    • PKCS#11

  3. Keep the deployment choice too

    SaaS operated by ANKATech, your private cloud, or on-premise — including air-gapped. Custody and deployment are separate decisions: a SaaS tenant can still wrap under its own KMS account, and an on-premise installation can still serve a tenant that brings a cloud key.

  4. Prove it from outside the platform

    Every wrap and unwrap of a data key is a call to your backend, so it appears in your provider’s own audit log — CloudTrail, Cloud Audit Logs, Azure Monitor, your HSM’s log — alongside ANKASecure©’s signed trail. Two records, two owners, one story.

    • signed audit trail
    • your provider’s log

Fifteen minutes

What you will actually watch

Live, on a real deployment, against a backend in an account you control. Nothing in this list is a mock-up or a roadmap item.

  1. A tenant on the managed backend. Its keys, and the backend that wraps them, on screen.

  2. The tenant declares its own KMS key in its own account. The live round trip runs; the declaration is accepted.

  3. A key is created under it. The wrap call appears in the cloud provider’s audit log, in your account, seconds later.

  4. A second tenant, on a different backend, in the same installation. Neither can reach the other’s Root of Trust.

  5. ANKASecure©’s signed trail next to the provider’s log: the same operations, recorded by two parties.

  6. Your custody clause, checked on the deployment rather than on a slide.

What it rests on

The capabilities underneath, with their state

  • Shipping

    Three-rung backend precedence

    Tenant BYOK, then the backend the licensed edition assigns, then the deployment default; resolved per tenant.

  • Shipping

    Cloud KMS backends

    AWS KMS, GCP KMS, Azure Key Vault and Azure Managed HSM, each exercised in a live round trip against the real service.

  • Shipping

    HSM backends

    AWS CloudHSM exercised live; PKCS#11 adapters for other HSMs ship with a published per-mechanism certification state.

  • Shipping

    Per-tenant keystores and key lifecycle

    Envelope encryption: data keys wrapped by a per-tenant key-encryption key that never leaves the backend; a seven-state lifecycle per key.

  • Shipping

    Three deployment models

    SaaS, private cloud, on-premise including air-gapped — independent of the custody decision.

  • Shipping

    Signed audit trail

    Every wrap and unwrap recorded, tamper-evident, beside your provider’s own log.

All of the platform →

The framework

Where this sits in CAPA

The Cryptographic Control Plane reference architecture states this as a conformance requirement, not a preference: a platform that requires every key or Root of Trust to live in a single provider or cryptographic failure domain does not conform.

02

Primary pillar

Cryptographic Sovereignty

Scenario realised

Retaining control of the Root of Trust

Practical test

“Can the organization govern policy across all its trust domains without moving keys, and revoke a third party’s cryptographic authority without re-encrypting the data?”

05

Primary pillar

Enterprise Readiness

Scenario realised

Integrating with the existing enterprise security ecosystem

Practical test

“Can the control plane be adopted without replacing the identity, KMS/HSM, PKI, or monitoring platforms already in place?”

04

Supporting pillar

Cryptographic Governance & Compliance

Scenario realised

Applying policy across multiple jurisdictions

Practical test

“Can the organization prove, by querying the control plane, which policy applied to a given operation, and change that policy centrally?”

L2L3

Maturity move

From a KMS the platform depends on to a Control Plane that governs keys wherever they are held. Custody is the property that makes level 3 acceptable to an organization that could not otherwise adopt one.

The six maturity levels →Reference architecture: cryptographiccontrolplane.org

What this does not do

  • It does not operate your HSM or your cloud account. The backend, its credential and its availability stay yours; ANKASecure© calls it and records the call.

  • It does not move a tenant’s existing key material between backends on its own. Changing the Root of Trust is a governed operation with its own evidence, not a background migration.

  • It does not certify you. ANKASecure© maps its controls to NIST CSWP 39, the GSA PQC Buyer’s Guide and OWASP and hands you the evidence; the determination is still your auditor’s.

After this

The same installation already does these

No new deployment, no second contract for the platform. Once the Root of Trust is where it must be, everything on top of it is policy.

Bring your custody clause.

The one that says the keys stay. Fifteen minutes on a live deployment to show it as a setting, against an account you control.

Book the demo