Post-quantum readiness scanner

Find the cryptography in your code that won't survive a quantum computer.

Adversaries are harvesting encrypted data now to decrypt once quantum machines mature. You can't un-capture the past — and you can't migrate what you can't see. Point CipherChecker at a GitHub repo and it inventories the quantum-vulnerable cryptography in your source and dependencies, maps each to its NIST replacement, and prioritizes the fix.

Try a real one: · ·
Reads package.json, requirements.txt, go.mod, Cargo.toml, pom.xml, Gemfile, composer.json + source call-sites from the repo's default branch. Presence is a signal to review — not proof of vulnerable use. Need an audit-ready report? Compliance report + CBOM →

🔒 Your code stays yours. Don't want to share a private repo? Run our GitHub Action in your own CI — your source never leaves your runner, we only see the findings. And any compliance report we generate for you is yours alone: it carries no tracking or analytics.

Live scan result

Quantum readiness

Why "later" still matters today

Today — traffic captured
Stored, waiting
Quantum decrypt

Anything with a multi-year confidentiality lifetime — health records, legal files, state secrets, long-term contracts — is already exposed if it crosses a vulnerable channel today. The migration clock started before the computer arrived.

First, a definition

When we say crypto, we mean cryptography — not cryptocurrency.

Cryptography is the math that protects data: the encryption on your HTTPS connections, the certificates behind your VPNs, the digital signatures on your software updates, the keys guarding your stored records. Cryptocurrency is just one application that happens to use it — the way a car uses combustion. One is a product; the other is the underlying science.

Quantum computers threaten the science layer. That's why this reaches far past any single industry: RSA, Diffie-Hellman, and elliptic-curve cryptography — the algorithms securing essentially every digital system built in the last 30 years — all need to be replaced.

What CipherChecker scans

Cryptography in your code. The crypto libraries your project depends on and the algorithm call-sites in your source — RSA, ECDSA, ECDH, X25519, and the legacy hashes — the working math your codebase relies on.

What this is not about

Cryptocurrency. No coins, no wallets, no tokens. If a buyer's first thought is "blockchain," this section is why we put the definition up front.

The problem, stated as math

You can't fix the past. You can measure your future.

Encrypted data is already being intercepted and stored by adversaries who plan to decrypt it once quantum computers mature — a strategy called "harvest now, decrypt later." You cannot un-capture data that left your network years ago. What you can control is the math that decides whether you're already exposed.

[ how long your data must stay secret ]+[ how long migration takes you ]
vs.[ time until a quantum computer breaks today's encryption ]
When the first two added together exceed the third, you are already exposed today. Most teams can't even fill in the second value — because they've never inventoried where their vulnerable cryptography lives. That inventory is what CipherChecker produces.
Why the timeline debate doesn't change your decision

The deadline isn't Q-Day. It's your auditor.

Experts disagree on when quantum computers will break encryption — estimates cluster between 2030 and 2035, with some predicting sooner and some never. You don't need to win that argument, because your real deadline is regulatory, not physical.

2030
EU critical infrastructure

High-risk sectors (energy, finance, telecom) targeted to complete post-quantum upgrades by 2030. US requires TLS 1.3 adoption by Jan 2, 2030.

2031
UK NCSC priority systems

Migration plan due by 2028; highest-priority systems migrated by 2031, on the path to full migration.

2035
US / UK / EU full migration

NSM-10 sets 2035 for full federal PQC migration; NIST IR 8547 disallows quantum-vulnerable algorithms by 2035. NSA CNSA 2.0 starts in 2027.

CISA / NSA / NIST migration playbook

Every standard starts with the step most teams skip.

The official guidance is explicit: you cannot prioritize or migrate cryptography you have not identified. CipherChecker's output drops into each stage of the federal playbook.

Scope, stated plainly: CipherChecker inventories the cryptography that lives in your code and dependencies — the slice most teams can't see. Certificate, TLS-endpoint, and VPN discovery are separate inputs you'd combine with this for a full enterprise inventory. We don't pretend to scan your live infrastructure.
01

Establish a quantum-readiness roadmap

Assign an owner and set a baseline. The scan's readiness grade and summary become your starting line; re-scan to track progress.

→ Readiness grade + summary
02

Build a cryptographic inventory

Identify the quantum-vulnerable cryptography across your dependencies and source call-sites. This is the non-skippable first step — and the part of the inventory that hides in code.

→ Dependency + source-call-site inventory (CBOM)
03

Assess risk and prioritize

Findings are ranked by severity so you target the most exposed, longest-lived crypto first, not everything at once.

→ Severity-ranked findings + tiered plan
04

Map vulnerable algorithms to replacements

Every flagged primitive points to its NIST replacement: key exchange to ML-KEM (FIPS 203), signatures to ML-DSA (FIPS 204) or SLH-DSA (FIPS 205).

→ Per-finding NIST replacement mapping
05

Engage vendors and supply chain

Dependency findings show which third-party libraries carry the exposure, so you can ask those maintainers for PQC timelines and require crypto-agility in procurement.

→ Dependency / supply-chain findings
06

Prove compliance

The compliance report maps findings to NIST IR 8547 and NSA CNSA 2.0 with a dated posture — the audit evidence for the 2030 and 2035 mandates.

→ NIST IR 8547 / CNSA 2.0 compliance report
Straight about scope

What CipherChecker is — and what it honestly isn't.

It is

  • A scanner for your code and dependencies — step one of every official playbook
  • A risk-prioritization tool that ranks exposure by severity
  • A compliance-evidence generator mapped to NIST IR 8547 / CNSA 2.0 and the 2030/2035 mandates

It isn't

  • A way to stop interception or harvesting — that's a network-layer problem, not a scanner's
  • A certification — it's a detection-based assessment; findings are signals to review, with false positives and capped coverage
  • A one-time "are you safe?" checkbox — readiness is a multi-year program, and the scan is step one, repeated as your code changes

This honesty is the point. Anyone promising "quantum-proof in one click" is selling false comfort — there is no Q-Day announcement to wait for. The only defensible posture is to have already started. And you can't start what you haven't measured.

Free tool vs. done-for-you

Scan it yourself free — or have us handle it and prove it.

The scanner is free because seeing your exposure should be. What teams under a deadline actually pay for is having it done across their whole codebase, kept current, and signed off — the part a free tool fundamentally can't be.

Free · self-serve

See your exposure

For anyone. No signup.
  • Scan any public repo — readiness grade + crypto inventory
  • Prioritized NIST migration plan
  • Copy-paste fix-PR preview
  • Run our GitHub Action on your private code in your own CI — nothing leaves your runner
Talk to us

Book a 20-minute post-quantum review.

Tell us your stack and what's driving this. We'll scan your code, walk you through exactly where you stand against NIST IR 8547 / CNSA 2.0, and map the fastest path to a signed, audit-ready report. The review is free.

Just want to look around first? Run a free scan →