How Quantum Computing Will Transform Encryption—and Your Data

Quantum computing won’t just make some workloads faster—it will upend how we protect information. The future of data security hinges on how quickly organizations move from today’s public-key cryptography to quantum-resistant methods, redesign their systems for crypto-agility, and manage the messy reality of migrations at Internet scale. This article explains where quantum risk comes from, what the next-generation building blocks look like, and—most importantly—how to start transitioning now without breaking the business.

Disclaimer: This article is for educational purposes only and does not constitute legal, regulatory, or security advice. For decisions that affect your organization’s risk posture, consult qualified professionals.

Key takeaways

• Why change is inevitable: Certain quantum algorithms can break widely used public-key schemes, forcing a move to quantum-resistant cryptography and hybrid deployments during the transition.
• What’s standard today: The first wave of post-quantum standards is finalized, including a key encapsulation mechanism and two digital signature families, with more candidates advancing.
• How to start safely: Build a cryptographic inventory, prioritize by secrecy lifetime and exposure, and pilot hybrid key agreement in transport and VPN stacks.
• Performance & UX matter: Expect larger handshakes and modest latency increases for some connections; test, measure, and tune to preserve customer experience.
• Operational playbook: Treat the migration like a multi-year program—governance, vendor management, crypto-agile software, continuous testing, and clear KPIs.
• Don’t forget the archives: “Harvest-now, decrypt-later” means old encrypted data and backups may require re-protection with quantum-safe methods.

Why quantum changes encryption (and what that means for you)

What it is & why it matters.
Two landmark quantum algorithms drive the threat. One efficiently factors large integers and solves discrete logarithms, undermining common public-key systems used for key exchange and digital signatures. Another speeds up brute-force search, roughly halving the effective security of symmetric keys. In plain terms: the bedrock for key exchange and signatures is at risk; symmetric crypto mostly needs longer keys and careful hashing choices.

Benefits of acting early.
Moving now protects data with long confidentiality lifetimes from “harvest-now, decrypt-later” adversaries, shrinks rush-migration risk, and avoids vendor lock-in by standardizing on crypto-agile designs.

Requirements & low-cost alternatives.

• Baseline requirements:
  • An up-to-date asset and data inventory (apps, protocols, libraries, HSMs, PKI, archives).
  • Build pipelines capable of swapping cryptographic libraries without touching business logic.
  • Test environments that can run dual-stack (classical + post-quantum) handshakes.
• Budget-friendly alternatives:
  • Start with discovery tooling and an inventory spreadsheet even if automated scans aren’t ready.
  • Pilot on a single externally facing service before broad rollout.
  • Use vendor-provided beta channels for hybrid handshakes to learn quickly.

Step-by-step for beginners.

1. Map critical crypto: List where public-key crypto is used (TLS, VPNs, code signing, S/MIME, document signing, identity, update servers).
2. Classify data by secrecy lifetime: Identify data that must remain confidential for 5, 10, or 20+ years.
3. Pick initial pilots: Choose one TLS-terminated service and one site-to-site VPN.
4. Introduce crypto-abstraction: Wrap cryptographic calls behind interfaces to swap algorithms later.
5. Stand up a test endpoint: Enable a hybrid key agreement in non-production and measure handshake size and latency.
6. Add monitoring & rollback: Track handshake failures, fallback rates, and error logs; ensure an immediate revert path.

Beginner modifications & progressions.

• Simplify: Start with client-controlled experiments (staging front end to a canary API).
• Scale up: Expand to multiple regions, then customer-facing traffic with opt-in flags, then default-on for compatible clients.

Recommended frequency/duration/metrics.

• Cadence: Quarterly crypto reviews; monthly inventory refresh; per-release regression tests.
• KPIs: % endpoints supporting hybrid or post-quantum key agreement; TLS handshake success rate; median handshake latency; % long-lived data re-encrypted.

Safety, caveats & common mistakes.

• Don’t announce a cutover date before verifying client compatibility.
• Avoid mixing unvetted libraries; rely on implementations aligned with published standards.
• Don’t treat symmetric crypto as unaffected—evaluate key sizes and hash functions.

Mini-plan (example).

• This week: Inventory TLS and VPN endpoints.
• Next week: Launch a dev/staging hybrid handshake test and capture perf metrics.

The new cryptographic building blocks you’ll actually use

What it is & why it matters.
The first three post-quantum standards are finalized: a module-lattice KEM for key establishment and two digital signature families—one lattice-based, one stateless hash-based. Official nomenclature refers to them as ML-KEM (derived from CRYSTALS-Kyber), ML-DSA (derived from CRYSTALS-Dilithium), and SLH-DSA (derived from SPHINCS+). Additional work continues on further KEM options; one code-based scheme advanced in 2025, diversifying the portfolio.

Core benefits.

• Drop-in for public-key roles: ML-KEM replaces key exchange; ML-DSA/SLH-DSA replace signatures.
• Defense in depth: Two signature families with very different assumptions reduce correlated failure risk.
• Compatibility path: Designed to fit today’s protocols and networks.

Requirements & low-cost alternatives.

• Requirements: Modern TLS/IPsec stacks; updated crypto libraries; PKI tooling capable of new OIDs and certificate profiles.
• Low-cost: Start with hybrid deployments that pair ML-KEM with an established elliptic-curve method to maintain compatibility during rollout.

Step-by-step for beginners.

1. Library readiness check: Confirm your language/runtime has stable ML-KEM and ML-DSA/SLH-DSA support.
2. PKI testbed: Stand up a parallel issuing path for post-quantum certificates (even if not yet deployed to production).
3. Protocol handshake demo: Prove hybrid key agreement in a lab between a modern client and server.
4. Signature pilot: Evaluate ML-DSA for software signing; try SLH-DSA where conservative assurance is desired despite larger signatures.

Beginner modifications & progressions.

• Start small: Sign one internal artifact (e.g., nightly build) with ML-DSA in addition to your current signature.
• Progress: Expand to container images, firmware bundles, then external software updates.

Recommended frequency/duration/metrics.

• Cadence: Monthly library updates; quarterly PKI issuance drills.
• KPIs: Number of services with ML-KEM support; % of artifacts dual-signed; certificate validation success rates.

Safety, caveats & common mistakes.

• Be prepared for larger keys and signatures compared to current algorithms.
• Validate certificate chain sizes don’t exceed protocol or device limits.
• Keep fallback mechanisms during early adoption to avoid bricking devices or cutting off customers.

Mini-plan (example).

• This week: Add ML-KEM to a test TLS endpoint behind a feature flag.
• Next week: Dual-sign one internal release with ML-DSA and verify downstream tooling.

Build crypto-agility into your stack (so this isn’t painful again)

What it is & why it matters.
Crypto-agility means you can swap algorithms, parameters, and libraries without rewriting applications. It’s your insurance policy against future breakthroughs and implementation bugs.

Benefits.
Shorter upgrade cycles, reduced vendor lock-in, and safer experimentation with hybrid or new algorithms.

Requirements & low-cost alternatives.

• Requirements:
  • A cryptographic bill of materials (C-BOM) per application or service.
  • Abstraction layers around crypto operations; no hard-coded algorithm choices.
  • Centralized policy that maps security levels to acceptable algorithms.
• Low-cost: Start by documenting where crypto is called in code and move those calls behind a single module.

Step-by-step for beginners.

1. Create a C-BOM: For each service, list algorithms, key lengths, libraries, and endpoints.
2. Refactor: Introduce crypto_provider interfaces and configuration-driven algorithm selection.
3. Policy as code: Encode allowed suites per environment (dev, staging, prod).
4. Testing: Add unit tests that run the same flow with classical, hybrid, and post-quantum settings.

Beginner modifications & progressions.

• Start with one microservice that terminates TLS and one that performs signing.
• Progress to a shared library consumed by all services.

Recommended frequency/duration/metrics.

• Cadence: Quarterly policy reviews; per-release compliance checks.
• KPIs: % services behind crypto abstraction; time to change an algorithm; number of hard-coded crypto calls eliminated.

Safety, caveats & common mistakes.

• Avoid silent fallback that hides incompatibilities.
• Don’t pin versions that block security updates.
• Ensure reproducible builds for signed artifacts.

Mini-plan (example).

• This week: Ship a minimal interface that centralizes all crypto calls in one service.
• Next week: Add config flags to flip between classical, hybrid, and post-quantum suites.

Prioritize by secrecy lifetime and exposure (defend against “harvest-now, decrypt-later”)

What it is & why it matters.
Adversaries may record encrypted traffic today and decrypt it years later when quantum resources are available. Data with long confidentiality requirements—personal records, trade secrets, national-scale infrastructure data—should be prioritized.

Benefits.
You reduce your most consequential risk first and build credibility with stakeholders.

Requirements & low-cost alternatives.

• Requirements: Data classification framework; retention and archival policies; inventory of where long-lived data moves and rests.
• Low-cost: A spreadsheet mapping systems to secrecy lifetime estimates and exposure level (public Internet vs. internal).

Step-by-step for beginners.

1. Define secrecy lifetimes: 0–2 years, 3–7, 8–20, 20+.
2. Tag systems & datasets: Especially backups, logs, and replicated storage.
3. Map flows: Identify where long-lived data crosses public networks or third-party processors.
4. Choose controls: Prioritize hybrid key agreement and strong symmetric settings on long-lived paths; consider re-encrypting archives.

Beginner modifications & progressions.

• Simplify: Focus on three systems: external web, site-to-site VPN, backup pipeline.
• Progress: Extend to email, document signing, and software update channels.

Recommended frequency/duration/metrics.

• Cadence: Biannual reassessment as systems evolve.
• KPIs: % long-lived data paths using hybrid/post-quantum key agreement; % archives re-encrypted; % vendors contractually committed to timelines.

Safety, caveats & common mistakes.

• Don’t ignore metadata (e.g., DNS queries or headers) that can leak sensitive patterns even when payloads are protected.
• Validate off-site backup solutions for key rotation and re-encryption capabilities.

Mini-plan (example).

• This week: Flag data sets with 7+ year secrecy and list their network paths.
• Next week: Pilot re-encryption of a small archival set with stronger symmetric parameters and updated key management.

Deploy hybrid key agreement in transport and VPNs

What it is & why it matters.
Hybrid key agreement combines a post-quantum KEM (such as ML-KEM-768) with a classical elliptic-curve method (such as X25519) to derive session secrets. If either component remains secure, the session key stays safe.

Benefits.
Best of both worlds—quantum resilience with a safety net while the community hardens new implementations.

Requirements & low-cost alternatives.

• Requirements: TLS 1.3 stacks or reverse proxies that support hybrid groups; VPN gear or software that supports multi-key-exchange in IKEv2; updated cryptographic libraries on both ends; monitoring.
• Low-cost: Start with software-only stacks and modern browsers/clients that already support hybrid handshakes.

Step-by-step for beginners (TLS).

1. Enable hybrid on a staging endpoint: Choose a hybrid named group pairing ML-KEM-768 with a common curve.
2. Collect metrics: Measure handshake size, split packets, latency, failure modes, and fallback rates.
3. Progressive rollout: Canary to 1–5% of traffic, then ramp.
4. Certificate path: Keep your current certificate chain; hybrid affects key agreement, not server certs.

Step-by-step for beginners (VPN/IPsec).

1. Turn on multiple key exchanges: Configure IKEv2 to accept an additional ML-KEM exchange layered with your existing method.
2. Validate rekey behavior: Test IKE rekey and Child SA rekeys with hybrid material added.
3. Monitor fragmentation: Larger messages may trigger fragmentation; tune MTU/MSS accordingly.

Beginner modifications & progressions.

• TLS: Start with a single region or internal admin portal to minimize risk.
• VPN: Pilot between two controllable gateways before extending to partner tunnels.

Recommended frequency/duration/metrics.

• Cadence: Weekly canary reviews during rollout.
• KPIs: Handshake success rate; median and p95 TLS latency; % traffic negotiated with hybrid groups; VPN tunnel stability and rekey success.

Safety, caveats & common mistakes.

• Expect larger handshakes and a slight latency increase in some environments; plan for bandwidth/packetization effects. Measurements from a widely used desktop browser indicated around a four-percent median increase due to bigger ClientHello messages.
• Avoid enabling hybrid everywhere at once; some middleboxes mishandle larger handshakes.
• Ensure logging and dashboards distinguish between classical, hybrid, and post-quantum sessions.

Mini-plan (example).

• This week: Enable hybrid on a staging web endpoint and a lab VPN.
• Next week: Canary 1% of production web traffic, watch handshake size and latency, and fix any path MTU issues.

Upgrade the rest of the stack: applications, signatures, and data at rest

What it is & why it matters.
Transport is only one layer. You also sign code and documents, exchange email, push firmware, and store years of backups. Each path needs a quantum-ready plan.

Benefits.
Consistent protection across endpoints, supply chains, and archives—reducing weak links.

Requirements & low-cost alternatives.

• Requirements: Tooling that can parse and validate new signature schemes; updated HSM/secure-module firmware or software; support for larger certificate chains where applicable.
• Low-cost: Begin with dual-signing (classical + ML-DSA or SLH-DSA) for internal artifacts to validate pipeline compatibility.

Step-by-step cheat-sheet by area.

• Software/code signing:
  1. Add a post-quantum signature to internal builds (container images, packages, firmware).
  2. Update verifiers in CI/CD and deployment to accept dual signatures.
  3. Roll out to customer-facing updates after successful pilots.
• Email & documents:
  1. Enable post-quantum signatures for S/MIME or document workflows where supported.
  2. Prepare for larger signatures; test viewer compatibility.
  3. Maintain classical compatibility for recipients not yet upgraded.
• Identity & authentication:
  1. Catalogue where public-key credentials live (smart cards, passkeys, SSH).
  2. Track emerging support for post-quantum credential formats; avoid hard dependencies on legacy-only tokens.
  3. Use hybrid or transitional modes where available.
• Databases and storage:
  1. Review symmetric crypto parameters; use strong key lengths and modern hash-based KDFs.
  2. Plan re-encryption of archives with updated key management.
  3. Ensure backup/restore procedures preserve new key metadata.

Beginner modifications & progressions.

• Start with internal artifacts where you control both signing and verification.
• Progress to customer-distributed artifacts after telemetry shows stable verification.

Recommended frequency/duration/metrics.

• Cadence: Quarterly feature reviews with security and platform owners.
• KPIs: % artifacts dual-signed; % endpoints able to verify; % archives re-protected.

Safety, caveats & common mistakes.

• Don’t assume older HSMs can handle new schemes; confirm firmware support.
• Watch for size limits in package registries, signing formats, and PDF viewers.
• Maintain clear provenance and transparency logs to help customers trust the new signatures.

Mini-plan (example).

• This week: Dual-sign one internal container image and verify in CI.
• Next week: Pilot dual-signed OTA update in a small internal device fleet.

Testing, performance, and monitoring without surprises

What it is & why it matters.
Post-quantum handshakes are bigger. Some clients or middleboxes won’t behave the same. You need data to prove the user experience stays smooth.

Benefits.
Evidence-based tuning, fewer outages, and happier customers.

Requirements & low-cost alternatives.

• Requirements: Synthetic probes, real-user monitoring, TLS analytics, VPN telemetry, and packet captures for debugging.
• Low-cost: Start with a single synthetic probe from multiple regions and a basic handshake histogram.

Step-by-step for beginners.

1. Define baselines: Measure handshake size, latency, and success before changes.
2. Add tags: Label connections by negotiated key agreement to slice metrics.
3. Tune packetization: If ClientHello splits across packets, test TCP settings and consider early hints or compression where safe.
4. Iterate: Try different parameter sets (e.g., ML-KEM-768 vs. 512/1024 where appropriate) in non-prod to evaluate trade-offs.

Beginner modifications & progressions.

• Simplify: Start with one browser and one mobile client.
• Progress: Add real-world A/B tests at low traffic percentages.

Recommended frequency/duration/metrics.

• Cadence: Daily checks during pilots; weekly after stabilization.
• KPIs: p50/p95 handshake times, error codes by cipher suite, retransmission rates, tunnel rekey success.

Safety, caveats & common mistakes.

• Don’t enable experimental parameters broadly without a rapid rollback.
• Beware of path MTU issues causing silent drops.

Mini-plan (example).

• This week: Build dashboards for handshake size/latency with labels for classical vs. hybrid.
• Next week: Run a 1% hybrid canary and compare the distributions.

Governance, vendor management, and contracts

What it is & why it matters.
You cannot migrate alone. Cloud vendors, network providers, SaaS platforms, and hardware suppliers all influence timelines.

Benefits.
Procurement power and clear expectations accelerate upgrades while reducing integration risk.

Requirements & low-cost alternatives.

• Requirements: Contract language that mandates post-quantum support within defined windows; vendor-readiness questionnaires; escalation paths.
• Low-cost: A simple addendum for new contracts requiring crypto-agility and a migration roadmap.

Step-by-step for beginners.

1. Add readiness clauses: Require support for ML-KEM and at least one post-quantum signature family, with test access.
2. Ask for telemetry: Vendors should report adoption status and pilot windows.
3. Insist on crypto-agility: Interfaces must avoid hard-coding algorithms.

Beginner modifications & progressions.

• Start with strategic vendors (CDN, identity, email).
• Progress: Extend to every contract that handles long-lived data.

Recommended frequency/duration/metrics.

• Cadence: Semiannual vendor reviews.
• KPIs: % strategic vendors with published PQ roadmaps; % with active pilots; % contract coverage.

Safety, caveats & common mistakes.

• Don’t accept vague “roadmap” language—ask for dates and environments.
• Avoid bespoke algorithms that can’t interoperate.

Mini-plan (example).

• This week: Send a 10-question readiness survey to top 10 vendors.
• Next week: Add crypto-agility clauses to new SOWs.

Quick-start checklist

• Inventory where public-key crypto appears (TLS, VPNs, S/MIME, code signing, firmware, document workflows).
• Classify data by secrecy lifetime and exposure; flag anything ≥7 years.
• Stand up a staging endpoint with a hybrid key agreement and capture latency and failure metrics.
• Dual-sign one internal artifact with a post-quantum signature.
• Introduce crypto-abstraction in one service; remove hard-coded algorithms.
• Notify key vendors and request pilot access and timelines.
• Define KPIs and a dashboard for handshake success, latency, and adoption.

Troubleshooting & common pitfalls

• Handshake fragmentation or failures: Increase initial congestion window cautiously, tune MTU/MSS, and verify middleboxes.
• Certificate chain too large: Use compact intermediate chains, minimize extras, and test embedded device limits.
• Client incompatibility: Maintain classical fallbacks and staged allow-lists; provide clear error messaging.
• HSM doesn’t support new schemes: Use software providers for pilots; plan eventual hardware refresh.
• Build systems break on dual signatures: Update verification steps early; ensure downstream tools can parse new OIDs.
• Under-estimating archives: Plan re-encryption timelines and storage I/O budgets for large datasets.

How to measure progress

• Adoption: % of external TLS connections using hybrid or post-quantum.
• Coverage: % of long-lived data paths upgraded; % vendors committed in contracts.
• Reliability: Handshake success and fallback rates; VPN rekey stability.
• Performance: Median and p95 handshake latency deltas; bandwidth overhead.
• Integrity: % artifacts dual-signed and verified; % endpoints validating new signatures.
• Agility: Mean time to swap an algorithm in a representative service.

A simple 4-week starter plan

Week 1 – Discover & decide

• Build a C-BOM for one Internet-facing service and one site-to-site VPN.
• Classify top three datasets by secrecy lifetime and map where they traverse public networks.
• Pick ML-KEM and one post-quantum signature family for pilots; define KPIs and dashboards.

Week 2 – Prove it works

• Enable a hybrid key agreement on a staging TLS endpoint; run synthetic probes from multiple regions.
• Pilot multiple key exchanges on a lab VPN pair; verify rekey behavior and fragmentation handling.
• Dual-sign a single internal artifact and verify in CI/CD.

Week 3 – Canary & extend

• Roll out hybrid to 1% of production traffic with strict monitoring and automatic rollback.
• Start re-encrypting a small archival dataset using modern symmetric parameters and updated key management.
• Send vendor readiness questionnaires and schedule pilot windows.

Week 4 – Operationalize

• Expand canary to 5–10% if KPIs hold; document runbooks for incidents and rollbacks.
• Add crypto-abstraction to one more service; remove hard-coded algorithm choices.
• Publish an internal roadmap with dates for transport, signatures, and archive upgrades.

FAQs

1) When will quantum computers actually break today’s encryption?
No one can give a reliable date. Plan on the basis of secrecy lifetimes and migration lead times rather than predictions.

2) Do I need to change my symmetric encryption?
Likely not fundamentally—focus on strong key sizes and robust hash/KDF choices. The bigger changes are in key exchange and signatures.

3) Is hybrid key agreement required or optional?
It’s a practical transition strategy. It provides resilience if either the classical or post-quantum component is compromised.

4) Which post-quantum signature should I pick?
Use a lattice-based option for performance where size fits, and consider a stateless hash-based option in contexts that value conservative assumptions and can tolerate larger signatures. Many organizations deploy both.

5) Will this slow down my website or app?
Handshakes are larger and can slightly increase latency. In widely observed measurements, the median increase was a few percent. Measure in your environment and tune.

6) What about messaging apps—are they already protected?
Some large-scale systems have begun integrating post-quantum protections in key establishment. Treat that as a signal to proceed with your own pilots.

7) Do I need new hardware?
Not necessarily for pilots. Many stacks support the new algorithms in software. Hardware refreshes may be needed for high-throughput signing or verification at scale.

8) Are quantum key distribution networks a replacement for post-quantum cryptography?
No. They can complement, not replace, software-based cryptography. Most organizations should prioritize standardized post-quantum algorithms first.

9) How do I handle partners and vendors who aren’t ready?
Keep classical fallbacks, negotiate timelines in contracts, and use canaries to limit risk. Prioritize connections that handle long-lived data.

10) What should I do about old encrypted archives and backups?
Create a plan to re-encrypt with modern symmetric settings and manage keys accordingly, prioritizing archives with long confidentiality needs.

11) Are these algorithms final and future-proof?
They’re standardized based on extensive analysis, and the portfolio is expanding. Design for crypto-agility so you can adapt if assumptions change.

12) How do I know if my rollout is working?
Monitor handshake success, latency, and adoption rates; verify signatures at scale; and track vendor progress against agreed milestones.

Conclusion

Quantum computing is a once-in-a-generation platform shift for security. The path forward is clear: adopt the new building blocks, deploy hybrid handshakes, make software crypto-agile, and re-protect long-lived data. Organizations that start now will protect today’s secrets, minimize disruption later, and build a stronger security culture along the way.

Call to action: Start a one-service pilot this week—enable a hybrid key agreement on a staging endpoint, measure the impact, and turn your findings into a 90-day migration plan.

References

1. Module-Lattice-Based Key-Encapsulation Mechanism Standard (FIPS 203), National Institute of Standards and Technology (NIST), August 13, 2024. https://csrc.nist.gov/pubs/fips/203/final
2. Module-Lattice-Based Digital Signature Standard (FIPS 204), NIST, August 13, 2024. https://csrc.nist.gov/pubs/fips/204/final
3. Stateless Hash-Based Digital Signature Standard (FIPS 205), NIST, August 13, 2024. https://csrc.nist.gov/pubs/fips/205/final
4. NIST Releases First 3 Finalized Post-Quantum Encryption Standards, NIST News, August 13, 2024. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
5. Workshops and Timeline – Post-Quantum Cryptography, NIST CSRC, (notes selection of HQC on March 11, 2025). https://csrc.nist.gov/projects/post-quantum-cryptography/workshops-and-timeline
6. Memorandum M-23-02: Migrating to Post-Quantum Cryptography, Office of Management and Budget, November 18, 2022. https://www.whitehouse.gov/wp-content/uploads/2022/11/M-23-02-M-Memo-on-Migrating-to-Post-Quantum-Cryptography.pdf
7. Quantum-Readiness: Migration to Post-Quantum Cryptography, CISA/NSA/NIST, August 21, 2023. https://www.cisa.gov/sites/default/files/2023-08/Quantum%20Readiness_Final_CLEAR_508c%20%283%29.pdf
8. Shor, P. W., Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer, SIAM Journal on Computing, 1997. https://epubs.siam.org/doi/10.1137/S0097539795293172
9. Grover, L. K., A Fast Quantum Mechanical Algorithm for Database Search, arXiv, May 29, 1996. https://arxiv.org/abs/quant-ph/9605043
10. Recommendation for Key Management: Part 1 – General (SP 800-57 Part 1 Rev. 5), NIST, 2020. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r5.pdf
11. Frequently Asked Questions about Post-Quantum Cryptography, National Cybersecurity Center of Excellence (NCCoE), Last updated July 14, 2025. https://pages.nist.gov/nccoe-migration-post-quantum-cryptography/FAQ/index.html
12. Advancing Our Amazing Bet on Asymmetric Cryptography, Chromium Blog, May 23, 2024. https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html
13. The State of the Post-Quantum Internet, Cloudflare Blog, March 5, 2024. https://blog.cloudflare.com/pq-2024/
14. Cloudflare Now Uses Post-Quantum Cryptography to Talk to Origins, Cloudflare Blog, September 29, 2023. https://blog.cloudflare.com/post-quantum-to-origins/