Comparison
QNSI vs AWS KMS
An honest, code-grounded side-by-side. Every row in the table below is backed by a verifiable public source - AWS documentation, NIST FIPS publications, or QNSI source files. We don't make claims we can't support.
AWS KMS is a strong product for AWS-resident workloads, and it now negotiates hybrid ML-KEM in the TLS handshake to its endpoints. But that protects data in transit to the API - the keys stored under KMS still wrap with classical material, and KMS exposes no PQC key operations in its data plane. QNSI is built for the next decade - quantum-safe at the data plane by default, multi-cloud by design, with per-tenant crypto-policy enforcement and a unified SDK across five languages. The two systems can also coexist: QNSI can wrap existing AWS KMS keys for a phased migration without re-keying every artifact.
Side by side
Eight categories that matter to a security buyer
| Category | QNSI | AWS KMS |
|---|---|---|
| NIST PQC algorithm coverage | 87 algorithms across 13 PQC families (24 KEMs + 63 signatures). ML-KEM (FIPS 203, finalized Aug 2024), ML-DSA (FIPS 204, finalized Aug 2024), SLH-DSA (FIPS 205, finalized Aug 2024), Falcon, BIKE, Classic McEliece, FrodoKEM, MAYO, CROSS, UOV, SNOVA, NTRU-Prime. Independently reproducible from the public mirror at github.com/heossihq/qnsi-public. | AWS KMS has exposed generally available ML-DSA-44, ML-DSA-65, and ML-DSA-87 signing key operations since June 2025. AWS states that ML-DSA keys and signature operations run in its FIPS 140-3 Security Level 3 validated HSMs. AWS KMS also supports hybrid ML-KEM TLS to service endpoints; that transport feature is distinct from ML-DSA key operations. Sources: docs.aws.amazon.com/kms/latest/developerguide/mldsa.html and aws.amazon.com/about-aws/whats-new/2025/06/aws-kms-post-quantum-ml-dsa-digital-signatures/. |
| Multi-cloud / portability | QNSI publishes shared client contracts and defines cloud, customer-VPC, on-premises, and air-gapped architecture options. Dedicated topologies and customer-HSM paths become supported only after deployment-specific provisioning and qualification. | AWS-only. Cross-region keys via multi-region key feature; cross-cloud unsupported. Migrating off AWS requires re-encryption of all KMS-protected data with a different KMS provider. |
| Hardware Security Module model | Native software crypto by default; six capability-gated PKCS#11 connector implementations and two REST custody backends. Hardware custody and vendor-certificate scope require live device qualification. The current escrow route is not threshold recovery and is not presented as available. | AWS KMS is backed by AWS-operated FIPS 140-3 Security Level 3 validated HSMs and supports native ML-DSA signing. AWS CloudHSM is a separate customer-controlled HSM service; QNSI's current CloudHSM/HSPK qualification uses RSA-OAEP custody with software ML-DSA. Any FIPS statement must identify the exact service/module, operation, configuration, certificate, and certificate owner. |
| Audit trail | The audit source defines hash chaining, checkpoint signing, streaming, and configurable retention contracts. Complete KMS event ingestion, production replay, and retention effects remain NOT VERIFIED. | CloudTrail logs every KMS API call. Tamper-evidence depends on CloudTrail log file integrity validation (a separate, customer-enabled feature). Real-time streaming via EventBridge requires additional plumbing. |
| Crypto policy enforcement | Per-tenant crypto-policy tiers (default / strict / maximum / government) enforce algorithm allow-lists at the KMS service layer. Government tier allows only ML-KEM-1024 + ML-DSA-87 + SLH-DSA-256f. Tenants on lower tiers cannot accidentally use weaker algorithms. | Algorithm choice is per-key; AWS does not ship a built-in per-tenant crypto-policy abstraction. Customers compose policy gating from KMS key policies, Org SCPs, IAM conditions, or third-party tools (e.g. CloudCustodian) - see docs.aws.amazon.com/kms/latest/developerguide/key-policies.html and docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html. |
| Free tier | Free forever: 20 KMS keys + 20 000 KMS ops/month + 25 vault secrets + 10 GB encrypted storage + 50 000 API calls/month, no credit card. Tier limits independently reproducible from the public mirror at github.com/heossihq/qnsi-public. | AWS Free Tier: 20 000 KMS requests/month for the first 12 months. Beyond 12 months, $0.03 per 10 000 requests + $1/month per customer-managed key (aws.amazon.com/kms/pricing - verify before quoting). |
| Migration / coexistence | Customers running AWS KMS today can layer QNSI on top: QNSI wraps existing KMS-protected keys with PQC envelope encryption (vault.wrap → kms.sign with ML-DSA), so the AWS-side key never moves. Crypto Inventory (CBOM) auto-discovers existing KMS keys for a phased migration plan. | Vendor lock-in by design. Migrating to a different KMS provider requires re-encryption of every KMS-encrypted artifact (S3 SSE-KMS objects, EBS volumes, RDS snapshots, etc.) - a multi-quarter project for most enterprises. |
| SDK languages | TypeScript / Node.js (@heossihq/qnsi), Python (qnsi), Go (sdks/go/qnsi), Rust (qnsi on crates.io), JVM / Android (com.heossi:qnsi on Maven Central). Identical wire contracts; outputs round-trip across languages byte-for-byte. One activation handshake per process. | AWS SDK for ~10 languages. AWS Encryption SDK is a separate package per language. Cross-language byte-compatibility depends on careful KMS context + AAD wiring. |
When to pick which
Decision guide
Stay on AWS KMS if…
- Your data lifecycle is < 7 years and your threat model excludes HNDL (harvest-now-decrypt-later) attacks.
- You're 100% AWS-resident and not under an upcoming multi-cloud mandate.
- Classical RSA/ECC keys are sufficient for your compliance regime today.
Add QNSI on top if…
- You have data with retention > 7 years that an adversary could harvest today and decrypt later.
- You're under regulator pressure to show a NIST PQC migration plan (NIST SP 800-208).
- You need multi-cloud or hybrid-cloud KMS without re-keying.
Replace AWS KMS with QNSI if…
- You're starting greenfield - no migration cost, get PQC by default.
- You operate in a regulated sector (finance, healthcare, defense, government) where the auditor is asking about quantum readiness.
- Your application stack uses Python / Go / Rust as much as TypeScript and you want one consistent SDK.
Try it yourself
Verify the QNSI claims in 30 seconds
The PQC sandbox at qnsi.heossi.com/#verify-sandbox runs real ML-KEM-768 and ML-DSA-65 operations on every page request. Or sign up for a free QNSI account, get an API key, and wrap your first ML-KEM secret in a few lines of @heossihq/qnsi.