Technology · KMS

Key management, the way a bank would build it.

Per-tenant isolation, HSM root of trust, policy-engine gating, and a cryptographic audit log. Every sign operation is signed twice — once by the key, once by the policy.

Key hierarchy

Five classes of keys, five different storage models. A leaf key can never compromise the root.

ClassStorage / rotation / usage
Root / Master
Storage: HSM (FIPS 140-2 L3)
Rotation: 5 years
Signs intermediate CA certs, nothing else
Tenant Signing
Storage: MPC cohort (3-of-5)
Rotation: Proactive every 90 days
Signs client-directed transactions
Data-at-Rest
Storage: KMS + HSM-wrapped DEK
Rotation: Per-object DEK, yearly KEK
AES-256-GCM envelope encryption
TLS / mTLS
Storage: Per-pod ephemeral
Rotation: 24h rotation via SPIFFE
Service-to-service auth
API / JWT
Storage: KMS (Ed25519)
Rotation: Daily
Signs user session JWTs

Per-tenant isolation.

Every tenant gets a dedicated encryption key at the KMS level, backed by a dedicated HSM partition (or full HSM on the Enterprise tier). A compromise of tenant A's key material is mathematically uncorrelated with tenant B.

Tenant-scoped KEK per organization
Envelope encryption — per-object DEK, KMS-wrapped
Bring-your-own-key (BYOK): import wrapped keys from AWS KMS / GCP KMS
Hold-your-own-key (HYOK): Enterprise-tier external HSM integration

Policy engine.

A signature isn't just "can this key sign?" — it's "should this key sign this payload right now?" Every sign request is evaluated by a declarative policy engine before the key ever moves.

VelocityPer-key per-hour signature cap; exceed = auto-disable + pagerduty
Geo-fenceRequire signing request to originate from approved regions
Destination allowlistWhitelist counterparties per key; deny everything else
Amount thresholdBelow $X single-factor; above requires multi-party approval
Time-of-dayBlock withdrawals outside business hours for treasury keys
Dual controlTwo human approvers required above policy threshold

Cryptographic audit log

Every sign, every policy evaluation, every rotation — sealed into a tamper-evident log.

Hash-chained

Each event commits the previous event hash. Deletion is detectable — you can't quietly remove a suspicious sign.

Blockchain-anchored

Every N events, the log root is committed to the Z-Chain. Tampering requires rewriting a public blockchain.

Customer-replicated

Enterprise tenants get a read-only replica of their audit log, signed by our KMS — export it for your SIEM.

Open-source stack.

Lux KMS builds on github.com/luxfi/kms and the shared Hanzo KMS (Infisical-based) at kms.hanzo.ai. Secrets are never stored in application databases — apps authenticate to KMS with short-lived JWTs and fetch wrapped material at runtime.

Universal Auth for service-to-service secret fetching
Zero-knowledge secret encryption — operators can't read tenant secrets
Automatic rotation hooks for DB credentials, API tokens

Plays well with:

HSM — root of trust for all KEKs
MPC — signing keys never reconstructed
Post-quantum — ML-KEM wrapping for forward secrecy
Compliance — audit log exports for SOC 2 / PCI

Managed keys. Enforced policy.

Let Lux manage the hard parts of key lifecycle. Inherit HSM rooting and FIPS compliance on day one.