Post-Quantum Cryptography Explained: A Beginner's Guide for Professionals

Almost every secure digital interaction you had today relied on a mathematical assumption that has a known expiry date. When your browser opened an HTTPS connection, when your phone verified a software update, when your bank confirmed a payment instruction, the underlying trust came from public-key cryptography — RSA or elliptic-curve cryptography (ECC). Both rest on problems that classical computers cannot solve efficiently, but that a sufficiently large, fault-tolerant quantum computer could, using an algorithm published in 1994 (Shor, 1994).

No such machine exists today. What has changed is that the transition away from those algorithms is no longer a research topic — it is a scheduled infrastructure programme with published standards, government deadlines and procurement consequences. The United States finalised its first post-quantum standards in August 2024. The European Union adopted a coordinated migration roadmap in June 2025. In June 2026, a U.S. executive order converted advisory timelines into binding dates for federal agencies and, indirectly, for the vendors that sell to them.

This guide is written for professionals who need a working understanding rather than a cryptographer's one: security and IT leaders, developers, architects, compliance and procurement officers, healthcare and financial-services staff handling long-lived sensitive data, and students entering the field. It assumes no prior knowledge of quantum mechanics or lattice mathematics.

By the end you will understand what quantum computing actually threatens (and what it does not), which algorithms have replaced the old ones, why "harvest now, decrypt later" changes the urgency calculation, what the current deadlines are across major jurisdictions, where the genuinely hard engineering problems remain, and what a defensible first 90 days of work looks like.

---

Executive summary

• The threat is specific, not general. Quantum computing primarily breaks public-key cryptography (RSA, ECC, Diffie-Hellman). Symmetric encryption such as AES-256 and modern hash functions remain broadly viable, with parameter adjustments.
• The replacement algorithms are standardised. NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) on 13 August 2024. These three are the stable baseline; HQC and FN-DSA (FIPS 206) are selected but not yet final (NIST, 2024a–c; NIST, n.d.).
• Urgency comes from data lifetime, not from machine availability. Under "harvest now, decrypt later," encrypted traffic captured today can be decrypted after a capable quantum computer exists. Anything that must stay confidential into the 2030s is already exposed.
• Resource estimates have fallen sharply. A 2025 Google Quantum AI analysis lowered the estimated cost of factoring RSA-2048 from roughly 20 million noisy qubits to fewer than one million, under stated hardware assumptions (Gidney, 2025). This is an estimate, not a demonstration — but it is the direction of travel.
• Deadlines now exist. U.S. federal high-value systems must migrate key establishment by 31 December 2030 and digital signatures by 31 December 2031 (The White House, 2026). The EU targets high-risk use cases by 2030 and broad completion by 2035; the UK NCSC sets 2028, 2031 and 2035 milestones.
• Encryption is far ahead of authentication. More than two-thirds of browser traffic reaching Cloudflare's network used post-quantum key agreement by June 2026 (Goldberg & Voci, 2026). Post-quantum certificates are still a work in progress.
• Size, not speed, is the main engineering obstacle. ML-DSA-44 signatures are roughly 2,420 bytes against 64 bytes for ECDSA P-256 — enough to push a TLS handshake past sizes where real-world connections start failing (Let's Encrypt, 2026).
• Hybrid deployment is the current consensus. Combining a classical and a post-quantum algorithm means an attacker must break both. This is what X25519MLKEM768 does in TLS 1.3.
• Crypto-agility is the durable lesson. The specific algorithms may change again; the ability to swap them via configuration rather than re-architecture is the capability worth building.

---

What quantum computers actually break

Public-key cryptography works because certain mathematical operations are easy in one direction and impractical to reverse. RSA depends on the difficulty of factoring large integers; ECC and Diffie-Hellman depend on the discrete logarithm problem. Shor's algorithm (1994) solves both classes efficiently on a quantum computer, which collapses the security of every system built on them.

A second quantum algorithm, Grover's search (Grover, 1996), offers a quadratic speed-up against symmetric ciphers. This is far less damaging: it roughly halves the effective security level, so AES-128 weakens toward a 64-bit-equivalent search while AES-256 remains comfortable. Cryptographers also note that Grover's algorithm parallelises poorly, which further limits its practical value to an attacker.

Table 1 — What is and is not at risk (original OneWise analysis)

The single most useful mental correction for newcomers: this is not "encryption is broken." It is "the part of the system that establishes trust between strangers is broken, and the part that scrambles the data is mostly fine."

---

Why the deadline is earlier than the threat

The counter-intuitive part of post-quantum planning is that you cannot wait for the machine to exist. Three intervals matter:

1. How long your data must stay confidential (a health record, a diplomatic cable, a genome, a 30-year mortgage file).
2. How long your migration will take — typically measured in years for large estates.
3. How long until a cryptographically relevant quantum computer (CRQC) exists.

If the first two added together exceed the third, data you protect today is already effectively exposed. This planning heuristic is widely associated with the cryptographer Michele Mosca and has become standard framing in national guidance. The attack it describes — recording encrypted traffic now and decrypting it after a CRQC arrives — is known as harvest now, decrypt later (HNDL).

HNDL applies asymmetrically. Confidentiality is retroactively breakable; authentication is not. A forged certificate is only useful in real time, which is why most roadmaps sequence encryption first and signatures second.

Figure 1 — "Harvest now, decrypt later": the three intervals Purpose: explain why migration deadlines precede the arrival of quantum computers. Layout: three horizontal bars on a shared left-aligned timeline starting at "Today (2026)". Bar A (top, blue): "Confidentiality lifetime of the data (X)" extending to ~2040. Bar B (middle, amber): "Time required to migrate (Y)" extending ~2026–2032. Bar C (bottom, grey, offset to start where Bar B ends): "Remaining protected window". A vertical dashed red line labelled "Possible CRQC arrival (Z) — uncertain" sits at roughly 2033, deliberately drawn as a fuzzy band rather than a point. Annotation: a bracket over the region where Bar A extends past the red line, labelled "Exposure gap: data harvested today, readable later." Caption: "Migration deadlines are set by data lifetime plus migration time, not by the arrival date of a quantum computer."

How close is a CRQC? Honest answer: unknown, and forecasts are contested. What can be reported factually is that estimated resource requirements have dropped. Gidney (2025) estimated that RSA-2048 could be factored in under a week by a machine with fewer than one million noisy physical qubits — down from a 2019 estimate of roughly 20 million qubits — assuming a 0.1% gate error rate and a one-microsecond surface-code cycle. Those assumptions still exceed any deployed system, and sustaining fault-tolerant computation at that scale remains an unsolved engineering problem. The correct reading is not "quantum computers are nearly here" but "the target keeps moving toward us, so planning margins should be conservative."

---

The standards: what has actually been finalised

NIST ran an open, international competition beginning in 2016 — the same model that produced AES and SHA-3. Three standards were published on 13 August 2024 and form the current stable baseline.

Table 2 — The NIST post-quantum portfolio as of 4 August 2026 (original OneWise summary)

Two design choices in that table deserve explanation.

Why two KEMs? ML-KEM and HQC rest on different mathematical assumptions. If a structural weakness were ever found in lattice problems, a code-based alternative provides insurance. Diversity is the point, not redundancy.

Why three signature schemes? SLH-DSA's security depends only on hash functions — the most conservative assumption available — but its signatures are large and signing is slow. ML-DSA is the general-purpose default. FN-DSA offers smaller signatures at the cost of a more delicate implementation (floating-point Gaussian sampling, which is unforgiving of side-channel mistakes).

NIST is still expanding the portfolio. On 14 May 2026 it published NIST IR 8610, advancing nine additional signature candidates — FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign and UOV — to a third evaluation round, with updated submission packages due 14 August 2026 (Moody et al., 2026). None of these is a standard, and none should appear in a production plan today.

The cost: size, not speed

For most workloads, post-quantum algorithms are computationally competitive. The problem is bandwidth.

Table 3 — Approximate wire sizes, classical vs post-quantum (original OneWise comparison; figures from IETF and Let's Encrypt documentation)

A typical TLS handshake carries roughly five signatures and two public keys. Replacing all of them naively pushes authentication overhead past 10 KB per connection — large enough that a measurable share of real-world connections fail outright (Let's Encrypt, 2026). This single fact explains most of the current engineering agenda.

---

Hybrid mode: the deployment pattern that won

Rather than swapping RSA for ML-KEM outright, the industry converged on hybrid (or PQ/T, post-quantum/traditional) key agreement: run both a classical and a post-quantum exchange and combine the results, so an attacker must break both.

The reasoning is symmetric hedging. Before 2024, post-quantum algorithms were too new to trust alone. After 2035, classical algorithms should be assumed to contribute nothing. Hybrid protects across both eras.

In TLS 1.3 this is specified by the IETF as X25519MLKEM768, together with two NIST-curve variants. As of publication the specification is at draft revision 05 (26 May 2026), has been approved by the IESG and is in RFC Editor processing — advanced, but not yet an RFC (Kwiatkowski et al., 2026). Teams running pilots should cite the draft version they tested rather than claiming standardised support.

The counter-example is instructive: in IPsec, the absence of an early interoperable standard led vendors to ship incompatible proprietary post-quantum key agreements, delaying migration by years (Goldberg & Voci, 2026). Convergence on a single hybrid group is why TLS moved quickly.

Figure 2 — Hybrid key agreement in a TLS 1.3 handshake Purpose: show non-specialists where post-quantum cryptography sits inside an ordinary HTTPS connection. Layout: two vertical lifelines, "Client" (left) and "Server" (right), with numbered horizontal arrows between them.

1. Client → Server: ClientHello containing a key_share for X25519MLKEM768 — annotate as "1,216 bytes: 1,184-byte ML-KEM encapsulation key + 32-byte X25519 share."
2. Server → Client: ServerHello with its combined share (ML-KEM ciphertext + X25519 share).
3. Both sides (parallel side-boxes): "Derive shared secret = ML-KEM secret ‖ X25519 secret (64 bytes)."
4. Server → Client: Certificate + CertificateVerify — shade this step amber and label "Still classical today — the authentication migration is incomplete."
5. Both: "Application data protected by AES-GCM (symmetric, already quantum-resistant)." Visual hierarchy: steps 1–3 in solid blue (migrated), step 4 in amber (in progress), step 5 in grey (unaffected). Caption: "In a hybrid handshake, key establishment is already post-quantum; certificate authentication is the remaining gap."

---

Two migrations, not one

The most useful structural insight for a newcomer is that "the PQC migration" is really two programmes with different urgencies, maturities and blockers.

Table 4 — Encryption migration vs authentication migration (original OneWise framework)

Adoption data illustrates the gap. Post-quantum encrypted traffic reached about 13% of TLS 1.3 traffic during 2024, roughly 52% by early December 2025, and more than two-thirds of browser traffic to Cloudflare's network by June 2026 (Cloudflare, 2025; Goldberg & Voci, 2026). Client-side adoption was driven by defaults: Chrome in April 2024, Firefox later that year, and Apple's platforms in 2025 — after which national shares jumped within days of OS releases. Server-side and origin support lags considerably; Cloudflare added an origin-support metric to Radar in February 2026 precisely because that gap had become the limiting factor.

Authentication is genuinely harder. On 3 June 2026, Let's Encrypt — which issued a majority of publicly trusted TLS certificates in early 2026 — announced that its path to a post-quantum Web PKI would be Merkle Tree Certificates (MTCs), which amortise one large post-quantum signature across thousands of certificates instead of signing each individually. It is targeting a staging environment in late 2026 and production readiness in 2027 (Let's Encrypt, 2026). In parallel, ML-DSA signatures in conventional X.509 certificates are specified in RFC 9881, which is the likely path for internal PKI, VPNs, mTLS and device authentication. A split ecosystem — MTCs for browsers, X.509 for everything else — is a plausible medium-term outcome, though this remains a forecast rather than a settled fact.

---

Latest developments (as of 4 August 2026)

Established facts are separated below from claims, forecasts and preliminary work.

Established (published, dated, verifiable)

• 22 June 2026 — U.S. executive order. "Securing the Nation Against Advanced Cryptographic Attacks" requires federal High Value Assets and high-impact systems to transition to post-quantum key establishment by 31 December 2030 and post-quantum digital signatures by 31 December 2031. It directs the FAR Council to propose rules requiring covered contractors to comply with post-quantum FIPS by the end of 2030, and directs CISA and NIST to publish minimum elements for a cryptographic bill of materials (CBOM). National Security Systems are excluded and remain on the NSA's separate CNSA 2.0 track (The White House, 2026). Note: secondary sources have cited conflicting executive-order numbers for this instrument; OneWise cites it by title and date pending confirmation in the Federal Register.
• 14 May 2026 — NIST IR 8610. Nine additional signature candidates advanced to a third evaluation round; five (CROSS, LESS, Mirath, PERK, RYDE) were eliminated. Expected to run approximately two years (Moody et al., 2026).
• 3 June 2026 — Let's Encrypt commits to Merkle Tree Certificates, with staging targeted for late 2026 and production for 2027 (Let's Encrypt, 2026).
• 26 May 2026 — draft-ietf-tls-ecdhe-mlkem-05 published; IESG-approved and in RFC Editor processing as of late July 2026 (Kwiatkowski et al., 2026).
• Ongoing — NIST IR 8547 remains an initial public draft. Published 12 November 2024, comments closed 10 January 2025; not finalised as of this article's publication date. Its 2030 deprecation / 2035 disallowance dates are widely used as the planning baseline but are, formally, draft guidance (Moody et al., 2024).

Company claims and organisational targets (credible, but self-reported)

• Cloudflare states it moved its own full post-quantum readiness target to 2029 and reports more than two-thirds post-quantum browser traffic (Goldberg & Voci, 2026). Google has publicly signalled a 2029 migration target for its services.

Preliminary or contested

• Q-Day forecasts. Estimates cluster loosely in the early-to-mid 2030s, but there is no consensus and no empirical basis for a specific year. Resource-estimate improvements (Gidney, 2025) reduce the theoretical bar without demonstrating hardware capable of clearing it.
• The eventual shape of post-quantum Web PKI. MTCs are backed by significant players but are not yet a finished standard.

---

Regional deadlines at a glance

Table 5 — Migration timelines by jurisdiction (original OneWise compilation)

Two observations follow. First, the dates converge: 2030 for priority systems, 2035 for the long tail. Second, none of these instruments binds a typical private company directly — the pressure arrives through procurement, supply-chain requirements and sector regulators rather than through direct mandate.

---

Where organisations go wrong

Frequently misunderstood concepts

• "Quantum-safe" is not a product property you can buy once. A system that supports ML-KEM but still accepts a classical-only handshake is vulnerable to downgrade attacks. Defining what "transitioned" means — supports, prefers, or exclusively uses — is a live problem even in federal guidance (Goldberg & Voci, 2026).
• Quantum key distribution (QKD) is not post-quantum cryptography. QKD is a hardware-based key-exchange method requiring dedicated physical links. Post-quantum cryptography is software, deployable over the existing internet. Several national agencies have declined to recommend QKD for general use.
• Hybrid is not "twice the work forever." It is a transitional combiner, expected to simplify once classical algorithms are disallowed.
• An exhaustive cryptographic inventory is not a prerequisite for action. Discovery projects can consume an entire budget cycle and go stale before completion. Protecting internet-facing traffic can begin immediately, in parallel.

Common mistakes

1. Treating this as a 2030 problem when the confidentiality exposure is present-tense.
2. Migrating encryption and postponing authentication, then discovering the 2031 dependency chain cannot be compressed into one year.
3. Ignoring embedded and operational-technology estates, where firmware may not be updatable at all and replacement cycles run 10–20 years.
4. Hard-coding algorithm choices instead of building crypto-agility — the same mistake that made the SHA-1 and SSLv3 retirements take a decade each.
5. Overlooking long-lived keys: root CAs, code-signing keys and firmware-verification keys have the longest lead times and the highest blast radius.

---

Practical takeaways: a defensible first 90 days

These recommendations are scaled to a mid-sized organisation without a dedicated cryptography team. Larger regulated entities will need formal programme governance; smaller ones can often achieve most of the benefit through vendor selection alone.

Figure 3 — A five-stage post-quantum migration workflow Purpose: give non-specialists a repeatable sequence rather than a checklist. Layout: five left-to-right rounded rectangles connected by solid arrows, with a dashed feedback arrow from stage 5 back to stage 2.

1. Prioritise by impact — "Which data must stay secret past 2035? Which keys have the longest lives?"
2. Protect traffic in bulk — "Enable hybrid key agreement at the edge, VPN and CDN layer."
3. Fix procurement — "Require PQC support, at no premium, with an authentication roadmap."
4. Inventory what remains — "Quantum impact inventory of internal systems and long-lived keys."
5. Plan authentication — "Certificate automation, crypto-agility, PKI re-keying." Side panel (vertical, spanning all five): "Continuous: crypto-agility, standards monitoring, vendor tracking." Caption: "Bulk protection comes before exhaustive inventory — waiting for a complete inventory delays the mitigations that are already available."

For security and IT leaders

• Start with data that crosses the public internet; it is the easiest to harvest and the cheapest to protect.
• Build a quantum impact inventory — what breaks, how badly, and how hard is it to fix — rather than beginning with an exhaustive CBOM.
• Identify long-lived keys first: root and intermediate CAs, code-signing, firmware verification.
• Set an internal target ahead of any external deadline; every published roadmap assumes migrations run late.

For developers and architects

• Use vetted library implementations; never hand-roll lattice arithmetic or Gaussian sampling.
• Isolate algorithm choice behind an abstraction so a swap is a configuration change.
• Test for size: measure handshake growth, MTU and fragmentation behaviour, and constrained-device performance now.
• Automate certificate issuance and renewal — CA/Browser Forum lifetime reductions make this necessary regardless of quantum concerns.

For procurement, compliance and risk

• Add post-quantum support to standard vendor questionnaires, including a dated authentication roadmap.
• Consult CISA's product-category guidance, which distinguishes technologies where post-quantum support is already widely available (cloud platforms, browsers, web servers, messaging, endpoint encryption) from those still transitioning (networking hardware, HSMs, identity systems, email, databases).
• Treat crypto-agility as a contractual requirement, not an aspiration.
• Record the exact standard version, errata state and validation status you tested against; "final" does not mean static.

---

Key insights

1. Quantum computing breaks public-key cryptography specifically — symmetric encryption and hashing survive with parameter changes.
2. Urgency derives from data confidentiality lifetime plus migration duration, not from the arrival date of a quantum computer.
3. FIPS 203, 204 and 205 are the only final NIST post-quantum algorithm standards as of August 2026.
4. HQC and FN-DSA are selected but unfinished; the nine third-round signature candidates are research-stage.
5. Hybrid key agreement is the deployment consensus, because it fails safe in both directions.
6. Post-quantum encryption is majority-deployed on the client side; post-quantum authentication has barely begun.
7. Signature and key size — not computational cost — is the dominant engineering constraint.
8. U.S., EU and UK timelines converge on roughly 2030 for priority systems and 2035 for the remainder.
9. Procurement, not regulation, is how these deadlines will reach most private organisations.
10. Crypto-agility outlasts any specific algorithm and is the most durable investment available.

---

Frequently asked questions

What is post-quantum cryptography in simple terms? Post-quantum cryptography is a set of encryption and digital-signature algorithms that run on ordinary computers but are designed to resist attacks from future quantum computers. It replaces RSA and elliptic-curve cryptography, not AES or SHA-2.

Is post-quantum cryptography the same as quantum cryptography? No. Post-quantum cryptography is classical software. Quantum cryptography — principally quantum key distribution — uses quantum physics and requires specialised hardware and dedicated links.

Do quantum computers exist that can break encryption today? No public evidence suggests any existing machine can break RSA-2048 or ECC. Current devices are far below the required scale and error-correction capability.

What is "harvest now, decrypt later"? An adversary records encrypted traffic today and stores it until a quantum computer can decrypt it. It makes today's confidentiality decisions dependent on future capability.

Which algorithms should I be using? For key establishment, ML-KEM (FIPS 203), usually in a hybrid such as X25519MLKEM768. For signatures, ML-DSA (FIPS 204), with SLH-DSA (FIPS 205) where conservative assumptions matter more than size.

Do I need to replace AES? Not urgently. AES-256 is considered adequate against known quantum attacks. Prefer 256-bit keys for data with long confidentiality requirements.

When is Q-Day? Unknown. Published estimates cluster in the early-to-mid 2030s but are forecasts, not measurements. Plan against data lifetime rather than a predicted date.

What are the actual compliance deadlines? For U.S. federal high-value systems: 31 December 2030 for key establishment and 31 December 2031 for digital signatures. The EU targets high-risk use cases by 2030 and broad completion by 2035; the UK NCSC sets 2028, 2031 and 2035 milestones.

Does this apply to private companies? Not directly in most cases. It reaches private companies through federal contracting rules, sector regulators, customer security requirements and vendor roadmaps.

Why is hybrid mode recommended instead of post-quantum alone? Because an attacker must break both components. It hedges against undiscovered weaknesses in the newer algorithms while retaining protection once classical algorithms are retired.

Why are post-quantum certificates taking longer than post-quantum encryption? Signatures are much larger, and the dependency chain spans clients, servers, certificate authorities, transparency logs, root stores and browsers — all of which must move together.

What is a cryptographic bill of materials (CBOM)? An inventory of the cryptographic algorithms, protocols and implementations in a product, analogous to a software bill of materials. U.S. agencies have been directed to publish minimum-element guidance for CBOMs.

Will post-quantum cryptography slow my applications down? Usually only marginally in compute terms. The measurable effect is larger handshakes and certificates, which matter most on constrained networks and devices.

What is crypto-agility? The ability to change cryptographic algorithms through configuration rather than re-architecture. It is the property that makes the next migration cheaper than this one.

Where should a small organisation start? Verify that your CDN, VPN and cloud providers support post-quantum key agreement by default, enable it, and add post-quantum requirements to your next procurement cycle. For many small organisations, that is most of the work.

---

Glossary

---

---

References

APA 7th edition. All sources were consulted directly in preparing this article.

Academic papers and preprints

Gidney, C. (2025). How to factor 2048 bit RSA integers with less than a million noisy qubits (arXiv:2505.15917) [Preprint]. arXiv. https://arxiv.org/abs/2505.15917

Grover, L. K. (1996). A fast quantum mechanical algorithm for database search. In Proceedings of the twenty-eighth annual ACM symposium on theory of computing (STOC '96) (pp. 212–219). Association for Computing Machinery. https://doi.org/10.1145/237814.237866

Shor, P. W. (1994). Algorithms for quantum computation: Discrete logarithms and factoring. In Proceedings 35th annual symposium on foundations of computer science (pp. 124–134). IEEE. https://doi.org/10.1109/SFCS.1994.365700

Standards and official technical documentation

Kwiatkowski, K., Kampanakis, P., Westerbaan, B. E., & Stebila, D. (2026). Post-quantum hybrid ECDHE-MLKEM key agreement for TLSv1.3 (Internet-Draft draft-ietf-tls-ecdhe-mlkem-05). Internet Engineering Task Force. https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/

Moody, D., Perlner, R., Regenscheid, A., Robinson, A., & Cooper, D. (2024). Transition to post-quantum cryptography standards (NIST IR 8547 ipd) [Initial public draft]. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.IR.8547.ipd

Moody, D., Alagic, G., Bros, M., Ciadoux, P., Dang, Q., Dang, T., Kelsey, J., Lichtinger, J., Liu, Y., Miller, C., Peralta, R., Perlner, R., Robinson, A., Silberg, H., Smith-Tone, D., & Waller, N. (2026). Status report on the second round of the additional digital signature schemes for the NIST post-quantum cryptography standardization process (NIST IR 8610). National Institute of Standards and Technology. https://csrc.nist.gov/pubs/ir/8610/final

National Institute of Standards and Technology. (2024a). Module-lattice-based key-encapsulation mechanism standard (FIPS 203). U.S. Department of Commerce. https://doi.org/10.6028/NIST.FIPS.203

National Institute of Standards and Technology. (2024b). Module-lattice-based digital signature standard (FIPS 204). U.S. Department of Commerce. https://doi.org/10.6028/NIST.FIPS.204

National Institute of Standards and Technology. (2024c). Stateless hash-based digital signature standard (FIPS 205). U.S. Department of Commerce. https://doi.org/10.6028/NIST.FIPS.205

National Institute of Standards and Technology. (n.d.). Post-quantum cryptography standardization. Computer Security Resource Center. Retrieved August 4, 2026, from https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization

Government and regulatory sources

Cybersecurity and Infrastructure Security Agency. (n.d.). Product categories for technologies that use post-quantum cryptography standards. Retrieved August 4, 2026, from https://www.cisa.gov/resources-tools/resources/product-categories-technologies-use-post-quantum-cryptography-standards

European Commission. (2025, June 23). A coordinated implementation roadmap for the transition to post-quantum cryptography. Shaping Europe's Digital Future. https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography

National Cyber Security Centre. (2025, March 20). Timelines for migration to post-quantum cryptography. https://www.ncsc.gov.uk/guidance/pqc-migration-timelines

National Security Agency. (2025). Commercial National Security Algorithm Suite 2.0 algorithms FAQ. https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF

Office of Management and Budget. (2022, November 18). Migrating to post-quantum cryptography (Memorandum M-23-02). Executive Office of the President. https://www.whitehouse.gov/wp-content/uploads/2022/11/M-23-02-M-Memo-on-Migrating-to-Post-Quantum-Cryptography.pdf

The White House. (2026, June 22). Securing the nation against advanced cryptographic attacks [Executive order]. https://www.whitehouse.gov/presidential-actions/2026/06/securing-the-nation-against-advanced-cryptographic-attacks/

Industry sources and measurement data

Cloudflare. (2025, December). The 2025 Cloudflare Radar year in review. https://blog.cloudflare.com/radar-2025-year-in-review/

Cloudflare Radar. (n.d.). Post-quantum encryption. Retrieved August 4, 2026, from https://radar.cloudflare.com/post-quantum

Goldberg, S., & Voci, V. (2026, June 23). The post-quantum EO is an important milestone. Now it's time to get to work. The Cloudflare Blog. https://blog.cloudflare.com/post-quantum-eo-2026/

Let's Encrypt. (2026, June 3). A post-quantum future for Let's Encrypt. Internet Security Research Group. https://letsencrypt.org/2026/06/03/pq-certs

---