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.
A bank's most sensitive assets - payment credentials, customer PII, long-lived contracts, HSM-rooted signing keys, TLS session material - are protected today by RSA and elliptic-curve cryptography, and both fall to Shor's algorithm on a cryptographically relevant quantum computer. The threat does not wait for that machine to exist: adversaries capture encrypted traffic and archives now and decrypt them later. For data with a 10-25 year confidentiality horizon - mortgages, custody records, health-linked insurance, government contracts - the exposure has already begun, and the 2026 mandates (EO 14412, DORA, PCI DSS 4.0, CNSA 2.0, MAS TRM) have converted it into dated obligations your auditors will test.
This five-phase migration evaluation framework maps each phase to a source surface, documentation path, or verification procedure. The mapping does not prove deployment-specific end-to-end execution; runtime behavior is NOT VERIFIED.
The 2026 mandate landscape
The standards are settled and the deadlines are concrete. Your PQC program should map to:
- US Executive Order 14412 (June 2026): federal High-Value Assets must use PQC for key establishment by 2030 and digital signatures by 2031; CISA and NIST are to publish minimum elements for a Cryptographic Bill of Materials (CBOM) within 270 days.
- EU DORA (in force since January 2025): encryption and key-lifecycle policy, certificate registers, crypto-agility, and operational-resilience testing.
- PCI DSS v4.0.1: a cryptographic algorithm inventory has been mandatory since March 2025.
- NSA CNSA 2.0: ML-KEM-1024 and ML-DSA-87, required for new national-security systems from January 2027 - the bar defense-adjacent counterparties will hold their suppliers to.
- MAS TRM (January 2021) and Singapore PDPA: MAS-regulated institutions are expected to assess and mitigate quantum risk under existing technology-risk and data-protection obligations.
Every framework on that list terminates in the same demand: show us the evidence. QNSI source defines evidence-pack mappings for SOC 2, HIPAA, GDPR, PCI DSS, ISO 27001, PDPA, and MAS TRM. Complete generation, data provenance, and independent deployment verification remain NOT VERIFIED.
Phase 1 - Discover: build the CBOM with QNSI Crypto Inventory
You cannot migrate what you cannot see, and EO 14412 turns the machine-readable CBOM from best practice into a requirement. QNSI Crypto Inventory defines 11 cloud-vendor connector families and 36 normalized source types for keys, certificates, algorithm usage, host, Kubernetes, TLS, imports, and code findings. Complete connector execution and estate coverage remain deployment-specific.
Open Crypto Inventory in the portal at cloud.qnsi.heossi.com, connect your accounts, and the first inventory run replaces the spreadsheet archaeology most banks budget a quarter for. The same data is available programmatically - cryptoInventory.discoverAssets() and listAssets() in every QNSI SDK - so the CBOM lands in your existing pipelines, not another silo.
Phase 2 - Assess and prioritize with the QNSI readiness score
Discovery produces a list; migration needs a ranked plan. Rank each classical algorithm by urgency - RSA-1024-class material is critical, RSA-2048 and ECDSA-P256 are high - and let context escalate: a certificate on the public wire, or one expiring inside 90 days, moves up a level. QNSI rolls the classified inventory into an organization-level PQC readiness score across key management, certificate infrastructure, TLS, code signing, data protection, hardware security, and governance.
That score - on the Crypto Inventory dashboard and via cryptoInventory.getReadinessScore() in the SDK - is the number a bank reports to its board and its regulator quarter over quarter. 'Where are we on PQC?' becomes a query, not a workshop.
Phase 3 - Make the algorithm a policy decision: QNSI crypto policy tiers
The biggest failure mode in a crypto migration is hard-coding the new algorithm. If ML-KEM-768 is baked into application logic the way RSA was, you have simply bought the next migration. On QNSI, algorithm choice is a per-tenant crypto policy - default, strict, maximum or government - not a code change: your application asks the QNSI KMS for a key, and the policy decides which algorithms are allowed, whether hardware custody applies, and whether operations are cross-verified across two independent implementations. Government tier pins FIPS-finalized algorithms only.
The source catalog exposes 87 post-quantum algorithms - 24 KEMs and 63 signatures across 13 families - through provider abstractions, with @noble/post-quantum covering an overlapping FIPS subset. BYOK, rotation, and 8 capability-gated BYOHSM connector implementations are represented in source. Production execution across every advertised path is NOT VERIFIED, and the current escrow route is not threshold recovery and is not presented as available.
The SDK call below illustrates the intended ML-DSA signing contract. A local snippet or successful response is not independent production proof.
// pnpm add @heossihq/qnsi (Python: pip install qnsi · Rust: cargo add qnsi · JVM: com.heossi:qnsi)
import { QnsiClient } from "@heossihq/qnsi";
const qnsi = new QnsiClient({ apiKey: process.env.QNSI_API_KEY });
const key = await qnsi.kms.createKey({ algorithm: "dilithium-5", purpose: "signing" }); // ML-DSA-87 (FIPS 204)
const data = new TextEncoder().encode("settlement batch 4821");
const sig = await qnsi.kms.sign(key.keyId, data);
console.log(await qnsi.kms.verify(key.keyId, data, sig)); // truePhase 4 - Implement the PQC-native data and transport target
The required architecture is PQC-native: vault and storage data-encryption keys must be established or wrapped by a genuine PQC KEM before AES-256-GCM bulk encryption. The current Vault and Storage migration, including safe recovery and rewrap of existing DEKs, is not complete; end-to-end production protection is NOT VERIFIED.
X25519MLKEM768 is not the native default. It may be selected only as an explicit composite-interop boundary with separate labelling, audit, and metering. Production edge negotiation is NOT VERIFIED. The command below is an unexecuted verification procedure; its output must be captured independently before any runtime claim is made.
# Verification procedure only; no successful negotiation is asserted
# Requires OpenSSL 3.5+ with X25519MLKEM768 support
echo | openssl s_client -connect api.qnsi.heossi.com:443 \
-servername api.qnsi.heossi.com -groups X25519MLKEM768 2>&1 | grep 'group:'Phase 5 - Prove it: signed audit chain and evidence packs
For a bank, a migration that cannot be proven to an auditor is incomplete. QNSI source defines hash-linked, ML-DSA-signed audit and provider-attestation contracts. Complete operation ingestion, signature publication, reconstruction, and independent deployment verification remain NOT VERIFIED.
The source maps evidence-pack contracts to MAS TRM, PCI DSS, SOC 2, ISO 27001, PDPA, HIPAA, and GDPR; complete pack provenance and deployment behavior are NOT VERIFIED. The separate conformance artifact at qnsi.heossi.com/verify/conformance proves only its published NIST ACVP vector scope.
Start now
Phase 1 does not need a procurement cycle. Create a Free Forever workspace at https://cloud.qnsi.heossi.com/auth?mode=signup, mint an API key, and make your first post-quantum call in minutes. Developer plans start at $149/month; enterprise tiers add maximum and government crypto policy, HSM-rooted custody and dual-control workflows. To walk your specific estate through the five phases, talk to an architect at qnsi.heossi.com/contact.