Most organisations treat post-quantum migration as a 2028 problem. The reasoning is straightforward: cryptographically-relevant quantum computers (CRQC) don't exist yet, NIST only finalised the standards in August 2024, and the headline regulatory deadline (CNSA 2.0) is January 2027. There's time.
This reasoning is wrong, and it's wrong for a specific reason: the harvest-now-decrypt-later (HNDL) threat model doesn't wait for CRQC. Every byte of encrypted traffic captured today by a state-level adversary — and there are many — is a candidate for future quantum decryption. The clock is running on data confidentiality, not on quantum hardware.
What HNDL actually means in operational terms
Here is the threat model spelled out concretely. Imagine your organisation processes a class of records today — patient health records, financial settlement instructions, defence procurement contracts, legal privileged communications — that has a confidentiality requirement of N years.
That traffic is currently encrypted with classical TLS (typically X25519 or ECDHE-P256 for key agreement, AES-256-GCM for bulk encryption). A state-level adversary records the ciphertext today. They cannot decrypt it today because the underlying public-key cryptography (RSA / ECDH) is computationally infeasible to break with classical computers.
Sometime between 2030 and 2040 (estimates vary; the conservative end is sooner), a cryptographically-relevant quantum computer becomes available. The adversary runs Shor's algorithm against the recorded key-exchange traffic, recovers the AES session keys, decrypts the bulk-encrypted records. The confidentiality of your records is now retroactively broken — including records whose confidentiality requirement extends past 2040.
The math: if you process data today with a 10-year confidentiality requirement, and you believe CRQC is 8 years out, you are already 2 years past the deadline.
Why CNSA 2.0 January 2027 is the deadline for being DONE
The US National Security Agency's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) mandates ML-KEM, ML-DSA, and SLH-DSA for US National Security Systems. The transition timeline:
- January 2027: PQC required for new National Security Systems
- December 2030: PQC required for all existing National Security Systems
- December 2033: Classical algorithms (RSA, ECDH, ECDSA) prohibited for NSS
Note the framing: January 2027 is when PQC is *required* — not when the migration *starts*. A federal contractor or defence supplier whose platform isn't PQC-capable by Dec 2026 will fail authorisation reviews in 2027.
The same dynamic propagates outward: organisations selling to federal customers must be PQC-capable by Dec 2026. Organisations selling to those organisations must be PQC-capable shortly after. The supply chain ripples mean the practical deadline for many commercial vendors is closer to mid-2026 than January 2027.
Adjacent regulatory pressure: FedRAMP, MAS TRM, PCI DSS, PDPA
CNSA 2.0 is the most explicit deadline, but it's not the only regulatory pressure:
- FedRAMP authorisations increasingly reference CNSA 2.0 alignment as evaluators recognise that FIPS 140-3 module validation for ML-KEM / ML-DSA / SLH-DSA is imminent.
- Singapore's MAS Technology Risk Management Guidelines (Jan 2021) require 'robust and sound cryptographic algorithms.' Once NIST PQC standards finalised, MAS-regulated financial institutions are expected to incorporate them.
- PCI DSS v4.0.1 raises cryptographic-agility expectations. While PCI doesn't explicitly mandate PQC yet, the next revision is widely expected to.
- GDPR Article 32 requires 'appropriate technical and organisational measures' for personal-data security. A 2030 GDPR enforcement action against a controller using classical-only crypto in 2030 is plausible.
What the actual deadline means for engineering teams
If your platform has a 12-18 month engineering lead time on cryptographic changes (typical for regulated SaaS), here's the back-of-envelope math:
Engineering start: now (May 2026) — inventory + design
Parallel deployment: Q3 2026 — hybrid TLS, PQC-capable KMS, dual-provider verification
Customer migration: Q4 2026 — early adopters move to PQC tier
Compliance evidence: Q1 2027 — evidence packs for FedRAMP / CNSA 2.0 audits
In other words, if you're starting the migration in May 2026, you're on schedule. If you're starting in January 2027, you're a year behind. If you're starting in 2028, you missed the deadline that determines whether your platform can sell to federal / regulated customers in 2027.
The honest version: you don't have to do this alone
Most security platforms now offer some PQC capability. The credibility question — which we covered in 'Five PQC Vendor Red Flags' — is whether their PQC story is real or marketing-layer.
QNSP exists because building this from scratch inside an organisation requires a year of engineering work that isn't your core business. We provide the PQC platform layer (KMS, vault, audit, edge gateway, dual-provider cross-verification, framework-level compliance mapping) as managed infrastructure, so your engineering team can focus on the application-specific migration work that nobody else can do for you.