QNSI

Platform capability

Post-Quantum Key Management & Custody

Govern key creation, rotation, signing, verification, wrapping, import, policy, and qualified customer-managed custody from one tenant-scoped control surface.

Buyer outcome

Move cryptographic control away from application code while preserving explicit policy, authorization, custody boundaries, and reproducible evidence.

Source-backed · qualified paths identified

For CISO · PKI lead · Cloud security · Platform engineering

Evidence boundary

KMS routes, policy contracts, BYOK, rotation, signing, wrapping, and eight capability-gated custody connectors exist in source. Complete route execution and platform-wide enforcement remain NOT VERIFIED. The current escrow route is not threshold recovery and is not presented as available.

Capability map

What keys & custody covers

Each item is a source-backed or deployment-bounded capability, not an implied certification or universal runtime guarantee.

ML-KEM, ML-DSA, and SLH-DSA operations through tenant-scoped policy
BYOK import, scheduled rotation, signing, verification, wrap, and unwrap contracts
Six PKCS#11 and two REST customer-managed custody connector implementations
HSM-Sealed Post-Quantum Keys for ML-DSA-44/65/87 compatibility
Usage analytics, lifecycle policy, and cryptographic transition controls
Fail-closed HSM requirements until the selected device and configuration qualify

Operating model

How the capability fits into an accountable workflow

01

Select the trust policy

Choose the permitted algorithm set, assurance tier, approval requirements, and custody boundary.

02

Create or import

Generate new material or import eligible customer-controlled material through an authorized path.

03

Operate and rotate

Use stable key identifiers while policy governs signing, verification, wrapping, versions, and rotation.

04

Qualify custody

Prove module loading, capability discovery, operations, interruption handling, audit effects, and certificate scope before naming a hardware path supported.

Integration & assurance

Connect the capability, then verify the exact boundary

Integration surfaces

AWS CloudHSMAzure Dedicated HSMThales LunaEntrust nShieldUtimaco CryptoServerMarvell LiquidSecurityHashiCorp Vault TransitFortanix DSM

Frequently asked questions

Keys & Custody questions

Do all eight HSM integrations execute QNSI algorithms in hardware?

No. Six connectors use PKCS#11 and two use REST. Hardware mechanisms, firmware, configuration, validation scope, and supported operations vary. A connector is compatibility code; a named deployment becomes supported only after the published qualification path succeeds.

Does QNSI currently provide M-of-N threshold key recovery?

No. The current escrow route does not create threshold shares or reconstruct a key, so QNSI does not present threshold recovery as available. Any future recovery workflow must be implemented, exercised, and independently evidenced before that claim changes.

Next step

Evaluate the capability against your actual environment

Start with the public evidence, then scope the exact services, integrations, custody, deployment, and assurance required. QNSI will not convert source presence into a production claim without evidence.