Post-Quantum Cryptography Explained: What Every Security Team Needs to Know

Why Quantum Computers Break Today’s Encryption

The encryption protecting your banking data, health records, and classified communications is built on mathematical problems that classical computers cannot solve in any reasonable timeframe. RSA relies on the difficulty of factoring large numbers. Elliptic-curve cryptography (ECC) relies on the discrete logarithm problem. Both feel impenetrable — until you hand the problem to a quantum computer.

Shor’s algorithm, published in 1994, shows that a sufficiently powerful quantum computer can factor large numbers and solve discrete logarithms in polynomial time — collapsing decades of cryptographic assumptions in a single blow. RSA-2048, considered secure until the 2030s against classical attack, would fall in hours under a capable quantum machine.

This is not science fiction. IBM, Google, and government agencies worldwide are racing toward Cryptographically Relevant Quantum Computers (CRQCs). The National Institute of Standards and Technology (NIST) has already finalized post-quantum standards in anticipation.

---

The Harvest Now, Decrypt Later (HNDL) Threat

Here is the timeline that makes this urgent today, even before CRQCs exist:

An adversary can capture encrypted traffic now and decrypt it later, once quantum computers are capable.

Nation-state threat actors are almost certainly harvesting TLS sessions, VPN traffic, and encrypted email archives today. Any secret that must remain confidential for 10+ years is already at risk.

The data most exposed to HNDL attacks:

• Long-lived government secrets and diplomatic communications
• Medical records (HIPAA requires 6+ years; actual records persist for decades)
• Financial transaction archives and audit trails
• Intellectual property and trade secrets
• Long-duration contracts and legal documents

If your TLS sessions use RSA or ECDH key exchange with no post-quantum hybrid, those sessions are fair game.

---

What NIST Finalized

In August 2024, NIST published three final Post-Quantum Cryptographic standards under Federal Information Processing Standards (FIPS):

FIPS 203 — ML-KEM (Module-Lattice Key Encapsulation Mechanism)

Formerly CRYSTALS-Kyber

The primary replacement for RSA and ECDH key exchange. Based on the hardness of the Module Learning with Errors (MLWE) problem. Parameter sets:

Variant	Security Level	Public Key Size	Ciphertext Size
ML-KEM-512	128-bit	800 bytes	768 bytes
ML-KEM-768	192-bit	1184 bytes	1088 bytes
ML-KEM-1024	256-bit	1568 bytes	1568 bytes

Recommendation: ML-KEM-768 for most enterprise use cases.

FIPS 204 — ML-DSA (Module-Lattice Digital Signature Algorithm)

Formerly CRYSTALS-Dilithium

The primary replacement for RSA-PSS and ECDSA signing. Also lattice-based.

FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)

Formerly SPHINCS+

A hash-based signature scheme — conservative choice for systems requiring long-term verifiability. Larger signatures but security relies only on hash function security.

---

The Transition Challenge at Enterprise Scale

Understanding the algorithms is the easy part. The hard part is finding every place you use vulnerable cryptography — and there are far more places than most security teams expect.

A typical enterprise has cryptographic assets scattered across:

• Source code: hardcoded algorithms, library calls, key generation logic
• Dependencies: third-party packages with embedded crypto (SSL/TLS, JWT, JOSE, bcrypt, OpenSSL wrappers)
• TLS endpoints: web servers, APIs, load balancers, CDN configurations
• Infrastructure-as-Code: Terraform KMS resources, CloudFront TLS policies, ACM certificates
• Cloud key management: AWS KMS keys, Azure Key Vault, GCP Cloud KMS, HashiCorp Vault
• SSH servers: host key algorithms, accepted key exchange methods
• CI/CD pipelines: signing keys, artifact verification, secrets management
• HSMs and hardware: firmware, key storage, algorithm support matrices

Quantizant’s discovery engine finds all of these automatically, building a complete CycloneDX CBOM (Cryptographic Bill of Materials) that serves as your single source of truth for transition planning.

---

Where to Start: The Crypto Inventory

Before you can transition, you need to know what you have. This is the step most organizations skip — and then discover they have far more surface area than anticipated when a deadline appears.

# Install the CLI
brew install quantizant/tap/qtz-discovery-cli

# Scan your codebase (outputs a CBOM)
qtz-discovery-cli scan source ./my-repo --format cbom --output cbom.json --show-score

# Scan your live TLS endpoints
qtz-discovery-cli scan network api.example.com:443 --format table

# Inventory your AWS KMS keys
qtz-discovery-cli scan infra --provider aws --region us-east-1

The output tells you exactly which assets are VULNERABLE, PARTIAL, HYBRID, or SAFE — and a transition readiness score from 0 to 100.

---

The Transition Approach: Hybrid First

For most enterprises, the transition looks like this:

1. Inventory — Build a complete CBOM across code, network, cloud, and runtime
2. Prioritize — Focus on HNDL-exposed endpoints and long-lived secrets first
3. Pilot hybrid — Deploy classical+PQC hybrid mode (X25519MLKEM768 for TLS key exchange) to major endpoints; this protects against HNDL while maintaining backward compatibility
4. Transition signing — Replace RSA/ECDSA signatures with ML-DSA or SLH-DSA
5. Retire legacy — Disable TLS 1.2 ECDH and RSA key exchange ciphers
6. Prove compliance — Generate NIST FIPS 140-3 and MAS TRM compliance reports

The Quantizant platform automates steps 3–6 via a sidecar proxy that performs zero-downtime algorithm hot-swap with no application code changes required.

---

The 2030 Deadline Is Not the Actual Deadline

NIST guidance says agencies should complete PQC transition by 2030. Many enterprises interpret this as “we have until 2030.” That framing misunderstands the timeline:

• 2024: NIST standards published — transition clock starts
• 2026–2028: Regulators issue compliance mandates with teeth (MAS TRM already references PQC readiness)
• 2027–2029: Major cloud providers and browsers begin deprecating classical-only TLS
• 2030: NIST deadline — agencies that haven’t transitioned face audit failures and contract terminations
• 2030+: CRQC capability — retroactively decryptable HNDL archives become exploitable

The actual hard deadline for starting is now — because enterprises with 10,000+ cryptographic assets will need 2–4 years of phased transition. Starting in 2028 means finishing in 2032.

---

Key Takeaways

1. Quantum computers that break RSA and ECC are coming — and the “Harvest Now, Decrypt Later” threat is active today.
2. NIST has finalized three PQC algorithms: ML-KEM (key exchange), ML-DSA, and SLH-DSA (signatures).
3. The transition challenge is primarily a discovery and inventory problem — most organizations don’t know what cryptographic assets they have.
4. Start with a crypto inventory. Everything else follows from knowing your surface area.
5. The practical 2030 deadline means transition must start now for any enterprise with significant cryptographic footprint.

---

Ready to find out what’s in your cryptographic estate? Download qtz-discovery-cli for free and run your first scan in under five minutes.