{"slug": "using-ai-to-chart-a-course-for-our-post-quantum-migration", "title": "Using AI to chart a course for our post-quantum migration", "summary": "Cloudflare is developing an internal AI-powered tool called CryptoLabe to inventory cryptographic usage across its codebase and drive its migration to post-quantum cryptography ahead of a 2029 full-readiness deadline. Cloudflare said many products already use post-quantum encryption over TLS 1.3, but post-quantum authentication deployment remains in its early days, and the company wants per-repository and per-product counts of classical versus post-quantum cryptography plus early warning on protocols lacking a PQ migration plan. CryptoLabe is tailored to Cloudflare's internal repositories, ticketing systems and documentation and is not being made available to customers.", "body_md": "# Using AI to chart a course for our post-quantum migration\n\nAs laboratories around the world race to build out a [__cryptographically relevant quantum computer__](https://blog.cloudflare.com/the-quantum-menace/), we at Cloudflare are racing towards a [__2029 target deadline for full post-quantum readiness__](https://blog.cloudflare.com/post-quantum-roadmap/). While we’ve already transitioned many of our [__products__](https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-cloudflare-products/) to post-quantum encryption, we still have work to do to support [__post-quantum authentication__](https://blog.cloudflare.com/ml-dsa-will-have-to-do/) and achieve full post-quantum readiness across our platform.\n\nWe’re taking a maximalist stance (“PQ everything!”), because as an infrastructure provider to the world, we want to give our customers the peace of mind that using Cloudflare ensures that their traffic is future-proofed against quantum adversaries.\n\nBut how does one accomplish such a massive migration at an organization of our size and scale? After all, cryptography is the base layer for almost all of the world’s digital systems, including the software services and the networking protocols that power our platform.\n\nTo drive our PQ migration, we have three key goals.\n\nFirst, we want to help our product and engineering teams understand how cryptography is being used and how they should be upgrading it. This should cover both the upgrades to post-quantum encryption and to post-quantum authentication. Many of our products have already been upgraded to [__post-quantum encryption__](https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-cloudflare-products/) over [__TLS__](https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/) 1.3, but we still want to cover the long tail of TLS connections, as well as upgrade any other uses of public-key encryption. Meanwhile, it’s still __early__[days](http://blog.cloudflare.com/pq-ca-with-mtcs/) for our deployment of post-quantum authentication.\n\nNext, we want to provide progress metrics for the migration. These might include per-repository and per-product counts of the use of classical and post-quantum cryptography.\n\nFinally, we want to surface prerequisites early. If our products or platform rely on protocols that don’t yet have a PQ migration plan (because PQ variants of the system have not yet been considered, because PQ standards do not exist or lack consensus, or because software libraries or other key ecosystem components do not yet have PQ support), then we need to know now. That way we can work with the relevant stakeholders, standards bodies and ecosystems to help drive their PQ migration plans, so that we can meet our own 2029 PQ migration timeline.\n\nThis post is the story of how we’re going about this. We explain how we turned to AI to help us solve some of our problems and how we’re developing an internal tool called **CryptoLabe** to help us. CryptoLabe is named after the mariner’s astrolabe, a navigation instrument refined by Portuguese navigators. Just as an astrolabe helped sailors determine where they were and chart a course, CryptoLabe helps us discover cryptography in our code, understand how it is used, and chart a path to post-quantum migration.\n\nCryptoLabe is highly specialized to our internal systems (our repositories, our ticketing systems, and internal documentation processes) and still evolving as we continue its development, so we aren’t making it available to customers. Nevertheless, we are sharing our learnings so that other organizations can build upon our efforts as they work through their own PQ migration journey.\n\n## The scale of the problem\n\nThe software that powers most Cloudflare products lives inside our single centralized source control management platform. This means we can find most uses of cryptography across our platform by just looking through our codebase.\n\nWhile the centralization of our codebase is a marked advantage for us, we still need to contend with three challenges that come with the scale of this problem. First, our code is spread across many repositories. Second, cryptography rarely announces itself plainly in the code. Instead, it hides in\n\n- shared libraries that a repository imports but may or may not actually call\n- upstream and protocol defaults, like a TLS 1.3 listener that is configured to negotiate a classical key exchange such as X25519 rather than post-quantum X25519MLKEM768\n- configuration files that select algorithms far away from the code that uses them, like a TLS responder whose key exchange protocols are pinned in a YAML file stored in a different repository\n- code paths that are dead, test-only, or on a path to being deprecated\n\nThird, cryptography discovery is about more than just pattern matching. Grepping for certain algorithm names (e.g. “RSA” or “X25519”) overcounts, because it finds cryptography in unused code. Grepping also undercounts, because it misses defaults and indirect uses in dependencies and configuration. Most importantly, it can't tell you how the cryptography is used. A classical [__ECDSA__](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) signature could be part of a [__JWT__](https://www.rfc-editor.org/info/rfc7519/), [__IPsec__](https://www.cloudflare.com/learning/network-layer/what-is-ipsec/#how-does-ipsec-work), [__TLS__](https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/), or [__SSH__](https://www.cloudflare.com/learning/access-management/what-is-ssh/), and each has a completely different migration path. Many uses also depend on the other side of the connection: a TLS server may support both post-quantum key exchange and classical key exchange; the one it chooses to use would depend on the client.\n\n## Turning to AI\n\nIt turns out that AI is pretty good at doing more than just grepping. A model can search a codebase, follow evidence across files, and return structured analysis. It can also enrich findings by pulling information from other sources, like our internal documentation and ticketing systems. In fact, AI can even explain how cryptography is being used and how it should be updated. We’ve been putting that idea to the test as we develop CryptoLabe.\n\nAs we said before, our first two goals are to (1) discover and understand the use of cryptography in our codebase, and also (2) to get metrics on the state of our PQ migration. Towards these goals, our current implementation of CryptoLabe performs scans in two stages, as shown in the figure below.\n\nThe first “discovery” stage starts by mapping the repository. It then searches for cryptography through source, configuration, manifests, lockfiles, scripts, tests, and documentation. Among other things, the scan looks for the use of cryptography like key agreement, signatures, asymmetric encryption, [__PKI__](https://en.wikipedia.org/wiki/Public_key_infrastructure), tokens, credentials, hardware security module integrations, and more. This discovery stage produces a set of \"raw observations.\"\n\nEach raw observation feeds a run of the second stage. This “analysis” stage first re-checks the observation against the source code. It then investigates how the cryptographic operation is used at runtime, what role the repository plays, and which internal or external parties it depends on. When necessary, it can inspect related code in other repositories to complete the analysis. Finally, it takes a pass over its own conclusions, searching for missing or conflicting evidence such as configuration overrides, test-only code, or incorrect assumptions about runtime behavior.\n\nNext, the model assigns a classification to the finding. If there is not enough evidence to assign a classification, the model assigns *More evidence needed*, *External dependency*, or *Unknown* rather than guessing.\n\nThis is the current list of classifications used by CryptoLabe, containing catch-all classifiers which will likely be refined as we proceed through our migration. (As an example, we could refine our classifiers by splitting the “encryption” classifier into [__key agreement__](https://www.rfc-editor.org/info/rfc10024/) and [__HPKE__](https://blog.cloudflare.com/hybrid-public-key-encryption/); you get the idea.)\n\n| **Classification** | **Examples** | \n| Classical encryption | This is a catch-all category that finds cases of elliptic-curve [Diffie-Hellman key exchange (ECDHE)](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman) (e.g., X25519, P-256, P-384), RSA key agreement or other uses of public-key encryption (e.g.,[__HPKE__](https://www.rfc-editor.org/info/rfc9180/) ). These are broken by a quantum computer running[Shor's algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm) , which puts them at risk of[harvest-now-decrypt-later attacks](https://blog.cloudflare.com/the-quantum-menace/) . | \n| Classical signature | This is a catch-all category that finds use of an RSA signature or elliptic-curve (ECDSA) signature in anything, for example a certificate, a TLS handshake, another protocol handshake. These signatures are broken by Shor's algorithm. | \n| Classical token | We found a lot of [RS256 or ES256 JWT tokens](https://en.wikipedia.org/wiki/JSON_Web_Token) , so we created a special classification for them. These are JWTs that use classical RSA and ECDSA signatures;[RFC 9964](https://www.rfc-editor.org/info/rfc9964) defines a post-quantum replacement using[__ML-DSA__](https://blog.cloudflare.com/ml-dsa-will-have-to-do/) . | \n| PQ-ready hybrid key exchange | Finds hybrid post-quantum key exchange in TLS 1.3, i.e. [X25519MLKEM768](https://datatracker.ietf.org/doc/rfc10024/) . This is the most prevalent use of PQ encryption in our codebase. | \n| PQ-ready | Finds other uses of post-quantum cryptography that are not [X25519MLKEM768](https://datatracker.ietf.org/doc/rfc10024/) in TLS 1.3, like[ML-DSA](https://csrc.nist.gov/pubs/fips/204/final) . | \n\nFinally, it generates a report that serves two audiences: (1) product managers who need to understand what the migration means for their product, and (2) engineers that need enough detail to execute the migration.\n\nHere’s a (cropped) view of one of our reports:\n\nWhile we’ve been iteratively reviewing findings against the source code and with relevant engineers, we do not yet have a ground-truth dataset for reproducibly comparing different versions of the prompts we’ve tried for CryptoLabe.\n\n## Built on Cloudflare’s Developer Platform\n\nWe built CryptoLabe on [__Cloudflare's Developer Platform__](https://developers.cloudflare.com/). Here’s the architecture:\n\nCryptoLabe runs across two Cloudflare [__Workers__](https://www.cloudflare.com/products/workers/). There’s a scanner Worker that runs the scans. And there’s an inventory Worker that serves the dashboard, exposes the API, and stores everything in a [__D1__](https://developers.cloudflare.com/d1/) database. The two communicate through [__Service Bindings__](https://developers.cloudflare.com/workers/runtime-apis/service-bindings/). A scan starts when someone requests it from the dashboard, and the inventory Worker passes the request to the scanner.\n\n### Orchestrating a scan\n\nWe need a way to keep a scan alive and on track from start to finish, without building our own job orchestration system. We did this with [__Agents SDK__](https://developers.cloudflare.com/agents/). Each repository gets its own persistent coordinator built on a [__Durable Object (DO)__](https://developers.cloudflare.com/durable-objects/). A bounded queue in front of the coordinators limits how many scans run at once. When a scan's turn comes, the coordinator tracks its progress and handles cancellation, retries, and recovery.\n\nThe coordinator doesn't do the analysis itself. It hands the work to [__Cloudflare Workflows__](https://developers.cloudflare.com/workflows/), so that they can persist progress and automatically retry failed steps. The coordinator moves each repository through four stages:\n\n1. discovery Workflow (the first scanning stage that produces raw observations)\n2. deep analysis Workflow (the second stage, run on each raw observation)\n3. merge Workflow (that builds a list of findings for a given repository, including combining repeated or similar finds)\n4. publish workflow (that hands results back to the inventory Worker)\n\nThe first two workflows need the model to have access to the repository's code. We want this access to be isolated, so we don’t risk damaging the codebase. That’s why CryptoLabe downloads the repository once, at an exact commit, at the start of each scan, and then stores that snapshot in [__R2__](https://developers.cloudflare.com/r2/). Each Workflow then restores the snapshot into a fresh, short-lived [__Cloudflare Sandbox__](https://developers.cloudflare.com/sandbox/), an isolated container. The model then works with the Sandbox through a small set of read-only tools on an immutable snapshot of the code, even if the codebase changes while the scan is still running.\n\n### Calling the model at scale\n\nIf we want to scan through all of our (many!) repositories, we have to worry about both cost and capacity.\n\nFor cost, the model loop sends its requests through [__AI Gateway__](https://developers.cloudflare.com/ai-gateway/) to cost-effective open-weight models hosted on [__Workers AI__](https://developers.cloudflare.com/workers-ai/). Putting the model behind AI Gateway also makes it easy to switch models as better or cheaper ones become available.  \n\nCapacity became a problem once we scanned many repositories at once. Bursts of model requests began triggering HTTP 429 (rate limit) responses from AI Gateway, and scans retrying independently only made the bursts worse. We solved this with a single, global Durable Object that paces every model request across all scans, including retries. When any scan hits a rate limit, the cooldown is shared and all scans back off together, so concurrent scans share the available capacity instead of competing for it.\n\n## Prerequisites and hard cases\n\nLet’s now get into our third goal: surfacing prerequisites and hard cases early.\n\nA lot of ink has been spilled about *ecosystem readiness* for the PQ migration, and we are now going to spill some more. As everyone knows, a PQ migration cannot happen in a vacuum. For migration to succeed, post-quantum cryptography must be supported in relevant software libraries (e.g. BoringSSL) and across parties that participate in the ecosystem (e.g. clients, browsers, origins, cloud proxies, certificate authorities, etc.). Standards are also an important indicator of ecosystem support, although a standard that is still in “draft” state does not necessarily mean deployment cannot proceed. As an example, we deployed X25519MLKEM768 in TLS 1.3 back in 2022 when it was still a “draft” at the Internet Engineering Task Force ([__IETF__](https://www.ietf.org/)) while it was only finalized as [__RFC 10024__](https://www.rfc-editor.org/info/rfc10024/) in 2026.\n\nEither way, our point is that in order to upgrade a system to PQ cryptography, we need to understand its dependencies and level of ecosystem support.\n\nThat’s why CryptoLabe uses the concept of “prerequisites” to highlight findings that cannot be immediately remediated by an individual product team working alone.\n\nA prerequisite can be something as straightforward as “we are currently blocked on migrating to post-quantum JWTs.” We say this is straightforward because there is already a standard ([__RFC 9964__](https://www.rfc-editor.org/info/rfc9964/)) for post-quantum JWTs. Nevertheless, if our software libraries don’t yet support validating post-quantum JWTs, or if we’re using a token issuer that does not yet issue post-quantum JWTs, we can’t go company-wide and ask each of our product teams to start PQ-ing their JWTs. This migration is blocked until we solve its core prerequisites. CryptoLabe lets us group together findings that (likely) have the same prerequisite, which also helps us decide how to prioritize resolving these prerequisites.\n\nFor example, the snapshot below shows the six findings from CryptoLabe that have post-quantum [__SAML__](https://www.cloudflare.com/learning/access-management/what-is-saml/) as a prerequisite. (SAML is a protocol for single sign-on ([__SSO__](https://www.cloudflare.com/learning/access-management/what-is-sso/)).)\n\nOn the other hand, there may be uses of cryptography that lack even a basic level of ecosystem support. We’ve been calling these “hard cases.” To find them, we wrote a separate prompt that ignores “vanilla” uses of cryptography (e.g. ordinary TLS between internal systems) and instead looks for custom cryptographic protocols, keys, or signatures used in size-constrained fields, cryptography built into hardware, specialized cryptographic constructions (like [__blind signatures__](https://en.wikipedia.org/wiki/Blind_signature)), protocols without a PQ standard, and dependencies on external parties that do not yet support PQ cryptography.\n\nThis prompt is shorter and simpler than those used for CryptoLabe, since its only job is to find hard cases. In our qualitative review, we found that it got better results when it ran in one fell swoop against all our repositories, while also taking in context from our internal ticketing and documentation system.\n\nHere’s an example of a “hard case” we found: a certificate carried in an HTTP header. Post-quantum certificates and signatures are larger than their classical counterparts, so if the header (or an intermediary, or the application processing the header) assumes a certificate has a certain size, changing the signature algorithm may break the system. Our next step is to determine whether this code will remain in use in the long term. If it will, we need to measure the relevant size limits and decide how to accommodate the larger certificate.\n\nAn important lesson here is that no single scan finds everything. Our repository-by-repository scans were effective at discovering common uses of cryptography. Meanwhile, this targeted scan worked better for “hard cases” because it ignored well-understood cryptography and had more context about each product and its dependencies.\n\nThe bottom line is that different approaches find different things, and every finding still needs to be checked by the engineers who understand how the system actually works.\n\n## Sharing our prompts\n\nWe’ve been messing around with the best way to write prompts for CryptoLabe for the last several months.  We don’t yet have a ground-truth dataset for comparing one prompt’s performance against another, and we are not convinced we have 100% coverage of all uses of cryptography in our codebase. Instead, we have iterated by running scans, reviewing findings with the engineers that maintain the repositories, investigating misses that came up during these reviews and revising the prompts.   Nevertheless, we decided to publish [__selected prompts__](https://github.com/cloudflare/crypto-discovery-prompts/), so other teams can learn from and adapt our approach. These prompts are starting points, not a standalone version of CryptoLabe, and the quality of their results will depend on the model, tools, context, and engineering review available.\n\n## Thinking through your own PQ migration\n\nAt Cloudflare, we’re taking a maximalist approach to our PQ migration because of our goal of acting as a provider of post-quantum cryptography for customers and the Internet at large. But most organizations [do not need](https://blog.cloudflare.com/post-quantum-eo-2026/) to start by finding every use of cryptography in every repository in every one of their products. In fact, most organizations should not be doing this, because at this time it's a waste of precious resources.\n\nBefore scanning a single repository, you can protect traffic in bulk wherever possible. If your websites run through Cloudflare, we protect your data in transit with post-quantum encryption [__already today__](https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-cloudflare-products/); check this out with our [__new PQ visibility features__](https://blog.cloudflare.com/post-quantum-visibility). Our [__SASE__](https://www.cloudflare.com/learning/access-management/what-is-sase/) platform, [__Cloudflare One__](https://blog.cloudflare.com/post-quantum-sase/), provides post-quantum encryption for private network traffic. Post-quantum encryption is provided at [__no additional cost__](https://blog.cloudflare.com/post-quantum-crypto-should-be-free/) and without requiring you to upgrade every origin server or private application on your enterprise network. This gives you a compensating control while you work through discovering and understanding the use of cryptography inside your own systems.\n\nAn exhaustive cryptographic inventory is not a prerequisite for action. Instead, organizations should first identify the systems whose compromise would matter most, discover their use of cryptography, and then PQ that cryptography in priority order. Here is one way to begin:\n\n1. **Choose a repository for one important system.** Start with something that handles sensitive or long-lived data, authenticates users or software, or is exposed to the public Internet.\n2. **Run cryptography discovery against that repository.** We hope our description of CryptoLabe will be helpful to this effort!\n3. **Validate the results.** Ask the team who owns the system to validate the results of cryptography discovery and confirm that the cryptography finding is needed long term and needs to be upgraded to PQ. It’s important to remember that it might*not* need to be immediately upgraded to PQ if there is another compensating control in place.\n4. **Prioritize action.** Figure out what upgrades you can make now and what upgrades are blocked. Record shared prerequisites that need help from a library, vendor, standards group, or another part of your organization. Prioritize your findings and make a plan for addressing the highest-impact systems and prerequisites first.\n\nThat gives you the beginning of a PQ transition plan, without requiring a complete map of every cryptographic operation in your organization. CryptoLabe is still ever-evolving, but its scans and results have been illuminating to us as we plan our migration. We hope these shared learnings will be useful as you continue to work through your own PQ migration.\n\n*Acknowledgements: Many people across Cloudflare provided feedback on and contributed to CryptoLabe, including Davide Marquês, Peter Wu, Phil Schmieder, JP Aumasson, Andrew Galloni, Christopher Patton, Luke Valenta, Mari Galicer, Vânia Gonçalves, and the [__Client__](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/download/), [__Tunnel__](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/) and [__Gateway__](https://www.cloudflare.com/zero-trust/products/gateway/) teams who reviewed reports produced by the tool.*", "url": "https://wpnews.pro/news/using-ai-to-chart-a-course-for-our-post-quantum-migration", "canonical_source": "https://blog.cloudflare.com/ai-driven-cryptography-discovery/", "published_at": "2026-09-29 13:00:00+00:00", "updated_at": "2026-09-29 13:17:30.939884+00:00", "lang": "en", "topics": ["ai-tools", "ai-infrastructure", "artificial-intelligence"], "entities": ["Cloudflare", "CryptoLabe", "TLS 1.3"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/using-ai-to-chart-a-course-for-our-post-quantum-migration", "markdown": "https://wpnews.pro/news/using-ai-to-chart-a-course-for-our-post-quantum-migration.md", "text": "https://wpnews.pro/news/using-ai-to-chart-a-course-for-our-post-quantum-migration.txt", "jsonld": "https://wpnews.pro/news/using-ai-to-chart-a-course-for-our-post-quantum-migration.jsonld"}}