Cryptographic change control and CBOM evidence

Quantsiv finds the cryptography quantum computers could break

It shows what to fix first, based on how long your data must stay secret, and flags changes that add more. Scanning runs inside your own build pipeline by default and produces a standard inventory of what it found: a Cryptographic Bill of Materials (CBOM).

Why it matters See the roadmap

A future quantum computer could break the public-key cryptography in wide use today, and the US and the EU have published dates for replacing it. Replacing it starts with knowing where it is. Quantsiv scans your code on every build and shows what is exposed, how long it stays exposed and what to move to.

Harvest Now, Decrypt Later

Attackers can copy encrypted data today and keep it until a quantum computer can unlock it. For data that must stay secret for years, the risk starts now.

Steal now, read later

An attacker does not need a quantum computer today. They only need to record your encrypted traffic and stolen data now, then decrypt it once a large enough quantum computer exists. RSA, ECDSA, Diffie-Hellman and DSA, the public-key methods in common use, all fall to a known quantum method, Shor's algorithm. For crypto-asset wallets the blockchain itself is the archive: a public key already on-chain is enough to forge a transfer later.

The real deadline is your data's lifetime

What matters is not when the quantum computer arrives, but how long your data must stay secret. If a system's data must stay confidential for 25 years, traffic recorded yesterday is already at risk. Health records, financial data, government communications and trade secrets often have to stay secret for years.

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 ECC can then be read, including data that must stay confidential for years more. For signatures the risk is different: future forgery, not reading old data.

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.

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.
Nov 2024

NIST proposes when today's algorithms retire

In the initial public draft of NIST IR 8547, 112-bit-strength RSA, ECC and DH, such as RSA-2048, are deprecated after 2030. All quantum-vulnerable public-key algorithms, including P-256, are disallowed after 2035.
22 Jun 2026

A US Executive Order sets deadlines for 2030 and 2031

Executive Order 14412 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.
24 Jun 2026

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

Five phases from 2026 to 2035, from the US Office of Management and Budget. Federal agencies build an automated inventory whose data "should populate a central Cryptographic Bill of Materials". Agency plans are due 22 Oct 2026.
~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.
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, with a proposed Federal Acquisition Regulation (FAR) rule 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, 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, build scripts, and the secure connections (TLS) of servers you name or prove you own. By default it runs in your CI, the automated build that runs each time your developers change code. 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 a separate track, against the signature deadline.

3. Prioritize

Results are ranked so the fixes that matter most come first, not the longest list. 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 writes a CycloneDX 1.6 CBOM, a SARIF file for code-scanning tools and a ranked report. Each build is compared with the latest build of your main branch, and the change check flags cryptography a change adds, so the migration does not slide back.

What Quantsiv does

Quantsiv finds cryptography by matching known patterns in code. It detects common cryptographic APIs in Python, JavaScript and TypeScript, Go, Java and Kotlin, C#, Rust, Ruby, PHP, C and C++, Objective-C, Swift and Dart, openssl, ssh-keygen and keytool commands in CI and shell scripts, and keys and certificates in PEM and SSH formats. Because it matches patterns, depth varies by language and some calls are missed.

Cryptographic Bill of Materials

Like an ingredients list for cryptography: what was found and where. Quantsiv writes CycloneDX 1.6 that passes the schema's strict validation, imports a CycloneDX 1.6 CBOM from any other tool, and exports the latest CBOM of every repository as one document.

Ranked by how long data stays secret

You declare how long each kind of data must stay confidential, and encryption and key exchange are ranked by that lifetime. Signatures are tracked separately against the signature deadline, because their risk is forgery, not someone reading old data.

Flags changes that add more

Each build is compared with the latest build of your main branch, and cryptography a change adds is flagged. Set rules for each kind of data and record exceptions with a named approver and an expiry date. Results go to GitHub Code Scanning as SARIF and, with the GitHub Actions template, to the pull request as a comment.

Runs inside your own build

A container, a ready-to-run package, with templates for GitHub Actions, GitLab, Jenkins and Azure DevOps. Scanning works offline. Only the CBOM and the details of each finding reach Quantsiv, and only if you upload them.

Keys, certificates and secure connections

Reads key and certificate files for algorithm and size, and never keeps the key itself. Probes the secure connection (TLS) of servers you name; the hosted service probes only domains you prove you own with a DNS record.

Wallet and custody code

Finds the signing and key exchange in common wallet libraries: secp256k1 and Ed25519 signing keys, Schnorr signatures, and ECDH and ECIES key transport. Once a wallet's public key is on the blockchain, its risk is a forged transfer, not decryption, and the finding's guidance says what to do until the chain accepts post-quantum signatures. Reads code, not the blockchain.

For AI coding assistants

A read-only connector (an MCP server) lets an AI coding assistant ask your rules and declared data lifetimes before it writes cryptography. The same check then runs in your build. The connector cannot change anything, and there is no AI model of ours in it.

What to move to

Where the use is clear, each finding names the standard to move to: ML-KEM (FIPS 203), ML-DSA (FIPS 204) or SLH-DSA (FIPS 205), with hybrid key exchange, old and new combined, during the transition.

Honest limits

Pattern matching misses calls made under another name or built at run time, outside code copied into a project (vendored code), and third-party packages (dependencies). We state the limits up front.

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:

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
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; 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.