​
Components

​
Policy vs. custody

QuantumLock separates two responsibilities that are often conflated:
  • Policy (QuantumLock): which algorithm to use, when to sign, key lifecycle rules, who may call what.
  • Custody (the KMS provider): where private keys physically live and where the cryptographic operation executes.
The provider registry resolves custody per request from the deployment’s configuration: Trust profiles raise the floor on custody: profiles exist from standard (local or BYOC optional) through enterprise and sovereign profiles (cloud KMS or HSM custody expected) to defense, which requires a PKCS#11 HSM and refuses to operate without one. Deployment targets span the public clouds, on-premises, and air-gapped environments; sovereign/on-prem targets imply stricter custody defaults. Two properties hold everywhere:
  1. Fail-closed selection. If the configured provider is unusable — SDK missing, HSM unreachable, key store down — the request is refused with 503; it is never quietly served by a software key, because a signature’s custody claim must be trustworthy.
  2. Auth before custody. Authentication and scope checks resolve before any provider is constructed, so unauthenticated callers can neither probe custody posture nor trigger key creation.

​
Trust boundaries

  • Your API key identifies your workspace; everything you create (licenses, artifacts, key_refs, bundles) is namespaced to it.
  • Your end users never hold your API key. They hold licenses, whose signatures are the credential for hybrid validation and offline checks.
  • Third-party verifiers need only the published verification keys, a bundle, an inclusion proof, and a signed checkpoint — see Evidence & Transparency.

​
Where things run

The SaaS deployment runs as a container service with a PostgreSQL license store. Interactive API docs are disabled in production; the OpenAPI-derived surface is documented in the API Reference. For deployment options relevant to customers, see Deployment.