An Open-Source Scanner That Tells You Exactly How to Get Quantum-Ready

Hackers Are Already Stealing Your Data — They Just Can't Read It Yet

October 2026 was brutal. Sony Network Communications leaked 2.5 million customer records. Hackers exploited a VMmanager zero-day at FirstVDS to walk out with passwords, cloud credentials, and crypto wallet files. The University of Copenhagen exposed 525,000 people through a compromised test environment. Japan Airlines bled 92,000 customer records through Amadeus. CISA issued an emergency directive after attackers chained an Ivanti Connect Secure zero-day to exfiltrate credentials at scale.

That's one month. And every byte of that stolen data was encrypted in transit with classical TLS.

Here's the part most teams haven't internalized: attackers don't need to break your encryption today. They just need to copy the ciphertext. State-backed groups are already intercepting and stockpiling encrypted traffic to decrypt later once quantum computers can break RSA and ECC. The U.S. Department of State has confirmed that nation-state actors "sit at our boundary, collect encrypted information to decrypt later." Thales reports that harvest-now-decrypt-later is now the leading quantum-related concern, cited by 61% of organizations.

If your data has a shelf life longer than a decade — trade secrets, infrastructure credentials, health records, customer PII — the window to protect it is now, not when quantum computers arrive. Every day your traffic moves over classical-only TLS is another day of exposure to a future adversary who's already recording.

The good news: the tools to fix this exist today. The hard part is knowing where to start.

Q-Day Is a Migration Problem, Not a Research Problem

The post-quantum algorithms are standardized (FIPS 203/204/205). OpenSSL 3.5, Node 22, and .NET 10 already ship ML-KEM support. The cryptography isn't the bottleneck anymore — knowing what to change, where to change it, and in what order is.

Most teams stall out on the same questions:

• Where does TLS actually terminate — my code, a library, or the load balancer in front of it?
• If I upgrade a dependency, does that even change the negotiated crypto?
• What's the smallest, safest change I can make right now?

pqmap is an open-source CLI that answers all three. Scan your codebase, get a readiness score, and receive a concrete remediation plan — pointed at the right layer, not guesswork.

Built for the Languages and Frameworks You Actually Use

pqmap ships with a data-driven catalog covering 50+ frameworks across seven languages, and adding more is just adding TOML rows — no Rust compilation required.

Currently supported:

pqmap doesn't grep for string patterns. It resolves imports, aliases, and dependency-injection wiring (AddHttpClient<T>() in C#, axios.create({baseURL}) in JS, RestTemplate in Java) to trace each network call back to its actual TLS owner.

The Key Insight: Your Code Probably Doesn't Terminate TLS

In most production deployments, an ALB, CloudFront distribution, nginx reverse proxy, or Envoy sidecar terminates TLS before your application code ever sees the request. Upgrading your Python library to support ML-KEM does nothing if AWS ALB is the actual TLS terminator — and ALB is still classical-only.

pqmap catches this. It parses your infrastructure-as-code (Terraform, CDK, CloudFormation, Kubernetes manifests) and maps each code-level network edge to its outermost TLS terminator. When your code says one thing and your infrastructure says another, pqmap flags it as a misleading code finding — so you don't waste time fixing the wrong layer.

Architecture: Clean Enough to Contribute To

pqmap is a Rust workspace split into six focused crates. Each one has a single job and a clear boundary:

pqmap/ ├── core/ # The data model — NetworkEdge, EndpointGraph, PqAssessment ├── kb/ # Crypto-capability matrix (TOML with provenance per row) ├── analyzers/ # Language-aware scanners + infrastructure detection ├── scoring/ # Two-axis scoring engine + remediation ladder ├── probe/ # Built-in TLS handshake verification (rustls + ML-KEM) └── cli/ # The five commands you actually run 

This separation matters for contributors. Want to add Django REST Framework detection? You only touch analyzers/ and a TOML catalog file. Want to add a new infrastructure provider? Same pattern. The core data model stays stable while the detection surface grows.

The Knowledge Base Is the Moat

The most valuable part of pqmap is the crypto-capability matrix — a curated TOML dataset mapping runtimes, libraries, and infrastructure to their actual PQ support:

[[crypto]] row_id = "openssl-3.5-linux" runtime = "openssl" version_min = "3.5" pq_kem = true pq_sig = false source_url = "https://www.openssl.org/news/changes.html#OpenSSL-3.5.0" as_of = "2025-09-10" [[infra]] row_id = "aws-alb" name = "aws-alb" pq_kem = false source_url = "https://docs.aws.amazon.com/..." as_of = "2025-06-01" 

Every claim carries a source URL and date. Stale rows degrade to unknown — never a stale true. This is the kind of shared knowledge that gets better with more contributors: if you know when GCP Cloud Load Balancing adds ML-KEM support, that's a one-line PR that helps everyone.

Scan, Score, Fix — a Closed Loop

pqmap scan /path/to/repo # Build the relationship graph pqmap score --graph pqmap.json # Two-axis quantum readiness report pqmap fix --dry-run # See the remediation plan pqmap probe --graph pqmap.json # Live-verify what's actually negotiated 

Honest Scoring

pqmap scores two axes independently because post-quantum readiness isn't a single boolean:

• Confidentiality (key agreement) — protects against harvest-now-decrypt-later. ML-KEM is mature and deployable today.
• Authentication (signatures) — protects against future identity forgery. The ecosystem is early; most of the industry is honestly a C here.

If pqmap can't determine the cryptography for a connection, it grades it N (unknown) — which never inflates your score. You see exactly what's known, what's not, and what needs investigation.

Fixes Pointed at the Right Layer

Detection without actionable remediation is a report that gathers dust. pqmap generates a four-rung remediation ladder and proves which rung applies before recommending it:

The system won't recommend a dependency bump (Rung 1) when your TLS is terminated at the ALB — that change wouldn't affect the negotiated crypto. It'll tell you to fix the infrastructure (Rung 3). This is the difference between a useful tool and a checkbox exercise.

Why Open Source

Post-quantum migration is an industry-wide problem. No single vendor has visibility into every runtime, every framework, and every infrastructure provider's PQ rollout timeline. The knowledge base that powers pqmap — which runtimes support ML-KEM, which load balancers negotiate PQ groups, which versions introduced support — is inherently community-scale knowledge.

pqmap is designed so that the most impactful contributions don't require writing Rust:

• Add framework detection: edit a TOML catalog file
• Update PQ capability data: edit the knowledge base with a source URL
• Add test fixtures: drop a sample project into fixtures/

The architecture is intentionally simple and data-driven so the barrier to contribution is low. The more runtimes and infrastructure the KB covers, the more useful the tool is for everyone.

Get Started

cargo install pqmap pqmap scan . 

pqmap is:

1. A single binary
2. Runtime independent
3. Offline
4. Fast

The quantum clock is ticking, but the migration path doesn't have to be murky. Scan your project, see where you stand, and fix the thing that actually matters first.

Star the repo, file issues, contribute KB rows for your runtime or infrastructure. This is better when it's shared.