qScan: cryptographic discovery and readiness scoring
What Quantakrypto's own scanner does: finds where cryptography lives across your code and infrastructure, classifies what is quantum-vulnerable, and rolls it up into a readiness score you can track over time.
Discovery you can act on
qScan is Quantakrypto's cryptographic discovery scanner. It inspects source, dependencies, certificates, and configuration to find where cryptographic algorithms are used, flags the quantum-vulnerable ones (RSA, ECDH, ECDSA), and produces a readiness score weighted by exposure. The output is a cryptographic inventory you can prioritize and re-run to track progress. The scan is what turns a guess into a work list.
Every migration program starts with the same question: where is our cryptography? Answering it by hand across a large estate is impractical. qScan is the platform's scanner for automating that discovery and turning it into a living inventory rather than a one-time spreadsheet.
What it discovers
- Algorithms in code: direct calls into crypto libraries and the primitives they select (key exchange, signatures, hashing, symmetric ciphers).
- Dependencies: cryptographic libraries pulled in transitively, where the real algorithm choices often hide.
- Certificates and keys: key types and sizes in certificates and keystores (for example RSA-2048 or an EC P-256 key).
- Protocol and TLS configuration: negotiated key-exchange and signature algorithms on services you point it at.
- Configuration and secrets handling: where algorithm choices are pinned in config rather than made agile.
The output is a cryptographic inventory (CBOM)
qScan's findings form a cryptographic bill of materials: for each asset, which algorithm, where it is used, and whether it is quantum-vulnerable. That inventory is the artifact every later phase depends on: prioritization, migration sequencing, and readiness reporting all read from it.
How the readiness score works
A raw count of vulnerable algorithms is not decision-useful. A hard-coded RSA key exchange matters more than the hundredth repeat of a pattern you already know about, and a finding in a test fixture matters less than one in production code. qScan weights findings by severity, with diminishing returns for repeated instances of the same pattern and a down-weight for test paths, to produce a readiness score. The harvest-now-decrypt-later layer (how long each finding's data must stay secret) is opt-in and purely additive: it flags urgency on top of the score, never inside it. Treat the score as a headline that always drills down into the underlying findings; it is a communication device, not a substitute for the inventory beneath it.
Where it fits in the program
- Phase 1 (Discover): run qScan across repos and services to build the initial inventory.
- Phase 2 (Prioritize): use the severity-weighted findings, plus the HNDL flags if enabled, to sequence the backlog.
- Ongoing: re-run continuously (see the GitHub / CI article) so new vulnerable crypto is caught as it lands, and the readiness trend stays honest.
A scanner finds; it does not fix
Automated discovery is necessary but not sufficient. qScan tells you where the vulnerable cryptography is and how exposed it is. A human still has to decide the migration approach for each domain (hybrid TLS, PKI re-issuance, and so on). Do not treat a green-looking score as 'done'; treat it as a map that keeps you honest about what remains.