The threat isn’t sci-fi. It’s storage.
When people hear “post-quantum cryptography,” they picture a lab somewhere flipping a switch and every VPN falling over at once. That framing is wrong in two ways.
First, nobody knows the exact date a cryptographically relevant quantum computer arrives. Second, for a large class of data, you don’t need that date to feel pain. If someone can record encrypted traffic or steal encrypted databases now, they can decrypt later. CISA, NSA, and NIST call this out directly in their quantum-readiness guidance: attackers may already target data with a long secrecy lifetime using harvest-now / decrypt-later operations.
I’ve lived the other side of that problem in IT and data protection work. The hard part is rarely “does AES still work?” Symmetric crypto ages more gracefully under quantum pressure (you mainly need larger keys and good operational hygiene). The brittle layer is public-key: key exchange and signatures—the glue of TLS handshakes, code signing, certificates, identity federation, and secure boot chains.
If that glue fails in ten years, the damage isn’t theoretical for:
- Health records and legal discovery archives
- Long-term source control and signed firmware
- Executive communications and M&A due diligence
- Anything you’ve promised “confidential for the life of the relationship”
That’s why Gartner-style risk narratives in the market keep landing on the same punchline: treat PQC as a present migration program, not a research curiosity. Even when the primary reports sit behind paywalls, the secondary conversation is consistent—harvest now, decrypt later is the near-term story, and crypto agility is the control that survives uncertainty about timelines.
NIST drew a line in 2024. Migration didn’t get easier.
In August 2024, NIST approved three Federal Information Processing Standards for PQC:
- FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), from CRYSTALS-Kyber, primary path for general key establishment
- FIPS 204 — Module-Lattice-Based Digital Signature Algorithm (ML-DSA), from CRYSTALS-Dilithium, primary path for signatures
- FIPS 205 — Stateless Hash-Based Digital Signature Algorithm (SLH-DSA), from SPHINCS+, a hash-based backup approach with different mathematical assumptions
NIST’s broader project page remains the best single door into the program: Post-Quantum Cryptography.
What practitioners should hear is simple: algorithm selection is no longer the blocker for planning. The blockers are inventory, protocol support, certificate lifecycle, performance under new key sizes, and vendors who still ship “crypto as a black box.”
CISA has also pushed product-category thinking for PQC adoption—helping buyers map where standards matter in hardware and software stacks. See CISA’s PQC product categories resource and the joint Quantum-Readiness: Migration to Post-Quantum Cryptography factsheet with NSA and NIST.
Cryptographic agility is the actual CISSP-grade control
If I had to reduce PQC for a board or an exam answer, I wouldn’t start with lattice math. I’d start with agility:
Can we change algorithms, parameter sets, certificates, and libraries across the environment without a multi-year rewrite and without creating a long dual-insecure period?
Agility fails for boring reasons I’ve seen repeatedly:
- Hard-coded algorithms in custom apps (“RSA-2048 only” buried in a jar from 2016)
- Certificate and HSM constraints that assume key types and sizes that PQC breaks
- Protocol versions that can’t negotiate hybrid handshakes cleanly
- Vendor contracts with no crypto upgrade path and no SBOM-level crypto inventory
- Performance surprises—PQC keys and signatures are often larger; that shows up in constrained devices, cert chains, and high-volume auth paths
- Shadow crypto—libraries pulled by developers outside the approved stack
Crypto agility is not a buzzword. It’s change management for algorithms.
What a practical program looks like (no fake maturity scores)
Here’s the sequence I trust because it matches how migrations actually fail and succeed.
1. Inventory before ideology
Find every place public-key crypto appears:
- TLS termination and mutual TLS
- VPN and SSH
- Code signing, package signing, container image signing
- PKI and intermediate CAs
- S/MIME, document signing, timestamping
- Device identity and firmware update channels
- Application-layer JWTs, API client credentials, service meshes
CISA’s guidance is blunt: build a quantum-readiness roadmap, inventory, risk-rank, and engage vendors early. You cannot prioritize what you cannot see.
2. Risk-rank by secrecy lifetime and exposure
Not every RSA cert is equal. Prioritize:
- Data that must remain confidential for many years
- High-value interception surfaces (internet-facing key exchange)
- Systems that are expensive or slow to patch (OT-adjacent, appliances, embedded)
- Dependencies you don’t control (SaaS, managed PKI, third-party APIs)
3. Prefer hybrid transitions where the ecosystem supports them
Many organizations will run classical + PQC in parallel for a period—not because it’s elegant, but because interoperability is uneven. Hybrid approaches reduce “all eggs in one new algorithm” risk while standards and products stabilize. The tradeoff is complexity: more code paths, more test surface, more things for ops to misconfigure.
4. Demand agility in procurement language
If a vendor cannot answer:
- Which algorithms are supported today?
- What’s the roadmap for ML-KEM / ML-DSA / SLH-DSA?
- How are algorithm suites configured without a full product rewrite?
- How do certificates and keys rotate under new parameter sets?
…then you are buying tomorrow’s technical debt.
5. Test like you mean it
Lab the handshake failures. Lab the certificate size issues. Lab the HSM firmware constraints. Lab the monitoring blind spots when ciphersuites change. Crypto migrations die in edge cases, not in architecture decks.
Where CISSP thinking helps (and where it gets you in trouble)
Domain-wise, this sits at the intersection of cryptography, asset security, security architecture, and supply chain. The exam-friendly idea is still true in production: encryption is only as good as key management, algorithm choice, and implementation.
Where CISSP-style thinking can mislead is treating “approved algorithm list” as the finish line. In operations, the finish line is:
- You can prove what crypto you run
- You can change it under change control
- You can detect drift when someone reintroduces weak suites
- You can recover when a parameter set or library is deprecated
That’s governance, not a weekend patch.
Operational friction I expect you to feel
Be honest with leadership about the ugly parts:
- Your CMDB will be wrong about crypto.
- Your “standard image” will contain three TLS stacks.
- Legal will ask whether historical archives need re-encryption (sometimes yes for high-value long-lived data at rest; often the bigger fight is transport and key exchange going forward).
- Budget owners will want a single migration year. Realistically you’ll have waves by system class.
- Security teams will over-focus on quantum headlines while leaving basic cert hygiene broken. Fix both.
Also: quantum risk does not excuse ignoring classical failures. Misconfigured TLS, poor key storage, and weak identity still dominate day-to-day breach paths. PQC is additive urgency, not a replacement for fundamentals.
A simple decision rule for data protection practitioners
If I were briefing a Canadian media or enterprise privacy team tomorrow, I’d use this rule:
- If the confidentiality requirement outlives the expected safe life of current public-key crypto, treat HNDL as in-scope today.
- If the system cannot swap algorithms without a project the size of a platform rewrite, fund agility before you fund brand-name PQC products.
- If vendors own the crypto, put migration milestones in the contract—not in a hope slide.
Sources worth keeping open
- NIST PQC project: https://csrc.nist.gov/projects/post-quantum-cryptography
- NIST announcement of FIPS 203/204/205: https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved
- FIPS 203 / 204 / 205 finals: FIPS 203, FIPS 204, FIPS 205
- CISA/NSA/NIST quantum-readiness factsheet: Quantum Readiness PDF
- CISA PQC product categories: Product categories for PQC technologies
- CISA Post-Quantum Cryptography Initiative hub: https://www.cisa.gov/quantum
Secondary market narrative (Gartner urgency, HNDL framing) is widely reflected in practitioner and vendor discussions of Gartner’s PQC preparation messaging—use primary NIST/CISA texts for decisions, and treat analyst summaries as prioritization pressure, not as technical specs.
Actionable takeaway
Post-quantum readiness is less about predicting the first useful quantum computer and more about whether your organization can change cryptography on purpose. Harvest-now-decrypt-later makes long-lived secrecy a present risk. NIST’s 2024 standards removed the “no algorithms yet” stall. The work left is inventory, hybrid migration, vendor pressure, and true cryptographic agility—so when the next algorithm swap comes (and it will), you’re not starting from a spreadsheet and a prayer.