Beyond AWS KMS: Migrating to Post-Quantum Key Management with QNSI

Evidence boundary: any present-tense QNSI product wording below describes source-declared contracts, architecture targets, or vendor-run artifacts-not independently observed production behavior. Conformance artifacts prove only their stated algorithm scope. End-to-end production execution is NOT VERIFIED.

Your keys live in AWS KMS. Your risk committee wants the quantum-safe plan - EO 14412 has put PQC deadlines of 2030 and 2031 on federal High-Value Assets, CNSA 2.0 binds the national-security supply chain from January 2027, and DORA and PCI DSS 4.0 push the same direction in finance. Nobody in the room wants to re-encrypt petabytes or rip out a service that works.

QNSI source defines a reversible AWS migration architecture spanning inventory, BYOK, policy, audit, and genuine PQC envelopes. Connector execution, KEM wrapping, enforcement, evidence provenance, and end-to-end deployment behavior remain NOT VERIFIED.

Where AWS KMS stands on PQC - the factual version

Credit where due: AWS KMS is a strong managed key service-durable, deeply integrated, CloudTrail-audited, and HSM-backed. It has exposed generally available ML-DSA-44, ML-DSA-65, and ML-DSA-87 signing key operations since June 2025, and AWS states that those keys and signature operations run in FIPS 140-3 Security Level 3 validated HSMs. Hybrid ML-KEM also protects transport to supported AWS endpoints; that transport feature is distinct from ML-DSA key operations.

That native ML-DSA capability is real, but it is not an estate-wide migration program. If your requirement is ML-DSA signing inside AWS, KMS may be the right target. If it extends to discovering cryptography across clouds and source code, choosing target paths per asset, enforcing policy, coordinating recoverable migration waves, retaining existing qualified PKCS#11 custody where needed, and producing evidence an auditor can re-run, that is the layer QNSI occupies.

Threat-model precision: Shor's algorithm breaks the asymmetric layer - RSA and ECC key exchange and signatures. Grover's only halves symmetric strength, so AES-256 stays safe. Your urgent migration surface is asymmetric keys, not bulk AES data.

What QNSI puts on the table

87 catalogued PQC algorithms - 24 KEMs and 63 signatures across 13 families - with source-defined key-operation and overlapping provider contracts. Complete route and dual-provider execution remain NOT VERIFIED.
Per-tenant policy source with a finalized-only Government configuration and qualified-HSM requirement. Platform-wide production enforcement remains NOT VERIFIED.
CBOM crypto inventory contracts across 11 cloud-vendor connector families and 36 source types - including AWS KMS, ACM, ELB, S3, RDS, and Secrets Manager - plus CycloneDX export and readiness scoring. Complete execution and coverage remain deployment-specific.
BYOK, 8 capability-gated BYOHSM connector implementations, rotation, and algorithm-transition contracts exist in source. The current escrow route is not threshold recovery and is not presented as available; complete runtime behavior remains NOT VERIFIED.
Vault, encrypted-storage, and vector-search targets whose genuine PQC envelopes and plaintext boundaries remain NOT VERIFIED.
Source-defined audit chaining, evidence packs, framework mappings, and dual-control contracts. Complete event coverage, control effectiveness, and approval execution remain NOT VERIFIED.
PQC-native transport is the required architecture, and SDK/CLI/MCP surfaces exist in source. Public-edge negotiation and route alignment remain NOT VERIFIED.

Step 1 - Inventory your AWS keys with the CBOM connector

The AWS inventory source defines contracts for KMS, ACM, load balancers, S3, RDS, and Secrets Manager plus CBOM scoring/export. Complete connector execution, asset coverage, and deployment accuracy remain NOT VERIFIED.

import { QnsiClient } from "@heossihq/qnsi";

const qnsi = new QnsiClient({ apiKey: process.env.QNSI_API_KEY! });

// After connecting the AWS source in the portal:
const assets = await qnsi.cryptoInventory.listAssets(); // every discovered key + algorithm
const readiness = await qnsi.cryptoInventory.getReadinessScore(await qnsi.tenantId());

Step 2 - Layer a PQC envelope around the keys that stay

The reversible target keeps the AWS key in place while introducing a genuine ML-KEM recipient envelope for data keys. QNSI end-to-end wrapping, compatibility, rollback, and deployment behavior remain NOT VERIFIED; do not retire existing keys without independently verified recovery and rewrap evidence.

Do not re-key or retire AWS KMS keys as step one. Until the PQC path is verified against real traffic, the classical key is your rollback. The envelope pattern exists so you never have to burn the boats.

// Seal a data key under ML-KEM-1024 - the AWS-side CMK stays exactly where it is
const pqcKey = await qnsi.kms.createKey({ algorithm: "kyber-1024", purpose: "kem" }); // ML-KEM-1024
const sealed = await qnsi.kms.wrap(pqcKey.keyId, dataKey); // dataKey = your existing DEK bytes
const restored = await qnsi.kms.unwrap(pqcKey.keyId, sealed);

Step 3 - Move what should move: BYOK, policy, dual-control

Some keys belong on the PQC platform outright. QNSI supports BYOK import, scheduled rotation, algorithm transition, 8 capability-gated BYOHSM connector implementations, and the current escrow route, which is not threshold recovery and is not presented as available. Hardware custody is enabled only after the selected backend passes live qualification.

Source defines fail-closed PQC policy, dual-control, audit, and evidence-pack contracts. Complete enforcement, approval effects, event ingestion, pack provenance, and deployment behavior remain NOT VERIFIED.

Coexistence is the strategy, not a compromise

The end state is not 'QNSI replaced AWS KMS.' It is: AWS KMS keeps encrypting AWS-native infrastructure, where it is excellent - and QNSI fronts the quantum-exposed workloads: data with a decade-plus confidentiality horizon, signing infrastructure, and regulated estates with CBOM and evidence obligations. One wire contract across clouds and on-prem, five SDK languages, a CLI, and an MCP server - so the PQC layer is not a second lock-in.

Verify before you buy: live NIST ACVP conformance evidence for both of QNSI's crypto implementations is public at qnsi.heossi.com/verify/conformance - per-algorithm results, regenerated each release, no account required.

A fair scorecard

Stay on AWS KMS alone when: your estate is AWS-only, your PQC requirement is transport hardening, and you have no CBOM or attestation obligations. It is very good at that job.
Add QNSI when: you need post-quantum key operations today across the standardized families, enforceable per-tenant algorithm policy, a cross-cloud CBOM, BYOK/BYOH with hardware roots, dual-controlled destructive operations, and evidence an auditor can re-run.
The honest cost: QNSI is a platform decision, not a configuration flag. The envelope pattern keeps the migration reversible and your AWS keys in place - but treat adoption as a program with an owner, the way you would any control plane.

Start now

The first step costs nothing and settles the scoping argument: create a Free Forever tenant at https://cloud.qnsi.heossi.com/auth?mode=signup, connect the AWS source, and read your own CBOM this week - no procurement cycle required. Developer plans start at $149/month; HSM-rooted and government-tier deployments are enterprise engagements.

Want the migration mapped against your actual key estate? Talk to an architect at /contact - bring the CBOM, and we will walk it with you.