Cloudflare is working toward full post-quantum readiness by 2029. Encryption over TLS 1.3 is already post-quantum for many products, but the long tail of TLS connections, other public-key encryption uses, and post-quantum authentication remain open work. The company's stance is maximalist — PQ everything — on the grounds that, as an infrastructure provider, it wants customers to know their traffic is future-proofed against quantum adversaries.

Migration at that scale requires visibility into where cryptography lives. Cloudflare's three goals are to help product and engineering teams understand how cryptography is used and how to upgrade it, to produce progress metrics such as per-repository and per-product counts of classical versus post-quantum cryptography, and to surface prerequisites early — protocols whose PQ variants have not been considered, standards that lack consensus, or libraries without PQ support. The third goal exists so the company can work with stakeholders, standards bodies, and ecosystems to drive their migration plans and hit 2029.

To that end, Cloudflare built an internal tool called CryptoLabe, named after the mariner's astrolabe. It is specialized to Cloudflare's repositories, ticketing systems, and documentation, still evolving, and not offered to customers; the company is sharing what it learned.

Where cryptography hides

Most Cloudflare product code lives in a single centralized source control platform, which makes a codebase search the primary discovery method. Three problems remain.

Code is spread across many repositories. Cryptography rarely announces itself and instead hides in:

  • shared libraries that a repository imports but may or may not call
  • upstream and protocol defaults, such as a TLS 1.3 listener configured to negotiate X25519 rather than X25519MLKEM768
  • configuration files that select algorithms far from the code using them, such as a TLS responder whose key exchange protocols are pinned in a YAML file in another repository
  • code paths that are dead, test-only, or on a path to deprecation

Pattern matching also fails on its own terms. Grepping for names like "RSA" or "X25519" overcounts, because it hits unused code. It undercounts, because it misses defaults and indirect uses in dependencies and configuration. And it cannot say how the cryptography is used: a classical ECDSA signature could belong to a JWT, IPsec, TLS, or SSH, each with a different migration path. Many uses also depend on the other side of the connection — a TLS server may support both post-quantum and classical key exchange, and the one it picks depends on the client.

A two-stage scanner

A model can search a codebase, follow evidence across files, and return structured analysis, and it can enrich findings from internal documentation and ticketing systems. CryptoLabe's current implementation runs scans in two stages.

The first, discovery, maps the repository, then searches source, configuration, manifests, lockfiles, scripts, tests, and documentation for uses of key agreement, signatures, asymmetric encryption, PKI, tokens, credentials, hardware security module integrations, and more. It produces a set of "raw observations."

Each observation feeds a run of the second, analysis stage. That stage re-checks the observation against the source code, investigates how the operation is used at runtime, what role the repository plays, and which internal or external parties it depends on, inspecting related code in other repositories when needed. It then reviews its own conclusions for missing or conflicting evidence: configuration overrides, test-only code, wrong assumptions about runtime behavior.

Next the model assigns a classification. When evidence is insufficient it assigns More evidence needed, External dependency, or Unknown rather than guessing. The current classifier list contains catch-alls that will likely be refined — one candidate refinement is splitting "encryption" into key agreement and HPKE.

The output is a report written for two audiences: product managers who need to know what the migration means for their product, and engineers who need enough detail to execute it.

Findings are reviewed iteratively against the source code and with relevant engineers. A ground-truth dataset for reproducibly comparing prompt versions does not exist yet.

Architecture and orchestration

CryptoLabe is built on Cloudflare's Developer Platform and runs across two Workers. A scanner Worker runs scans; an inventory Worker serves the dashboard, exposes the API, and stores everything in a D1 database. The two communicate over Service Bindings. Scans start on request from the dashboard, and the inventory Worker passes the request to the scanner.

Rather than build job orchestration, Cloudflare used the Agents SDK to keep scans alive and on track. Each repository gets a persistent coordinator built on a Durable Object, with a bounded queue in front of the coordinators limiting concurrent scans. A coordinator tracks progress and handles cancellation, retries, and recovery, but delegates the analysis to Cloudflare Workflows so progress persists and failed steps retry automatically. Each repository moves through four stages:

  1. discovery Workflow — the first scanning stage, producing raw observations
  2. deep analysis Workflow — the second stage, run per raw observation
  3. merge Workflow — builds a repository's findings list, combining repeated or similar finds
  4. publish Workflow — hands results back to the inventory Worker

The first two workflows need model access to repository code, which is isolated so the codebase cannot be damaged. At the start of each scan the repository is downloaded once at an exact commit and stored in R2. Each workflow restores that snapshot into a fresh, short-lived Cloudflare Sandbox, an isolated container, and the model works through a small set of read-only tools against the immutable snapshot even if the codebase changes mid-scan.

Cost and capacity

Scanning many repositories raises both cost and capacity concerns. The model loop sends requests through AI Gateway to cost-effective open-weight models hosted on Workers AI, which also makes switching models easy as better or cheaper ones appear.

Capacity broke down once many repositories were scanned at once: bursts of model requests triggered HTTP 429 rate-limit responses from AI Gateway, and independently retrying scans made the bursts worse. The fix was a single global Durable Object that paces every model request across all scans, retries included. A rate limit hit by any scan triggers a shared cooldown, so all scans back off together and concurrent scans share the available capacity instead of competing for it.

Prerequisites versus hard cases

A PQ migration is not something a single product team can complete in isolation. Post-quantum cryptography has to be supported in the relevant software libraries (BoringSSL, for instance) and across every party in the ecosystem: clients, browsers, origins, cloud proxies, certificate authorities and others. Standards are a useful signal of that support, but a draft is not automatically a blocker. Cloudflare deployed X25519MLKEM768 in TLS 1.3 in 2022, while it was still an IETF draft; it was only finalized as RFC 10024 in 2026.

To capture dependencies of this kind, CryptoLabe uses the notion of a prerequisite: a finding that no individual product team can remediate on its own. Post-quantum JWTs are a clean example — RFC 9964 already exists — but if the relevant software libraries cannot yet validate them, or the token issuer does not yet issue them, then asking every product team to PQ their JWTs is pointless. The work is blocked until the core prerequisite is resolved. CryptoLabe groups findings that likely share a prerequisite, which in turn indicates what to tackle first. A sample snapshot shows the six CryptoLabe findings whose prerequisite is post-quantum SAML, the single sign-on (SSO) protocol.

Some cryptographic uses lack even a basic level of ecosystem support. These are the “hard cases,” and a separate prompt exists to find them. It skips “vanilla” cryptography such as ordinary TLS between internal systems and looks instead for custom protocols, keys or signatures in size-constrained fields, cryptography in hardware, specialized constructions such as blind signatures, protocols with no PQ standard, and dependencies on external parties without PQ support.

That prompt is shorter and simpler than the CryptoLabe prompts because its only job is to surface hard cases. In qualitative review it performed better when run in one sweep across all repositories, with context from the internal ticketing and documentation system included.

One example: a certificate carried in an HTTP header. Because post-quantum certificates and signatures are larger than classical ones, any header — or intermediary, or application handling the header — that assumes a given certificate size may break when the signature algorithm changes. The follow-up is to establish whether the code has a long-term future; if it does, the size limits need to be measured and a plan made to accommodate the larger certificate.

The broader lesson is that no single scan finds everything. Repository-by-repository scans were effective at finding common cryptographic usage, while the targeted scan suited hard cases precisely because it ignored well-understood cryptography and had more context about each product and its dependencies. Different approaches surface different findings, and engineers who understand how a system actually works still have to check each one.

Prompt iteration and the published set

Prompt design evolved over several months. There is no ground-truth dataset for comparing prompt performance, and no confidence that coverage of all cryptographic usage in the codebase is complete. The loop instead was: run scans, review findings with repository maintainers, investigate missed uses raised during those reviews, then revise. Selected prompts were published so other teams can adapt them, with the caveat that they are starting points rather than a standalone version of CryptoLabe — their results depend on the model, the tooling, the context and the engineering review behind them.

A staged path for other organizations

Cloudflare’s maximalist approach follows from its goal of providing post-quantum cryptography to customers and to the Internet at large, but most organizations do not need to begin by cataloguing every cryptographic use in every repository across every product. At this stage, attempting that is a misallocation of resources.

Bulk protection comes before scanning. Traffic for sites running through Cloudflare is already protected in transit with post-quantum encryption, as the PQ visibility features show. Cloudflare One, the SASE platform, provides post-quantum encryption for private network traffic at no additional cost, without requiring upgrades to every origin server or enterprise application. That serves as a compensating control while discovery inside a given environment proceeds.

An exhaustive inventory is therefore not a prerequisite for action. The recommended sequence is to identify the systems where compromise would matter most, discover their cryptography, and PQ it in priority order:

  1. Pick one repository for an important system. Prefer systems that hold sensitive or long-lived data, authenticate users or software, or are Internet-facing.
  2. Run cryptography discovery on it.
  3. Have the owning team validate the results and confirm the finding is needed long term and requires a PQ upgrade. A compensating control may mean an upgrade is not immediately necessary.
  4. Prioritize. Separate what can be upgraded now from what is blocked, record shared prerequisites that need a library, vendor, standards group or another internal team, and plan around the highest-impact systems and prerequisites first.

This yields the start of a transition plan without a complete map of every cryptographic operation. CryptoLabe continues to evolve, and its scans and results have informed Cloudflare’s own migration planning.

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, Tunnel and Gateway teams who reviewed reports produced by the tool.