What is PQC?

Post-Quantum Cryptography (PQC) is a new generation of cryptographic algorithms designed to withstand quantum computers. A powerful enough quantum computer could break today’s encryption (RSA, ECC), making current security obsolete.

The “Harvest Now, Decrypt Later” Problem

Adversaries can store your encrypted data today and decrypt it later once quantum computers mature. Data with a long confidentiality lifespan—medical, financial, trade secrets—is already at risk, making PQC migration urgent.

Scan a source

Pick a source, optionally choose a report format, and submit once — a single submission produces the CBOM and, when a format is chosen, the rendered report.

Source type HTTPS URL Container image reference Container image archive (.tar / .tar.gz) Git repository (HTTP/HTTPS) Codebase archive (.zip / .tar.gz)

HTTPS URL Site or endpoint

The worker completes a TLS handshake with the endpoint and inventories what it negotiates — the key exchange, the record cipher, and every certificate in the chain. It never sends an HTTP request, so only the host and port are used; any path is ignored.

The key exchange is the finding that matters most: traffic captured today can be decrypted years from now unless the endpoint offers a post-quantum hybrid such as X25519MLKEM768.

Private Dedicated CBOM platform implementation with quantsec.pro available. Contact us at [email protected]

Report Report format

The CBOM is produced and downloadable for every scan, alongside the report.

Uploading…

PQC readiness scanning, in detail

Private PQC Scanning for Enterprises

We offer private, confidential scanning for organizations that require their infrastructure assessments to remain off public-facing tools—results are delivered securely and never published. In-depth dependency manifest scanning with reachability analysis — available with the fully supported enterprise edition.

The 0 to 100 readiness score

The score runs 0 to 100, higher is better. Every cryptographic asset the scan finds is classified quantum-broken (RSA, ECC, DH, DSA — all broken outright by Shor’s algorithm), quantum-weakened (Grover-halved or already deprecated, such as AES-128 or SHA-1), quantum-ready (ML-KEM, ML-DSA, SLH-DSA), or unknown. Each broken asset costs a full point, each weakened one half, each unknown three tenths, and the score is what is left of the inventory after that weighting. It describes the assets this scan found — not everything you own.

How each source is scanned

Website — live TLS probe

Not a file scan: we open our own connection and record the three things that fail independently—the negotiated key exchange, the bulk cipher, and for every certificate in the chain its public key and the signature its issuer applied. Support for post-quantum key exchange is established with a raw ClientHello offering only hybrid groups and an empty key share: a server that supports one answers HelloRetryRequest naming it, one that does not sends an alert. Neither completes a handshake nor sends a byte of application data. TLS version and handshake hash are recorded but kept out of the arithmetic—SHA-256 inside HKDF is not the weakness a collision rule would call it.

Git repository — clone and inspect

The repository is cloned and the working tree inspected. Detection is artifact-based, not static analysis: X.509 certificates (.pem, .crt, .cer, .der, .ca-bundle, PKCS#7), private keys and secrets via the gitleaks ruleset, OpenSSL configuration, problematic CA trust, and Java security policy—which also scores how likely a component is to be reachable at runtime. Source is not parsed for cryptographic API calls, so a repository that calls RSA through a library without shipping a key or certificate can score better than it deserves.

Source archive — extract and inspect

Identical inspection to a git clone, on an upload rather than a clone. The archive is treated as hostile and extracted under strict limits first: no absolute paths, no .., no symlinks escaping the tree, and caps on member count, uncompressed size and compression ratio. Coverage and its limits are the same as the git path — certificates, keys, configuration and trust stores, not source-level cryptographic API usage.

Container image — registry reference

The image is pulled through a Docker daemon and its assembled filesystem inspected with the same five checks. This is where certificate and trust-store findings are richest: base images carry CA bundles, OpenSSL configuration and not infrequently private keys. The honest limit is binaries—compiled executables are not disassembled, so cryptography statically linked into a Go or Rust binary leaves no artifact to find and will not appear in the inventory.

Container image — uploaded tarball

For images the scanner cannot reach: docker save output is uploaded, loaded into an isolated daemon, and then scanned exactly as a pulled reference is. Same coverage, same binary caveat. It exists so an image from a private registry never needs credentials handed to us—you export it yourself and send the result.