Start here: AWS KMS is good. That's not the question.
AWS KMS is a genuinely strong managed key service. It is durable, deeply integrated across the AWS estate, audited through CloudTrail, and backed by HSMs you never have to manage. If your data, your applications, and your compliance boundary all live inside AWS, KMS is the path of least resistance for a reason. This guide is not an argument against it.
The question that actually matters in 2026 is narrower: does AWS KMS cover the post-quantum surface you need it to cover, and if not, what do you add — without ripping out what already works? QNSP, the flagship post-quantum cryptography platform from CUI Labs, is designed to answer the second half of that question. So let's be precise about where the line falls, then walk a migration path that keeps your AWS-side keys exactly where they are until you choose to move them.
What AWS KMS does for post-quantum today
AWS has done real PQC work, and it should be credited fairly. Hybrid ML-KEM in the TLS handshake is now generally available across AWS KMS, ACM, and Secrets Manager (non-FIPS endpoints, all Regions). That means the connection between your client and the KMS API is protected against a harvest-now-decrypt-later attacker who records traffic today to decrypt once a cryptographically relevant quantum computer exists.
That is a meaningful mitigation for one specific attack: passive capture of the API channel. It is the layer AWS chose to harden first, and it is the right first move for the data-in-transit threat.
Where the data plane still sits classical
Inside the KMS data plane, the stored key material and key operations are still RSA, ECC, and AES with classical wrapping. As of June 2026 there is no ML-KEM encapsulation, and no ML-DSA or SLH-DSA signing exposed as a native KMS key operation. (For contrast and fairness: Google Cloud KMS does expose PQC KEMs in preview and ML-DSA / SLH-DSA signatures as key purposes — so this is a per-provider state of play, not an industry-wide gap.)
This is not a flaw in AWS KMS; it is a scope boundary. KMS protects the transport to its API and the durability of your keys. If your post-quantum requirement stops at 'protect the channel and keep my AES-256-wrapped data,' KMS plus hybrid ML-KEM TLS may be all you need. The gap opens when your requirement extends to PQC key operations, governance over which algorithms are even permitted, an auditable inventory of every cryptographic asset, portability beyond one cloud, or evidence you can hand an auditor.
When cloud KMS is enough — and when it isn't
Be honest with yourself about which side of this line you're on before you migrate anything. Most teams are on the 'KMS is enough' side for a while, and that's fine.
- AWS KMS is likely enough if: you are AWS-only with no cross-cloud or on-prem footprint; your PQC concern is the API transport channel; you don't have a regulatory requirement to enumerate and attest cryptographic assets; and per-key algorithm choice composed from KMS key policies, Org SCPs, and IAM conditions is sufficient governance for you.
- You likely need a dedicated PQC platform if: you must perform real PQC key operations (ML-KEM encapsulation, ML-DSA / SLH-DSA signing) as first-class operations, not just TLS hardening; you need a per-tenant or per-environment crypto-policy that enforces an algorithm allow-list at the service layer; you must produce a Cryptographic Bill of Materials (CBOM) for compliance; you run multi-cloud, on-prem, or air-gapped and need one wire contract everywhere; or you need independently verifiable conformance evidence rather than a vendor assertion.
What a dedicated PQC platform adds (the four real differentiators)
QNSP is a full managed platform — 18 backend services including KMS, a PQC-encrypted vault, SSE-X encrypted storage, vector search, AI orchestration, a tamper-evident audit trail, CBOM crypto-inventory, and crypto-policy enforcement at an edge gateway. Against a cloud key service, four differences carry the migration decision.
- Algorithm breadth as real key operations: 90 PQC algorithms across 14 families (27 KEMs + 63 signatures), including ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205), plus Falcon, HQC, Classic McEliece, FrodoKEM, BIKE, MAYO, CROSS, UOV, SNOVA and NTRU-Prime — exposed as actual encapsulation and signing operations, not just transport.
- Crypto-policy governance: per-tenant tiers (default / strict / maximum / government) enforce algorithm allow-lists at the KMS service layer. The government tier restricts KEM to FIPS-203 ML-KEM-1024. A tenant on a lower tier cannot accidentally pick a weaker algorithm — governance is enforced, not just documented.
- CBOM crypto inventory: crypto-inventory-service emits a Cryptographic Bill of Materials in CycloneDX 1.5 (cryptographic-properties extension) and auto-discovers existing keys — including your AWS KMS keys — so you get a real inventory to plan against.
- Portability and verifiable conformance: the same wire contract on AWS, GCP, Azure, on-prem, and air-gapped, with public NIST ACVP conformance at /verify/conformance (noble 435/435; liboqs 240/240 on the addressable ML-KEM surface), bound to a SHA-3-256 tamper digest regenerated each release.
Signing and provenance across the platform
Migration is not only about KEMs. Signatures are the other half of the quantum-vulnerable surface, and they show up in tokens, audit records, and attestations. On QNSP, JWTs default to ML-DSA-44 (Dilithium-2), the audit trail defaults to ML-DSA-65 (Dilithium-3), and CBOM crypto-attestation uses ML-DSA-44 verified against a pinned public key. KMS supports ML-DSA-44/65/87.
The practical point for a migration plan: if your current setup signs service tokens or audit entries with classical ECDSA, those signatures are in scope for the same Shor threat as your key exchange. A platform that signs with ML-DSA by default closes that gap as a side effect of adoption, rather than as a separate project you have to schedule later.
The migration principle: layer, don't lift-and-shift
The single biggest fear in any KMS migration is re-encrypting everything. Moving off one KMS provider to another normally means re-wrapping all KMS-protected data with the new provider — slow, risky, and hard to roll back. The migration pattern here deliberately avoids that.
Instead, QNSP layers on top of your existing AWS KMS: it wraps your existing KMS-protected keys with PQC envelope encryption (vault.wrap, then kms.sign with ML-DSA), so the AWS-side key never moves. You add a post-quantum envelope around what you already have. The classical AWS key stays in KMS, under AWS HSMs, audited by CloudTrail — and a PQC layer wraps it. That makes the migration reversible at every step, which is exactly what you want when crypto is involved.
Step 1 — Inventory with CBOM
You cannot migrate what you cannot see. Before touching any key, run a crypto inventory. QNSP's crypto-inventory-service auto-discovers existing cryptographic assets — including AWS KMS keys — and emits a CBOM in CycloneDX 1.5. The output is a concrete, machine-readable list: which keys exist, which algorithms back them, which are public-key primitives exposed to Shor, and which are AES-256 symmetric keys that are already quantum-resistant.
This inventory does two jobs at once. It scopes the migration (you'll usually find that the urgent set is your asymmetric key-exchange and signing keys, not your bulk-AES data keys), and it produces the auditable artifact a regulator or risk committee will ask for. Treat the CBOM as the source of truth for the phases that follow.
Step 2 — Dual-stack (PQC wraps the AWS key in place)
With the inventory in hand, stand up QNSP alongside AWS KMS and run both. For each in-scope key, QNSP wraps the existing AWS KMS-protected key with a PQC envelope rather than replacing it. The hybrid posture means a passive attacker who records traffic gains nothing post-quantum, while every classical consumer keeps working unchanged.
Run this dual-stack state long enough to build confidence: confirm PQC wrap/unwrap round-trips for every consumer, confirm the audit trail is hash-chaining the new operations, and confirm your crypto-policy tier is enforcing the algorithm allow-list you intend. Because the AWS key never moved, rollback at this stage is simply: stop using the PQC envelope. Nothing is destroyed.
Step 3 — Cut over (deliberately, key class by key class)
Cutover is the phase where new data uses the PQC path by default and you begin retiring classical-only operations — done per key class, not all at once. Order the cutover by risk from your CBOM: long-lived secrets and signing keys with the longest confidentiality horizon first (they have the most harvest-now-decrypt-later exposure), short-lived ephemeral material later.
Keep the AWS-side classical key available until the corresponding class is fully verified on the PQC path in the live platform. Only then retire the classical operation. This is the same discipline as a database migration: dual-write, verify, then stop the old write. The platform's tamper-evident audit log gives you the evidence trail for each cutover step, and the live /verify/conformance digest gives you something concrete to point an auditor at instead of a slide.
A fair scorecard
To keep this honest, here's the trade in plain terms — no fabricated weaknesses on either side.
- AWS KMS strengths: deep AWS-native integration, zero key-management ops, CloudTrail logging, HSM-backed durability, and hybrid ML-KEM TLS now GA across KMS/ACM/Secrets Manager. If you're AWS-only and your PQC need is the transport channel, this is a clean fit.
- AWS KMS boundaries: PQC is in the TLS handshake, not the data plane; no per-tenant crypto-policy abstraction (you compose it from key policies + SCPs + IAM); CloudTrail tamper-evidence is a separate opt-in feature; and it's AWS-only — cross-cloud migration means re-encryption.
- QNSP strengths: 90 PQC algorithms as real key operations, enforced crypto-policy tiers, CBOM in CycloneDX 1.5, multi-cloud/on-prem/air-gapped portability under one wire contract, a tamper-evident audit trail, and public dual-provider NIST ACVP conformance. It is the most complete and most verifiable full managed PQC platform for teams whose needs exceed transport hardening — a different layer of the stack than a cloud key service.
- QNSP cost of adoption: it is a platform, not a drop-in KMS replacement — you operate (or consume managed) more surface than a single AWS service. The layering pattern keeps that cost low by not requiring you to move AWS keys, but it's still a platform decision, not a config flag.
How to decide this week
If you take one action from this guide, run the inventory. A CBOM tells you whether you even have a migration to do — many teams discover their urgent surface is a handful of asymmetric signing and key-exchange keys, not the petabytes of AES-256 they were worried about. The free-forever tier (10 GB storage, 50,000 API calls/month, 20 KMS keys, 25 vault secrets) is enough to discover and wrap a meaningful slice without a procurement cycle, with SDKs in five languages (npm/TypeScript, PyPI/Python, Go, Rust, JVM via Maven Central) and an MCP server.
On the regulatory clock: FIPS 203, 204, and 205 were finalized in August 2024; FIPS 206 (FN-DSA/Falcon) is still draft; HQC was selected in March 2025 but is not yet a finalized FIPS standard. The CNSA 2.0 federal window runs roughly 2030–2033. None of that is a reason to re-encrypt everything tomorrow — it's a reason to inventory now, dual-stack the long-lived secrets, and keep AWS KMS doing exactly what it's good at while you do.