This page states what the running service demonstrably does — nothing more. Where a capability is a roadmap item or a non-goal, it says so.

​
Cryptographic inventory

Honest algorithm labels. Signature records name the mechanism that actually ran. The service resolves post-quantum mechanism names against the installed liboqs at runtime rather than hardcoding labels, precisely so a record can never claim ML-DSA-65 for something else. Mis-labeling one scheme as another is treated as a defect class, and regression tests ban a list of known-false claims from the codebase and its documentation. Entropy sources. The default entropy source is the operating system CSPRNG. QCOS-backed (quantum hardware), QRNG, HSM, simulator, and hybrid sources are optional and explicitly selected, and each entropy job records its source, health tests, and provenance. Quantum entropy is a provenance feature, not a magic security upgrade, and it is never silently substituted.

​
Authentication and tenancy

  • Every authenticated route takes a platform API key in x-api-key, checked against per-key scopes (quantumlock:read / use / keys / sign). Missing credential → 401 with a WWW-Authenticate challenge; wrong scope → 403. Scope checks are strict — no scope implies any other.
  • Tenancy is enforced with namespaced owner identifiers: licenses, artifacts, KMS keys (key_refs), and evidence bundles are readable and mutable only by the tenant that created them. Evidence bundles attribute to the authenticated principal; a tenant_id in a request body is ignored.
  • Self-service registration is disabled by default; keys come from the platform console. Legacy self-registered keys carry a bounded scope set and are never granted quantumlock:sign.
  • Authentication resolves before expensive resources: on KMS/evidence routes, no KMS provider is built and no key material is touched for a caller who is not let in.

​
Fail-closed behavior

QuantumLock prefers refusing to pretending. The load-bearing cases:

​
Withdrawn rather than degraded

When the 2026-07 security audit found surfaces whose guarantees the service could not back — the internal PKI, encryption-as-a-service, and trust badges — they were withdrawn (unmounted, answering 410 Gone with the reason) rather than left running in a weakened state. An advertised endpoint is a capability claim; see the withdrawn list.

​
Operational practices for integrators

  • Keep API keys out of source code; use environment variables or a secret manager, and rotate a compromised key immediately in the platform console.
  • Use separate keys for development, staging, and production, scoped to the minimum needed (read for verifiers, sign only where signing happens).
  • Never ship your API key inside client software — hybrid validation exists so shipped software authenticates with the license, not with your key.
  • Log validation failures without printing full license keys.

​
Limitations and non-goals

Stated plainly, in the spirit of the QuantumLock security whitepaper:
  • No QKD, no “quantum digital signatures”. Post-quantum security here means NIST-standardized lattice signatures (ML-DSA) computed on classical hardware. Nothing in QuantumLock performs quantum key distribution.
  • Quantum entropy is not the default. The default entropy source is the local CSPRNG. QCOS/QRNG sources are optional and provenance-tracked.
  • PQC beyond ML-DSA is limited or roadmap. Production signing and sealing use RSA-PSS + ML-DSA. ML-KEM and SLH-DSA appear as key types in the Enterprise Key Engine where liboqs provides them; Falcon, XMSS, and LMS are not implemented.
  • No blockchain anchoring. Evidence integrity rests on dual signatures and the Merkle transparency log.
  • No public CA, no OCSP, no ACME. QuantumLock is not a certificate authority and does not replace a qualified trust service provider; the previous internal PKI surface is withdrawn.
  • “PQC-ready” is not a certification. It means the service implements NIST PQC algorithms; it is not a quantum-proof certification of your product.
  • Local (software) key custody is not an HSM. It is not equivalent to a FIPS 140-3 certified module; deployments that require hardware custody must configure a PKCS#11 HSM, and the defense profile refuses to run without one.
  • License validation is software protection, not hardware security. A client-side check can be tampered with by someone controlling the machine; pair it with server-side validation and evidence bundles where the stakes require it.
  • No performance or uptime figures are promised here. Service levels are defined per plan in your agreement, not in this documentation.