See tomorrow. Secure today.

Quantsiv finds the cryptography quantum computers could break

Why it matters Get in touch

A quantum computer could break the public-key cryptography in wide use today.
Governments have published dates for replacing it.
Replacing it starts with knowing where it is.

This is where we come in. We scan your code on every build and show you what is exposed, how long it stays exposed and what to move to.

Two Quantum Threats

Harvest Now, Decrypt Later

Attackers can record encrypted traffic and copy encrypted data today, then decrypt it once a large enough quantum computer exists. This threatens encryption and key exchange, such as RSA encryption and Diffie-Hellman. The deadline is how long the data must stay secret: if it must stay confidential for 25 years, traffic recorded yesterday is already at risk.

Signature Forgery

Trust Now, Forge Later

Digital signatures prove that software, certificates, documents and transactions are genuine. A sufficiently powerful quantum computer could derive private keys from public keys and forge signatures, threatening RSA, ECDSA and EdDSA. The risk depends on how long keys and signatures must remain trusted, including in devices, certificate authorities and permanent records. In crypto wallets, an exposed on-chain public key could enable forged transfers.

AI coding assistants can repeat vulnerable defaults

Code assistants choose cryptography by completing familiar patterns, so they can repeat old defaults that a quantum computer could break. The code works and passes its tests, and it is still vulnerable.

Today

Capture

Attackers record encrypted traffic, copy encrypted data and store it.

Later

Decrypt

A large enough quantum computer breaks the public-key cryptography that protected the stored copies.

Then

Expose

Data whose encryption relied on RSA or elliptic curves can then be read. Signatures made with them can be forged.

The Deadline Is Already Set

These are published dates, not predictions. Standards bodies and governments in the US and the EU have issued dated guidance and requirements for replacing the vulnerable cryptography.

  1. 13 Aug 2024

    NIST publishes the replacement standards

    The US standards institute publishes three new algorithms: FIPS 203 (ML-KEM) to agree the keys that encrypt data, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. The replacements now exist.

  2. Nov 2024

    NIST proposes when today's algorithms retire

    In the initial public draft of NIST IR 8547, all quantum-vulnerable public-key algorithms, including P-256, are disallowed after 2035.

  3. 22 Jun 2026

    Executive Order 14412

    The order addresses the harvest-now, decrypt-later threat. It sets 31 Dec 2030 for post-quantum key establishment and 31 Dec 2031 for signatures on high-value assets and high-impact systems.

  4. 24 Jun 2026

    OMB M-26-15: the federal migration in phases

    Federal agencies build an automated inventory whose data "should populate a central Cryptographic Bill of Materials". Agency plans are due 22 Oct 2026. Five phases from 2026 to 2035.

  5. ~Dec 2026

    A proposed rule for federal contractors

    EO 14412 gives the FAR Council 180 days, about 19 Dec 2026, to propose a Federal Acquisition Regulation (FAR) rule requiring covered contractors to comply by 31 Dec 2030 with NIST's FIPS standards, including those that use post-quantum algorithms.

  6. ~Mar 2027

    Guidance on what a CBOM should contain

    CISA, the US cybersecurity agency, in coordination with NIST, publishes guidance on CBOM minimum elements within 270 days of EO 14412, about Mar 2027.

  7. 2030 – 2035

    Migration deadlines run to 2035

    Under EO 14412, key establishment by 31 Dec 2030 and signatures by 31 Dec 2031 on high-value assets and high-impact systems, and, once the FAR rule the order calls for is adopted, 31 Dec 2030 for covered contractors. NSA CNSA 2.0 sets exclusive-use dates between 2030 and 2033, depending on the category. In the EU, the NIS Cooperation Group roadmap (23 Jun 2025, a recommendation) asks for national strategies by end-2026, high-risk use cases by end-2030 and as many systems as feasible by 2035.

Sources: EO 14412, EO 14412 in the Federal Register, OMB M-26-15, NIST IR 8547, CISA Post-Quantum Cryptography Initiative, NSA CNSA 2.0, NIST FIPS 203, EU NIS Cooperation Group roadmap.

How Quantsiv Works

Four steps, from scanning your code to a standard record of its cryptography (a CycloneDX 1.6 CBOM).

1. Discover

Quantsiv looks for cryptography in source code, key and certificate files, configuration and infrastructure files, build scripts, and the secure connections (TLS) of servers you name or prove you own. Only the CBOM and the details of each finding reach Quantsiv, and only if you upload them.

2. Analyze

Each finding is checked against the algorithms a quantum computer could break: RSA, ECDSA, Diffie-Hellman and DSA. Encryption and key exchange are ranked by how long you say the data must stay secret, the harvest-now-decrypt-later risk. Signatures are ranked on their own track, by how long you say they must stay trusted, against the signature deadline.

3. Prioritize

A health record that must stay secret for years and a short-lived login token are not the same risk, even when both use RSA. Each finding says why it ranks where it does and, where the use is clear, which standard to move to.

4. Prove

Quantsiv generates a CycloneDX 1.6 CBOM, a SARIF file for code-scanning tools, and a ranked report. An AI agent can use this context to guide migration by identifying vulnerable cryptography, recommending quantum-safe replacements, and prioritising changes. Each build is compared with the latest main-branch build, flagging newly introduced cryptography to prevent regression.

What a finding looks like

The scan, the ranking and the checks are Quantsiv's real output for a sample repository written for this page. On real code the rules miss some calls; see the note under the capabilities. The agent's analysis and draft change are simulated, to show how the agent works through a finding.

example/billing-service branch main commit 1e94656 Scan complete Illustrative preview

Cryptographic inventory

Assets found
10
Quantum-vulnerable
9
Quantum-safe
1
Files scanned
8

Severity

  • Critical 4
  • High 5

Exposure

  • Harvest Now, Decrypt Later 4
  • Signature forgery 4
  • Use not classified 1

Findings

6 more assets
  • criticalECDH-256, key agreement web/src/card-vault.ts:3
  • highECDSA-256, certificate key certs/api.crt:1
  • highECDSA-256, key generation services/ledger/sign.go:12
  • highECDSA, signature services/ledger/sign.go:17
  • highRSA-3072, use not classified scripts/make-release-key.sh:3
  • safeX25519MLKEM768, hybrid key exchange deploy/nginx.conf:6

Finding: RSA-OAEP encryption

critical Harvest Now, Decrypt Later src/billing_export.py:10
Business context
Customer records must stay secret for 25 years (declared in the repository's quantsiv.yml)
Why it ranks here
Protects data that must stay confidential for 25 years.
The risk
RSA-based public-key cryptography is vulnerable to sufficiently capable quantum computers. Data intercepted today may become decryptable in the future if the relevant encryption or key-establishment mechanisms are compromised.
Move to
Replace RSA encryption/key transport with ML-KEM (FIPS 203) plus an AEAD.
Authority
EO 14412 (22 Jun 2026): post-quantum key establishment on high-value assets and high-impact systems by 31 Dec 2030. NIST IR 8547 (ipd): 112-bit RSA/ECC/DH deprecated after 2030, all quantum-vulnerable public-key algorithms disallowed after 2035.

Quantsiv AI: migration analysis

Analysis complete In your CI, on the model you choose Simulated output

The current implementation uses RSA-OAEP to protect exported customer records with a 25-year confidentiality requirement.

Not a drop-in swap. Here RSA-OAEP wraps the AES key that encrypts each export. ML-KEM does not encrypt a chosen key: it establishes a shared secret, and the data key is derived from it. AES-256-GCM keeps encrypting the records.

Recommended migration
  1. Review the existing RSA-OAEP encryption and key-management flow.
  2. Evaluate ML-KEM (FIPS 203) for post-quantum key establishment, including hybrid approaches where appropriate.
  3. Use an authenticated symmetric encryption scheme such as AES-GCM for payload encryption.
  4. Identify affected dependencies, integrations, certificates, and compatibility requirements.
  5. Prioritise the migration based on confidentiality lifetime and cryptographic exposure.
  6. Validate the updated implementation and run regression checks.
Priority
Critical, 25-year confidentiality
Affected
src/billing_export.py and the partner's decryption code, outside this repository
Standards
FIPS 203 (ML-KEM-768) for key establishment; AES-256-GCM for the records
Compatibility
The export format changes, and the partner needs an ML-KEM key pair. Exports already sent stay as they were.
Draft change
--- a/src/billing_export.py
+++ b/src/billing_export.py
@@ -4,10 +4,11 @@
 from cryptography.hazmat.primitives import hashes
 from cryptography.hazmat.primitives.ciphers.aead import AESGCM
-from cryptography.hazmat.primitives.asymmetric import padding
+from cryptography.hazmat.primitives.kdf.hkdf import HKDF
 
 def seal_export(records, partner_key, export_id):
-    data_key = AESGCM.generate_key(bit_length=256)
-    wrapped_key = partner_key.encrypt(data_key, padding.OAEP(mgf=padding.MGF1(hashes.SHA256()), algorithm=hashes.SHA256(), label=None))
+    # Key establishment: ML-KEM-768 (FIPS 203); the records stay encrypted with AES-256-GCM
+    kem_ciphertext, shared_secret = partner_key.encapsulate()
+    data_key = HKDF(algorithm=hashes.SHA256(), length=32, salt=None, info=b"billing-export v2").derive(shared_secret)
     nonce = os.urandom(12)
     body = AESGCM(data_key).encrypt(nonce, json.dumps(records).encode(), export_id.encode())
-    return {"wrapped_key": wrapped_key, "nonce": nonce, "body": body}
+    return {"kem_ciphertext": kem_ciphertext, "nonce": nonce, "body": body}

Validation

Checks on the draft change
  • target is a post-quantum alternative: ML-KEM-768
  • rescanned: RSA is gone
  • nothing quantum-vulnerable added
  • policy passes

Real output of Quantsiv's checks for the draft above. Your own tests run too when you set a check command; this sample sets none. A person reviews the change, and nothing is committed.

On every later build

A later pull request adds an RSA key. The change check compares it with the latest main-branch build:

gate
fail
new asset
RSA-2048 at src/partner_upload.py:6, high

Finding: TLS key exchange groups

critical Harvest Now, Decrypt Later deploy/nginx.conf:6
Found
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1; X25519MLKEM768 is recorded as quantum-safe; X25519 and ECDH-256 (P-256) are not.
Business context
Customer records must stay secret for 25 years (declared in the repository's quantsiv.yml)
Why it ranks here
Protects data that must stay confidential for 25 years.
The risk
A client that cannot use the hybrid group falls back to a classical one. Traffic on those connections can be recorded today and decrypted later.
Move to
Migrate key establishment to ML-KEM (FIPS 203), deployed as a hybrid with X25519 (e.g. X25519MLKEM768 in TLS) during the transition.

Quantsiv AI: migration analysis

Analysis complete In your CI, on the model you choose Simulated output

The server already offers the hybrid group first, so the work is in the clients that cannot use it. A configuration file gets guidance, not a code change.

Recommended migration
  1. Find the clients that still negotiate X25519 or P-256, from the server's TLS logs.
  2. Upgrade or retire those clients, starting with the ones that carry customer records.
  3. Remove the classical groups from ssl_ecdh_curve once traffic allows.
  4. Probe the endpoint again to confirm that the hybrid group is negotiated.
Priority
Critical, 25-year confidentiality
Affected
deploy/nginx.conf and the clients of api.example.com
Standards
FIPS 203 (ML-KEM-768) in the hybrid X25519MLKEM768 group
Compatibility
Clients that support no remaining group cannot connect once the fallbacks are removed.

Validation

Checks on the guidance
  • target is a post-quantum alternative: X25519MLKEM768
  • no other classical algorithm named

Real output of Quantsiv's checks for the guidance above. Changes to configuration, keys, certificates and token formats get guidance, never a diff.

On every later build

A later pull request adds an RSA key. The change check compares it with the latest main-branch build:

gate
fail
new asset
RSA-2048 at src/partner_upload.py:6, high

Finding: JWT signing

high Signature forgery src/auth/session_tokens.py:6
Business context
Signatures must stay trusted for 10 years (declared in the repository's quantsiv.yml)
Why it ranks here
Signatures must stay trusted for 10 years; deadline 31 Dec 2031.
The risk
A quantum computer could derive the signing key from its public key and issue tokens that every service accepts. Nothing has to be recorded first: the public key is public by design.
Move to
Migrate to ML-DSA (FIPS 204) or SLH-DSA (FIPS 205). Prioritise long-lived signing keys: code/firmware signing, CA and token-issuer keys.
Authority
EO 14412 (22 Jun 2026): post-quantum digital signatures on high-value assets and high-impact systems by 31 Dec 2031. NIST IR 8547 (ipd): disallowed after 2035.

Quantsiv AI: migration analysis

Analysis complete In your CI, on the model you choose Simulated output

These session tokens are signed with RS256, and other services verify them. Changing the algorithm changes the token format, so the agent gives guidance instead of a code change.

Recommended migration
  1. List every service and library that verifies these tokens.
  2. Confirm that each one can verify ML-DSA (FIPS 204) signatures before the issuer changes.
  3. Issue tokens with a new ML-DSA key, and accept both algorithms during the switch.
  4. Retire the RS256 key once no verifier depends on it.
Priority
High, signature deadline 31 Dec 2031
Affected
src/auth/session_tokens.py and every service that verifies the tokens
Standards
FIPS 204 (ML-DSA)
Compatibility
Tokens grow: an ML-DSA-65 signature is 3,309 bytes (FIPS 204), more than ten times an RS256 signature with a 2048-bit key. Check cookie and header size limits.

Validation

Checks on the guidance
  • target is a post-quantum alternative: ML-DSA-65
  • no other classical algorithm named

Real output of Quantsiv's checks for the guidance above. Changes to configuration, keys, certificates and token formats get guidance, never a diff.

On every later build

A later pull request adds an RSA key. The change check compares it with the latest main-branch build:

gate
fail
new asset
RSA-2048 at src/partner_upload.py:6, high

Find and rank the cryptography you need to replace. Built for the quantum era.

Discover and assess the cryptography in your code, keys and infrastructure files, see which risks to fix first, and get clear guidance on what to move to.

Multi-language support

Find common cryptographic APIs in Python, JavaScript, TypeScript, Java, Kotlin, Go, C, C++, C#, Swift and more, plus openssl, ssh-keygen and keytool commands in build scripts.

Cryptographic Bill of Materials

Automatically inventory the cryptography found in your repositories as a standard CycloneDX 1.6 CBOM, and import CBOMs from other tools.

Quantum risk assessment

Rank both quantum threats: encryption by how long your data must stay secret, signatures by how long they must stay trusted. The most critical risks come first.

Checks on every build

Flag quantum-vulnerable cryptography a change adds, on every build, with automated checks and feedback on GitHub pull requests.

Seamless CI/CD integration

Use templates for GitHub Actions, GitLab, Jenkins and Azure DevOps. Run scans on your own machine or inside your existing build.

Keys, certificates and TLS

Identify the algorithm and key size in key and certificate files, and probe the secure connections (TLS) of servers you name.

Infrastructure settings

Detect vulnerable key and TLS settings in Terraform, Kubernetes, CloudFormation, web-server, OpenSSL and OpenSSH files in your repository.

Wallet and custody code

Find the signing keys, signatures and key exchange in common wallet libraries, with guidance until the chain accepts post-quantum signatures. It reads code, not the blockchain.

AI coding assistant integration

Let AI coding assistants check your cryptography rules while they write code, through a read-only connector (MCP).

Post-quantum migration guidance

Get the standard to move to where the use is clear: ML-KEM, ML-DSA or SLH-DSA, with hybrid key exchange during the transition.

Privacy-first, offline scanning

Keep your source code in your environment: scans run offline by default, and findings reach Quantsiv only if you upload them.

Agentic AI analysis

An AI agent reads each finding in context and drafts a fix. If Quantsiv's checks or your tests reject the draft, the agent revises it, and you see only fixes that pass. It runs as an optional step in your build, on a model you choose. Nothing merges without a person's approval.

Detection is pattern-based, so depth varies by language, and rules for Rust, Ruby and PHP are early. It can miss calls made under another name or built at run time, calls to cloud key services, code copied into a project, and third-party packages.

Roadmap

Timed to the US and EU deadlines above.

Phase 1 · Now → 2027

Audit

Show where each application uses cryptography, from inside its build. The features above are built; next in this phase:

  • The AI agent learning from the changes your team approves
  • Post-quantum and hybrid cryptography counted as migration progress, across code, keys, certificates and configuration
  • An inventory of third-party packages (dependencies): which ones bring cryptography
  • COBOL code on mainframes, common in banks: its calls to the mainframe's cryptography service, and the mainframe's certificate and secure-connection settings
  • Reports that state their coverage, so a partial scan is not mistaken for a clean one
  • CBOM output aligned to the CISA minimum elements once published, about Mar 2027, and CycloneDX 1.7 accepted on import
  • CBOM evidence reports for auditors, citing the US and EU guidance
Phase 2 · 2027 → 2028

Migrate

Close the loop from finding to fix, with a person approving each change.

  • Suggested fixes as draft pull requests with the code change, the reasoning and the guidance cited, for a person to review
  • Migration targets that default to hybrid key exchange, with the platform versions each change needs
  • Tests that check each change before a person reviews it
Phase 3 · 2028 → 2030

Agentic Crypto-Agility

Agents propose and check each other's work; deterministic checks verify; a person approves. Nothing merges or deploys on its own.

Phase 4 · 2030 → 2035

Platform Consolidation

One product to install, covering audit, migration and review.

Get in Touch

Want to see what Quantsiv finds in your own code before launch, or have a question? Write to us.

hello@quantsiv.com

Privacy notice