PQC Migration
The defensible path to post-quantum cryptography
Migrating to post-quantum cryptography is not a flag flip. It is an inventory exercise, a parallel-deployment programme, a verification regime, an automation lift, and an evidence-generation pipeline. QNSP is built to compress that programme from years to months — without breaking your existing classical surface.
Drivers
Why this is on a clock
The PQC migration is not a 'next year' problem. Regulator deadlines, harvest-now-decrypt-later threat models, and compliance-framework updates all converge on 2027–2030.
CNSA 2.0 (US National Security Systems)
January 2027 transition begins · 2030 full compliance
Commercial National Security Algorithm 2.0 — mandates ML-KEM, ML-DSA, SLH-DSA for US national security systems. Federal contractors and defence-adjacent suppliers begin transition January 2027.
FedRAMP PQC alignment
Tracks CNSA 2.0 + FIPS 140-3 module validations
FedRAMP Moderate / High baselines reference FIPS-validated cryptography. As CMVP validates ML-KEM / ML-DSA / SLH-DSA modules, FedRAMP authorisations begin requiring PQC support.
MAS TRM (Singapore FSI)
Continuous; Section 8 (Cryptography) updated as standards land
Monetary Authority of Singapore Technology Risk Management Guidelines (Jan 2021) require 'robust and sound cryptographic algorithms and key management practices'. As NIST PQC standards are finalised, MAS TRM-regulated FSI entities must incorporate them.
Harvest Now, Decrypt Later (HNDL)
Already in progress
State-level adversaries record encrypted traffic today, intending to decrypt it once cryptographically-relevant quantum computers (CRQC) are available. Data with long confidentiality requirements (≥10 years) needs PQC protection now, not after CRQC arrives.
PCI DSS v4.0.1 + ISO/IEC 27001:2022 + GDPR
Cryptographic agility expectations rising
Modern compliance frameworks increasingly require demonstrable cryptographic agility — the ability to swap algorithms in response to standards changes or cryptanalytic advances. QNSP's policy-engine + dual-provider architecture is built specifically for this.
The Path
5 stages from where you are to defensible PQC
Each stage is a discrete deliverable. You can start at stage 1 (inventory) regardless of organisational PQC maturity; stages 2–5 unlock as you progress through QNSP's crypto-policy tiers.
1. Discover
Inventory your current crypto surface
Most organisations cannot answer 'where do you use cryptography' with a defensible list. The migration starts by closing that gap.
Outcome
A Cryptographic Bill of Materials (CBOM) per NIST SP 1800-38B: every TLS cert, KMS key, vault secret, signing key, JWT issuer, and mTLS identity in your cloud accounts.
QNSP mechanism
crypto-inventory-service scans 11 cloud-vendor surfaces (AWS, Azure, GCP, Cloudflare, Vault, etc.) and emits a CBOM-formatted inventory bound to your tenant.
2. Parallel-deploy
Run PQC alongside classical, not instead of
The naive migration ('replace RSA with ML-KEM') breaks compatibility with every classical client. The defensible migration runs hybrid: classical + PQC together, with PQC carrying the long-archival security guarantee.
Outcome
New workloads on QNSP's strict crypto-policy tier sign and encrypt with ML-KEM-768 + ML-DSA-65. Hybrid TLS (X25519+ML-KEM-768) preserves classical client compatibility. Existing services keep running unchanged.
QNSP mechanism
Tenant crypto-policy tier set to `strict`. KMS auto-routes new key requests to ML-KEM + ML-DSA. PQC TLS canary monitors hybrid-TLS handshake success at the edge gateway.
3. Cross-verify
Upgrade to dual-provider verification
A single PQC implementation is a single point of failure for cryptographic agility. Dual-provider cross-verification catches single-implementation bugs at runtime before they reach the audit ledger.
Outcome
Every signature operation on Maximum + Government tiers is signed by liboqs and independently verified by noble. Provider attestation flows into every audit event.
QNSP mechanism
Tenant crypto-policy upgraded to `maximum`. cross-verification-service registered alongside primary KMS path. Provider attestation written into the AuditCryptoContext for every sign / encrypt operation.
4. Automate rotation
Replace manual key rotation with policy-driven automation
The migration isn't done at first deploy. Long-archival data needs key rotation on regulator-driven cadences (90-day, 1-year, 7-year). Manual rotation doesn't scale.
Outcome
ML-KEM, ML-DSA, SLH-DSA rotation on configurable schedules. Rotation events audit-signed and bound to per-tenant policy. Failed rotations alert via the security-monitoring service.
QNSP mechanism
pqc-rotation-automation add-on. Rotation schedules per algorithm family. Failed-rotation alerts pipe to the security-monitoring SNS topic.
5. Evidence
Generate compliance evidence packs for auditors and regulators
The point of the migration isn't 'we shipped PQC' — it's 'we can defend that we shipped PQC to a regulator'. That requires evidence.
Outcome
Per-framework reports (SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, PDPA, MAS TRM) bound to live framework status, control-level evidence, NIST ACVP digest, entropy chain documentation, and current CBOM.
QNSP mechanism
evidence-compliance-pack add-on. On-demand evidence pack generation from the cloud portal. Reports include the SHA-3-256 ACVP digest binding our conformance evidence at the moment of generation.
Related
Where to go from here
The Quantum Imperative →
HNDL, NIST PQC standards, CNSA 2.0 deadlines, the migration window.
Algorithm Catalog →
14 families covering ML-KEM, ML-DSA, SLH-DSA, Falcon, HQC, BIKE and more — with per-algo FIPS standard, key sizes, ACVP coverage.
Compliance Mapping →
7 frameworks mapped at the control level — SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, PDPA, MAS TRM. Real-time evaluation via live service-health probes.
Pricing →
14 tiers from Free through Enterprise Elite. Migration starts on the strict tier (Business Team and up).