QNSI
Start building free
Platform
Platform overviewCapabilitiesAlgorithm catalogWhy QNSI
Solutions
Solutions by Use CaseSolutions by IndustryAssessment & migrationPQC migration guideCompare platforms
Developers
DocumentationDeveloper hubBuild patternsAI assistants (MCP)Public source & evidence
Pricing
Company
About HEOSSIChangelogContactKnowledge CentreResearchNews & Insights
TrustHub
TrustHub overviewSecurity programCompliance mappingPublic evidenceService statusResponsible disclosureLegal & Policy LibraryTerms of ServicePrivacy PolicyData Processing AddendumSub-processors
Start building free

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. QNSI is built to compress that programme from years to months - without breaking your existing classical surface.

Talk to a QNSI migration engineer →
Scoped engagement: inventory + parallel deployment within 30 days.
Start free, scope yourself →
Free-forever tier includes 10 GB PQC storage + 50K API calls + 20 KMS keys to run your own migration assessment.

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. QNSI'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 QNSI'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 tenant CBOM covering TLS certificates, KMS keys, vault secrets, signing keys, workload identities, host observations, and cryptographic API usage found in source repositories.
QNSI mechanism
Crypto Inventory combines cloud, TLS, host, probe, and Kubernetes discovery with local `qnsi crypto scan` reports. Source contents stay local; normalized findings enter inventory as code_repo / code_usage evidence.
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 providing long-term post-quantum protection.
Outcome
New workloads on QNSI'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.
QNSI mechanism
Target state: tenant policy selects finalized algorithms for eligible operations and a canary records observed hybrid-handshake results. Complete KMS routing, edge negotiation, and platform-wide enforcement require deployment-specific evidence.
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.
QNSI 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. Govern execution
Move through reviewed, recoverable migration waves
A bulk migration without an immutable preview, independent approval, recovery state, or provider reconciliation turns cryptographic change into an uncontrolled outage risk.
Outcome
The exact dry-run is hash-confirmed, approved by a second operator, executed in bounded waves, and recoverable after interruption. Ambiguous provider outcomes remain unresolved until evidence confirms what happened.
QNSI mechanism
Durable execution, wave, asset-action, control-event, and reconciliation ledgers. Pause / resume / cancel controls, per-asset cutover confirmation, worker leases, and immutable evidence hashes.
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.
QNSI 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.

FAQ

PQC migration - frequently asked questions

Direct answers to the questions teams ask before starting a post-quantum migration.

How do I migrate to post-quantum cryptography?

Migrate in five stages: inventory cloud, host, TLS, and source-code cryptography into a CBOM; deploy PQC in parallel with classical algorithms; enable cross-verification; execute hash-approved migration waves with recovery and reconciliation; then generate evidence packs. QNSI preserves classical compatibility during controlled cutover.

How long does PQC migration take?

There is no fixed timeline-it scales with the size and ownership of your cryptographic surface. QNSI shortens discovery with cloud connectors and local source scanning, then controls execution through reviewed waves rather than a single bulk change. You can start local scanning and inventory immediately and scope migration from measured evidence.

Related

Where to go from here

The Quantum Imperative →
HNDL, NIST PQC standards, CNSA 2.0 deadlines, the migration window.
Algorithm Catalog →
13 families covering ML-KEM, ML-DSA, SLH-DSA, Falcon, BIKE, Classic McEliece 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).