Your keys. Your custody. Always.
Each tenant holds their own keys in their own KMS or HSM. Veridra holds only references — structural custody, not procedural custody.
Revoking your key at the KMS is sufficient to stop us from signing. We built the architecture around key management; it isn't a feature bolted on top.
Custody model
Each tenant maintains two key classes: a signing key for the attestation pipeline and a data-encryption key hierarchy for envelope encryption. Both reside in the customer's chosen custody backend within their selected region — never materialized within Veridra services.
The signer service retains only a reference (ARN, key URI, or PKCS#11 handle). Each signature involves an outbound mTLS call to the customer's KMS. Disabling the key causes the next signing request to fail immediately, with the failure itself recorded as a signed log entry.
Supported custodians
AWS KMS
Asymmetric Ed25519 CMK with per-tenant IAM grant scoped to the Veridra signer role. CloudTrail provides line-item records of every signature request. CMKs support multi-region or single-region configurations based on residency requirements.
Azure Key Vault and Managed HSM
Ed25519 key with tenant-specific access policy. Managed HSM delivers FIPS 140-2 Level 3 custody with dedicated HSM partition and purge protection enabled by default.
GCP KMS and Cloud HSM
Ed25519 key in tenant-owned keyring. HSM protection level available where certifications require hardware custody. IAM binding restricted to the signer service account.
HashiCorp Vault (Transit)
Self-hosted option for on-premises or sovereign deployments. Transit engine with auto-unseal via cloud KMS or HSM, maintaining the same Ed25519 interface.
PKCS#11 HSMs
Direct integration with Thales Luna, Entrust nShield, YubiHSM 2, and AWS CloudHSM — designed for regulated environments where managed cloud KMS falls outside scope.
Lifecycle operations
Envelope encryption
Stored content uses per-tenant data keys wrapped by the customer's KMS CMK. The wrapped key resides alongside ciphertext; unwrapping occurs only within the customer's KMS. CMK rotation rotates the wrapping without rewriting ciphertext.
Scheduled rotation
Keys rotate on customer-defined cadences: quarterly, annually, or on-demand. The old public signing key remains published, preserving verifiability of historical signatures. Each rotation appears as a signed transparency log entry for audit timelines.
Break-glass revocation
KMS-level revocation acts as an immediate kill-switch, taking effect in seconds rather than through support processes. The signer returns signed errors, embedding revocation within the evidence record.
Per-tenant scoping
The kms-adapter enforces that a signer pod's SPIFFE identity can authorize only that tenant's key. Cross-tenant access is structurally impossible, not a permissions gap.
Quorum operations
Sensitive actions — enabling new regions, changing custody backends, exporting public keys — require two-person operator sign-off and appear as signed governance events.