Post-quantum cryptography, explained in plain English.
You don't need to be a cryptographer to act on this. This guide explains which cryptography quantum computers will break, why, what happens to your organization if you do nothing, and how to read every number in your CryptoScan report. Everything here matches our deterministic classification engine exactly — no AI guesswork.
Overview
Cisora CryptoScan is a cryptographic discovery and Cryptographic Bill of Materials (CBOM) platform. It continuously answers four questions about your organization's cryptography:
TLS certificates, SSH keys, cloud KMS/HSM keys, and crypto-library calls across your network, cloud, and code.
Every finding is graded against a hard-coded, auditable rules table — never an AI model.
A standards-based OWASP CycloneDX CBOM, exported in one click.
A prioritized fix list, expiry alerts, and drift detection over time.
The quantum threat, in 90 seconds
Almost every secure connection today is protected by public-key cryptography — RSA and elliptic-curve (ECC/ECDSA). It works because some math problems (factoring huge numbers, elliptic-curve discrete logs) are effectively impossible for normal computers. A large enough quantum computer running Shor's algorithm solves those problems efficiently — so the protection collapses, no matter how big your keys are.
You can't migrate what you can't see. Every framework — NIST, CNSA 2.0, India's CBOM mandate — begins with the same step: discovery. An accurate inventory of where your cryptography lives is the prerequisite for everything else. That's what the free scan gives you in a minute.
Run your first scan
- Enter a domain. Go to cisora.io and type a domain you own, e.g.
yourcompany.in. No signup, no install. - We scan your public surface. We find every subdomain ever certified for your domain via Certificate Transparency logs, then probe each live TLS endpoint.
- Read your report. You get an A–F readiness grade, your quantum-vulnerable percentage, certificates nearing expiry, weak TLS/ciphers, and a teaser CBOM.
The free scan only ever looks at your external surface and reads public metadata. It never connects into your network and never sees a private key.
Algorithm explorer
This is the exact rules table our engine classifies against. Click any algorithm to see, in plain English, what it's used for, which attack breaks it, what happens to you if you don't fix it, and what to migrate to. Filter by status or search by name.
Every verdict above is fixed in code and cites a published standard (NIST FIPS 203/204/205, IR 8547, CNSA 2.0, SP 800-131A, RFC 8996/7465). An AI model never assigns a status — a hallucinated "RSA is safe" in a compliance artifact would be catastrophic.
Two quantum attacks: Shor's vs Grover's
Nearly all quantum risk comes down to two algorithms. Knowing which one applies tells you whether you have a five-alarm fire or a plan-ahead situation.
🧨 Shor's algorithm
Breaks public-key crypto completely. It efficiently factors large numbers and solves discrete logs — the hard problems RSA, ECDSA, ECDH, and Diffie-Hellman rely on. A bigger key does not save you; the whole approach fails.
Quantum-vulnerable Affects: RSA, ECC/ECDSA, ECDH, DH, DSA, Ed25519/Ed448, X25519/X448.
🔎 Grover's algorithm
Weakens symmetric crypto by half. It speeds up brute-force search, so a 128-bit key behaves like ~64-bit. The fix is simple: double the key size. AES-256 and ChaCha20 keep ~128-bit strength and stay fine.
Weakened Affects: AES-128, AES-192. Safe AES-256, ChaCha20.
A third bucket has nothing to do with quantum at all: algorithms like MD5, SHA-1, RC4, 3DES, and TLS 1.0/1.1 are already broken by ordinary computers and exploited today. Those are the most urgent of all — fix them now, regardless of quantum timelines.
"Harvest now, decrypt later" — why the deadline is already here
The most counter-intuitive part: you can be breached today by a quantum computer that doesn't exist yet. An attacker records your encrypted traffic now, stores it cheaply, and decrypts it the day a quantum computer arrives. Any secret with a long shelf-life — health records, financial data, government communications, source code, long-lived credentials — is already exposed.
This is why "we'll deal with quantum when the computers are ready" is the wrong posture. The clock on your long-lived data started the moment that data first crossed the wire.
What actually happens if you don't fix it
In concrete, plain-English terms — by status, the same five buckets the explorer uses:
| If a finding is… | What it means for you, untouched |
|---|---|
| Quantum-vulnerable | Once a quantum computer arrives, anyone who recorded your traffic can decrypt past sessions and forge your signatures to impersonate your services and software updates. A larger key does not help — only migrating to a PQC algorithm does. |
| Broken (classical) | Exploitable today, with normal hardware. Forged certificates, decrypted sessions, and downgrade attacks are demonstrated in the wild. Browsers, PCI-DSS, and auditors already reject these — leaving them on is an immediate finding. |
| Weakened | Safe for now, but a quantum computer halves the strength. Your long-lived secrets (anything that must stay confidential for years) are the exposure. Upgrade the key size before then. |
| Acceptable | Fine against current attacks. For TLS, the handshake's key exchange is still classical, so it becomes quantum-vulnerable later — plan to turn on hybrid PQC key exchange. |
| Quantum-safe | Meets post-quantum expectations. No action needed. |
The readiness grade
Every scan rolls up into a single A–F grade so a non-specialist can act immediately. It's computed deterministically from your findings, weighted by severity: classically-broken issues (expired certs, RC4, TLS 1.0) weigh heaviest, then quantum-vulnerable public-key crypto, then weakened algorithms.
The grade is the headline; the findings list is the work order. It tells you exactly what to fix and in what order.
Severity & the Quantum Risk Gauge
On the dashboard, the signature Quantum Risk Gauge shows the single number a board understands: the percentage of your discovered cryptography that is quantum-vulnerable. Each finding also carries a severity that drives ordering:
The CBOM (Cryptographic Bill of Materials)
A CBOM is the inventory artifact regulators ask for: a machine-readable list of every cryptographic asset, its properties, and its quantum-readiness. CryptoScan exports the industry-standard OWASP CycloneDX 1.6 cryptography format, merging external scans and internal agent discoveries into one BOM, plus an India-framework-shaped compliance view (NIST IR 8547, CNSA 2.0, SP 800-131A). The free scan shows a teaser; the full export is part of the paid product.
Migration playbook
Once you can see your crypto, migration follows a predictable order. CryptoScan generates this fix list for you, prioritized by real risk:
- Kill classically-broken crypto first. Disable SSLv3/TLS 1.0/1.1, RC4, 3DES, MD5, SHA-1. These are exploitable today — no quantum required.
- Inventory every public-key usage. RSA and ECC certificates, SSH keys, KMS/HSM keys, and code-level crypto. You can't plan a migration you can't enumerate.
- Enable hybrid key exchange where supported. Turn on groups like
X25519MLKEM768in TLS 1.3 to protect today's traffic against "harvest now, decrypt later." - Move signatures to PQC. Plan certificate and signing migrations to ML-DSA (FIPS 204) or SLH-DSA (FIPS 205).
- Upgrade weakened symmetric crypto. Move long-lived data from AES-128 to AES-256.
- Track drift. Continuous monitoring catches new vulnerable crypto and expiring certs before they bite.
Crypto-agility CI/CD gate
Discovery tells you what you have today; the gate stops new problems from being added. Drop
cryptoscan-ci into your pipeline and it fails the build when quantum-vulnerable or classically
broken cryptography is introduced — MD5/SHA-1 hashing, DES/3DES/RC4, NULL/EXPORT ciphers, deprecated
TLS/SSL, or RSA keys under 2048 bits. Verdicts come from the same deterministic rules table as the rest of
CryptoScan, so CI and your CBOM never disagree.
Add it to GitHub Actions:
- uses: rahathusain/cisora-crypt/.github/actions/crypto-agility@main
with:
path: .
fail-on: broken # or: broken,quantumIt emits SARIF, so findings annotate the exact line on your pull request's
Files changed tab. Intentional references can be suppressed inline with a
cryptoscan:ignore comment. Exit code is non-zero on a violation, so the merge is blocked until
the crypto is fixed.
Standards & deadlines
| Framework | What it requires |
|---|---|
| NIST FIPS 203/204/205 | The finalized PQC standards: ML-KEM (key encapsulation), ML-DSA & SLH-DSA (signatures). The algorithms you migrate to. |
| NIST IR 8547 | Transition guidance — deprecation timelines for RSA/ECC through 2030–2035. |
| CNSA 2.0 (NSA) | Mandates PQC for US national-security systems, ramping from 2025–2027. |
| NIST SP 800-131A | Defines which classical algorithms/key sizes are disallowed or legacy. |
| India CBOM mandate | Readiness window centred on Dec 2026 for regulated entities — discovery + CBOM is the deliverable. |
References & further reading
Primary sources, so you can verify every classification yourself:
Security & privacy
We are a crypto-hygiene vendor, so our own posture is non-negotiable:
- Private keys never leave your environment. Scanners extract only metadata — algorithm, key size, public fingerprint, location, expiry. No secret key material is ever transmitted or stored.
- Deterministic classification. Quantum-vulnerability verdicts come from an auditable rules table mapped to NIST standards — never from an AI model.
- Least privilege. Cloud scanners use read-only roles; code scanners use read-only repo scopes. Every permission is documented.
- India-hosted. Data resides in AWS Mumbai (ap-south-1). TLS 1.3 in transit, AES-256 at rest, strict tenant isolation on every row.
FAQ
Do you need access to my servers for the free scan?
No. It reads only public Certificate Transparency data and connects to your public TLS endpoints the same way any browser would.
Will you ever see my private keys?
Never. Every scanner — external or internal — collects metadata and public fingerprints only. This is the single most important rule in the product.
Is the quantum-vulnerability verdict AI-generated?
No. It comes from a hard-coded, auditable rules table grounded in published NIST standards. AI is used only for optional conveniences like plain-language summaries — never for classification or CBOM contents.
Isn't quantum years away? Why act now?
Because of "harvest now, decrypt later" — data you encrypt today can be recorded and decrypted later. And because migration takes years: you can't inventory, plan, and replace cryptography across an org overnight. The deadline is set by your data's shelf-life, not by Q-Day.
What do I migrate to?
ML-KEM (FIPS 203) for key exchange, ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) for signatures, AES-256 for symmetric. The Algorithm Explorer above lists the exact target for each vulnerable algorithm.