Post-Quantum Cryptography Migration: How can PQCensus inventory cryptographic primitives?

A powerful quantum computer can break or reduce the security of modern-day cryptography, and this is described as a well known fact that puts enterprise IT infrastructure at risk [13]. The best known mitigation to this threat is migrating enterprise IT to a Post Quantum Cryptography state [13]. This migration is difficult because enterprise IT usually consists of several large applications with complex interdependencies [13]. Because of that difficulty, migration will require technical expertise together with new tools that can automate the process and reduce errors [13]. These four facts, taken in sequence, describe the exact gap an inventory tool is meant to fill: a real threat, a known but hard remedy, a structural reason the remedy is hard, and a call for tooling to make it tractable.

This is the practical reason an inventory tool is needed before any code is changed: nobody can migrate what they cannot find, and manual auditing of large, interdependent applications does not scale. Two tools have been proposed in the literature to meet this need directly: an Inventory Generator that produces a crypto inventory for an input application, and a TCS Quantum Risk Analyzer Engine that assesses an input application against quantum threats [13]. These are presented as a pair: first find the cryptography, then assess its risk [13]. The division of labour matters for a builder, because it separates two distinct engineering problems, discovery and risk scoring, that might otherwise be conflated into a single opaque tool.

A separate but related concern is that enterprise wide-area networks depend on quantum-vulnerable public-key cryptography to authenticate peers and establish keys for IPsec, TLS, and software-defined WAN services [11]. This shows the inventory problem is not confined to application source code: it also spans network-level protocol configuration, which a source-code scanner such as PQCensus does not directly examine. A complete enterprise migration programme therefore needs at least two kinds of inventory work running in parallel, one at the application source level and one at the network and protocol level, and no single claim in this note describes a tool that unifies both.

Against this backdrop, PQCensus positions itself narrowly and explicitly as a source-code-level answer to four engineering questions: where cryptography is used, what purpose each use serves, which uses are relevant to post-quantum migration, and what can be migrated next without inventing a target when evidence is ambiguous [1]. This scoping matters for a builder: PQCensus is not a network auditor, a risk-scoring engine across an entire enterprise, or a certifier; it is a static-analysis inventory step that other tools or manual review would need to build on. Reading PQCensus's four questions next to the enterprise-level framing above shows that PQCensus answers only the first half of the larger migration problem described by the enterprise tooling literature, the "find it" half, not the "assess enterprise-wide risk" or "fix the network layer" halves.

PQCensus is a local static-analysis tool [1]. It requires no API key, no hosted service, no cloud upload, and no LLM [1]. This is a design choice with direct operational consequences: a team can run it inside a closed network or an air-gapped build pipeline without sending source code anywhere, and without depending on an external model provider's availability or cost. For organizations with strict data-residency or confidentiality requirements around their own source code, this local-only design removes a whole category of approval and vendor-risk questions that a cloud-hosted or LLM-backed scanner would raise.

The tool also draws a hard boundary around what a normal scan does. Normal repository scanning does not intentionally import target packages, install target dependencies, run setup.py, package lifecycle hooks, Makefiles, shell scripts, tests, binaries, containers, or arbitrary builds, and it does not follow symlinks outside the requested scan root [1]. This means a scan is a read-only, source-level pass: it will not execute code, will not pull in third-party dependencies to inspect them dynamically, and will not wander outside the directory a user points it at. This is an important safety property for anyone running the tool against untrusted or third-party code, since it removes the risk that scanning itself triggers arbitrary code execution.

PQCensus is also explicit about what it will not claim. It does not claim NIST certification, and it will not label a repository "quantum safe" purely because a scan came back clean [1]. This is a meaningful limitation to communicate to any stakeholder who might otherwise read "zero findings" as "safe." A clean scan under this design can mean either that no relevant cryptography exists in the scanned source, or that the analyzer's coverage did not reach the relevant code, and the tool itself does not distinguish these two cases as a certification would.

Taken together, these three design facts, no cloud dependency, no code execution during scanning, and no certification claim, describe a tool meant to be a conservative, inspectable first step, not a final verdict on an application's post-quantum posture [1]. A builder adopting PQCensus should treat its output as a starting inventory to be reviewed and extended, not as a compliance artifact that closes out a migration audit on its own.

The stable source-language analyzer in PQCensus is Python AST-based [1]. This means the tool parses Python source into its abstract syntax tree and inspects that structure, rather than doing plain text or regular-expression matching, for the language it treats as production-ready. Working from the AST rather than raw text lets the analyzer reason about symbols, calls, and structure rather than surface string patterns, which is presumably why this is the only analyzer described as stable.

Coverage for other languages, JavaScript/TypeScript, Go, Java, Rust, and C/C++, is described as text coverage, and it is explicitly experimental and deliberately lower-confidence [1]. The tool's own documentation states this is not presented as equivalent to the Python analyzer [1]. A builder should read this as: treat non-Python findings as a starting hint to investigate manually, not as a finding with the same evidential weight as a Python AST-based one. The distinction between structural (AST) analysis and text coverage is stated directly in the source material, and it is the clearest signal available about where the tool's confidence genuinely lies today.

Every finding PQCensus produces preserves a specific set of reviewable evidence fields: stable finding and rule identifiers, source path and span, symbol/call information, algorithm and purpose, analyzer and confidence, rule/authority references, contextual risk and HNDL (harvest-now-decrypt-later) inputs, suppression state, and migration targets, with the migration target only included when purpose evidence supports the mapping [1]. This field list is the core mechanism by which the tool supports migration planning: each finding is not just a flag, it is a self-contained, auditable record that a reviewer or downstream tool can trace back to an exact file, line span, and algorithm/purpose classification. Because the identifiers are described as stable, a team can diff findings across successive scans of the same repository and track whether a given finding persists, disappears, or is suppressed, without losing the thread between scans.

The purpose classification step is the hinge on which migration guidance turns. When the analyzer cannot establish purpose with confidence, it labels the finding UNKNOWN, and UNKNOWN purpose does not receive an automatic PQC migration target [1]. This is the concrete mechanism behind the fourth engineering question the tool sets out to answer, what can be migrated next, without inventing a target when the evidence is ambiguous [1]. This UNKNOWN state is not a failure of the scan; it is a deliberate refusal to guess, which is consistent with the tool's overall stance of preferring an honest gap over a fabricated answer.

When PQCensus does propose a candidate migration target, it is careful about the status of that suggestion. Candidate migration targets are described as engineering guidance, not drop-in compatibility promises [1]. The tool's own documentation lists what still needs validation before any such target can be adopted: protocol, PKI, HSM/KMS, peer support, message size, lifecycle, rollback, and operational constraints [1]. This is a long and specific checklist, and it signals that a migration target field is the start of an engineering investigation, not the end of one.

This qualifier is important for anyone building a migration plan on top of PQCensus output. A migration target field populated in a finding record tells a reviewer which post-quantum primitive might replace the classical one being used, given the purpose evidence available, but it does not verify that the surrounding system, a TLS stack, a PKI hierarchy, a hardware security module, or a peer that must also support the new algorithm, can actually accept that swap. Each of the eight validation items listed above corresponds to a real deployment dependency that a purely source-level scanner cannot observe from the code alone.

This restraint is consistent with the tool's stated core design in the first section: not inventing a target when evidence is ambiguous [1]. It also connects directly to the UNKNOWN-purpose rule: if the purpose of a cryptographic call cannot be established, no target is proposed at all, rather than a guessed one [1]. The two rules together describe a single underlying policy: only report a migration target when the evidence chain, from call site to purpose to plausible replacement, is intact end to end.

For a builder, the practical takeaway is that PQCensus findings should be read in two tiers: findings with a populated migration target are candidates for a migration backlog item, still requiring the listed validation work, and findings without a target (UNKNOWN purpose) are candidates for manual investigation before any migration decision can even be framed [1]. Treating these two tiers with different workflows, rather than merging them into one backlog, keeps the tool's own evidentiary caution intact as the output moves into a team's planning process.

PQCensus reports effectiveness across three distinct, increasingly realistic benchmark layers, and each layer has its own sample size and its own conditions; they should not be pooled into a single headline number. On the synthetic semantic benchmark layer, consisting of 26 cases and 26 labeled findings, PQCensus achieved 26 true positives, 0 false positives, and 0 false negatives [1]. This is a fully controlled, synthetic test: every case has a known label, and the tool matched every one of them exactly. A perfect score on a synthetic layer built specifically to exercise known semantic patterns is expected behaviour for a well-tuned analyzer, and it should be read as a check that the rule engine works as designed, rather than as evidence about arbitrary real-world code.

On the curated upstream excerpts benchmark layer, consisting of 5 excerpts and 6 labeled call sites, PQCensus achieved 6 true positives, 0 false positives, and 0 false negatives [1]. This layer moves from synthetic constructions to short excerpts drawn from real upstream code, still a small and curated sample, but closer to real-world code shape than the synthetic layer. The sample size here, five excerpts and six call sites, is small enough that a single missed or misclassified call site would have produced a visibly worse score, so the perfect result should be read in light of that small denominator.

On the pinned end-to-end repositories benchmark layer, using python-jose 3.3.0 plus PyJWT 2.10.1 across 96 files, PQCensus produced 193 findings and matched 12 of 12 required observations [1]. This is the most realistic of the three layers: two real, version-pinned packages scanned in full, rather than isolated excerpts. The 193 findings figure is a raw count of what the scanner surfaced, and the 12-of-12 figure is the subset of those findings that the benchmark had pre-defined as required, both matched. It is worth noting explicitly that 193 total findings against 12 required observations means the majority of findings in this real-world layer are not directly scored against a labeled ground truth in the reported number; the 12-of-12 figure establishes that the required, labeled subset was fully recovered, but it does not by itself establish a precision figure over all 193 findings.

No claim states these numbers against any external baseline tool, so no comparative accuracy figure (for example, against dotnet-cbom or another scanner) can be reported here; each number stands only against its own labeled ground truth within its own layer [1]. A builder who wants to know how PQCensus would perform on their own, uncurated codebase should treat all three numbers as upper bounds obtained under favourable, curated, or pinned conditions, not as guarantees that transfer automatically to an arbitrary repository.

dotnet-cbom is a separate, related tool for a different ecosystem: it uses Roslyn static analysis to inventory cryptographic usage, classify quantum risk, and demonstrate post-quantum migration progress, targeting .NET code [7]. It discovers crypto across System.Security.Cryptography, JWT validation, TLS/cert handling, and post-quantum APIs (ML-KEM/ML-DSA/SLH-DSA), attaching a detection confidence to every finding [7]. It classifies each finding on two independent axes, classical weakness and quantum vulnerability, rather than a single risk label [7]. This two-axis design is a more elaborate classification scheme than anything described for PQCensus, which reports algorithm, purpose, and a migration target where warranted, but does not report a two-axis risk score in the claims available here.

dotnet-cbom also produces machine-readable and human-readable outputs: CycloneDX 1.6, SARIF 2.1.0, Markdown, HTML, and an executive summary [7]. It tracks change over time with a diff/--baseline mechanism that stamps each finding as New, Unchanged, Regressed, or Waived [7], and it validates its own generated CBOMs against the official CycloneDX 1.6 JSON Schema and the dotnet-cbom profile [7]. It sees third-party crypto through Bouncy Castle detection and a package-manifest inventory drawn from project.assets.json / PackageReference [7], and as of its readme it has 17 rules [7]. Its risk formula for a single finding is 0.45 times Q plus 0.35 times C plus 0.20 times X, combining quantum, classical-weakness, and usage-exposure factors, with fail-closed floors [7], and its PQC Readiness score is defined as 100 times safe-weight divided by total-weight, computed over quantum-relevant algorithms only [7]. It measures its own accuracy with a labeled-corpus accuracy benchmark that runs real detectors against independently authored ground truth and fails CI on any regression [7]. This last property, a CI-integrated regression gate on accuracy, is a form of continuous validation that is not described for PQCensus in the claims available here; PQCensus's benchmark numbers are reported as point-in-time results across the three layers described above.

Two clarifications matter here. First, the passages describing dotnet-cbom do not describe PQCensus at all; they describe a contract-based migration task for coding agents and the separate dotnet-cbom generator [5]. Second, the TCS Inventory Generator and Quantum Risk Analyzer Engine are proposed as a pair of tools for enterprise applications generally, not as a static-analysis method with reported precision/recall numbers in the material available [13]. None of these sources report a shared benchmark, a shared codebase, or a head-to-head run against PQCensus, so this section is a side-by-side description of separately reported systems, not a comparison of measured accuracy.

Beyond source-level inventory tools, the broader migration challenge also touches on other dimensions these tools do not cover. Coding-agent based migration, tested via a contract-based task moving a Go file signer from RSA to ML-DSA-44 across 160 attempts in four local-agent configurations, produced twelve final patches that pass local verification but fail external requirements [5]. Checker access did not increase the observed completion rate in any comparison in that study [5], reducing one model's context window from 128K to 32K lowered full passes from 36/40 to 4/40 [5], and four exploratory trials using two other model/tool combinations passed all 40 checks, including both baselines [5]. This is a distinct problem, automated code transformation, not inventory, and it is reported on a different benchmark (a single Go signer migration task) than any PQCensus number. It is a useful contrast for a builder nonetheless: it shows that even where an inventory correctly identifies a cryptographic call site and a plausible migration target, the downstream act of actually rewriting the code to use that target is a separate and, according to this study, still error-prone task, with twelve of 160 attempts passing local checks but failing external requirements [5].

An inventory tool's value depends partly on what happens after a migration target is identified, and the literature flags that the algorithms themselves are not interchangeable in cost. The energy, bandwidth, and latency needs of PQC algorithms span several orders of magnitude, and this is substantial enough to impact battery life, user experience, and application protocol design [6]. This is a direct consequence for any migration plan built from a PQCensus finding: a proposed migration target is a candidate algorithm, but its resource profile still needs separate evaluation before it is adopted at scale.

For mobile and cloud-connected contexts specifically, fast structured-lattice PQC schemes are reported as the preferred choice for cloud-connected mobile devices in most use cases, even when the per-bit data transmission energy cost of such schemes is relatively high [6]. This finding illustrates why PQCensus's own caution, that a migration target is engineering guidance and not a drop-in compatibility promise [1], is well founded: even a technically correct candidate algorithm can carry very different operational costs depending on the deployment context, and a scheme that is fast on-device can still be expensive to transmit, which matters differently for a battery-powered mobile client than for a server.

This also reinforces why PQCensus preserves contextual risk and HNDL inputs as evidence fields on each finding [1], since harvest-now-decrypt-later exposure and deployment context, mobile versus server, for example, both affect how urgently and how a given finding should be migrated, even before energy and bandwidth tradeoffs are weighed [6]. A finding flagged with high HNDL exposure but destined for a resource-constrained mobile deployment sits at the intersection of two separate concerns, urgency of migration and cost of the replacement algorithm, that a builder must weigh together rather than in isolation.

No claim ties a specific PQCensus finding to a specific energy or bandwidth measurement, so this connection is presented here as two separately reported facts that a builder must combine manually: PQCensus tells you where a classical primitive is used and what might replace it [1]; the mobile energy literature tells you that the replacement's resource cost still needs separate evaluation before deployment [6]. Combining the two requires a manual step that neither source performs on its own, and a builder should budget explicit engineering time for it rather than assume the inventory tool's migration target already accounts for deployment cost.

The most immediate limitation is release status: no canonical release evidence is currently established for PQCensus, and no GitHub Release or PyPI release is authorized as of the source material [1]. A builder evaluating this tool today is looking at a project without a stable, citable release artifact, which affects how much long-term reliance a team should place on any particular version's behaviour without pinning to a specific commit or build.

The second limitation is language coverage. Only the Python analyzer is described as stable and AST-based [1]; JavaScript/TypeScript, Go, Java, Rust, and C/C++ support is experimental, text-based, and deliberately lower-confidence, explicitly not equivalent to the Python analyzer [1]. Any organization with a mixed-language codebase should expect materially weaker guarantees outside Python, and should not assume the same false-positive and false-negative rates reported on the Python-oriented benchmarks would hold for a Go or Java repository.

The third limitation is scope. The tool does not execute installed dependencies, build steps, tests, or containers during a normal scan [1], so any cryptography whose use only appears at runtime, inside a dependency's compiled behavior, or via configuration not visible in static source, is out of reach of this method by design. It also makes no claim about certification or an overall "quantum safe" status [1], and no claim in the available material states an accuracy figure for real-world, uncurated repositories beyond the one pinned two-package benchmark reported [1]. This means the tool's demonstrated accuracy rests on a synthetic layer, a small curated-excerpt layer, and a single pinned two-package end-to-end layer; none of these establish a general accuracy figure across arbitrary, unseen, uncurated repositories.

Finally, this note cannot report a head-to-head measured comparison between PQCensus and any other tool, dotnet-cbom, the TCS Inventory Generator, or coding-agent-based migration methods, because no claim provides one. Each tool's numbers stand only against its own reported benchmark and conditions: PQCensus's three layers [1], dotnet-cbom's labeled-corpus accuracy benchmark [7], and the coding-agent study's 160-attempt, four-configuration task [5]. A builder who needs a comparative decision between these approaches would need to run such a comparison directly, on the same codebase, since none currently exists in the cited evidence.

1. Confirm the target codebase's primary language before starting. If it is Python, plan to rely on PQCensus's stable AST-based analyzer [1]; if it includes JavaScript/TypeScript, Go, Java, Rust, or C/C++, plan for those results to be experimental, lower-confidence, text-based findings that need manual follow-up rather than automatic trust [1].
2. Set up the scan to run locally, with no API key, hosted service, cloud upload, or LLM dependency, so the codebase never leaves your environment [1]. This also means you can run it inside a closed CI pipeline without external network calls, which is useful for codebases under strict confidentiality requirements.
3. Before running, verify the scan will not execute anything: it should not import or install target packages, run setup.py, package lifecycle hooks, Makefiles, shell scripts, tests, binaries, containers, or arbitrary builds, and it should not follow symlinks outside the scan root [1]. If your build wrapper does any of these things automatically, disable that behavior for the scan pass, so the scan stays a pure read-only, source-level operation.
4. Run the scan against the repository root and collect the finding set. Each finding should carry: a stable finding and rule identifier, source path and span, symbol/call information, algorithm and purpose, analyzer and confidence, rule/authority references, contextual risk and HNDL inputs, suppression state, and, only where purpose evidence supports it, a migration target [1]. Store these as your evidence baseline, keyed by the stable identifiers so later scans can be diffed against it.
5. Separate findings into two buckets immediately: those with a populated migration target, and those labeled UNKNOWN purpose with no target [1]. Route the UNKNOWN bucket to manual code review; do not attempt to auto-migrate it, since the tool itself declined to propose a target precisely because the evidence did not support one.
6. For every finding with a migration target, treat it strictly as engineering guidance, not a drop-in replacement [1]. Open a validation checklist per finding covering protocol, PKI, HSM/KMS, peer support, message size, lifecycle, rollback, and operational constraints [1], and do not close the migration item until each is checked.
7. Cross-reference the deployment context of each validated finding against known resource costs: if the target environment is mobile or cloud-connected, note that PQC schemes vary in energy, bandwidth, and latency by orders of magnitude [6], and that fast structured-lattice schemes are generally preferred for cloud-connected mobile devices even at relatively high per-bit transmission energy cost [6]. Record this as a separate line item, since PQCensus itself does not measure resource cost.
8. Validate tool output against the reported benchmark layers before trusting it on your own codebase: check whether your test cases resemble the synthetic semantic layer (26 cases/26 labeled findings, TP 26 FP 0 FN 0) [1], the curated upstream excerpts layer (5 excerpts/6 call sites, TP 6 FP 0 FN 0) [1], or the pinned end-to-end layer (python-jose 3.3.0 plus PyJWT 2.10.1, 96 files, 193 findings, 12/12 required observations matched) [1]. Do not assume these figures transfer to an unrelated, uncurated codebase, since each was obtained under its own controlled or curated conditions.
9. Do not report a clean scan (zero findings) as a certification or a blanket safety claim. PQCensus itself does not claim NIST certification or label a repository quantum safe from a clean static scan [1], and any downstream report your team produces should carry the same caveat rather than silently upgrading a clean scan into a safety guarantee.
10. If the codebase also depends on enterprise network infrastructure, such as IPsec, TLS, or software-defined WAN services that authenticate peers with quantum-vulnerable public-key cryptography, treat that as a separate inventory task outside PQCensus's scope [11], since the source-level scan does not examine network or protocol configuration directly.
11. Where a migration target has been validated and the codebase is Python, consider whether an automated code-transformation step (a coding agent, for example) will be used to apply the change; if so, budget for verification failures even after local checks pass, since a study of an analogous RSA to ML-DSA-44 migration task found twelve of 160 attempts across four agent configurations passed local verification but failed external requirements [5].
12. Keep the full evidence record, not just a pass/fail summary, for every finding that goes into a migration backlog. Because PQCensus preserves stable finding and rule identifiers, source path and span, and suppression state as part of its evidence fields [1], a reviewer months later can re-open the exact reasoning behind a decision to migrate, suppress, or leave a finding as UNKNOWN, which is the point of preserving reviewable evidence in the first place.

for file in repository (Python, AST-parsed):
    for call_site in file:
        classify(algorithm, purpose)
        if purpose == UNKNOWN:
            record finding (no migration target)
        else:
            record finding (migration target = candidate PQC primitive)
    attach: id, rule id, path, span, symbol/call info,
            analyzer, confidence, rule/authority refs,
            contextual risk, HNDL inputs, suppression state
review UNKNOWN bucket manually
for each finding with a target:
    validate protocol, PKI, HSM/KMS, peer support,
             message size, lifecycle, rollback, ops constraints
    check resource cost for deployment context (mobile/server)