Ten PQC Tools, One Migration Path, and What Each One Actually Runs

Updated 21 September 2026. Since the 19 September version, two things changed: our assessment tooling now seals three steps, the inventory, the exposure ranking and the migration plan, as linked signed receipts in one evidence file that anyone can check offline, and a third tool became usable in the browser.

The post-quantum transition is not a single product problem. An organization has to find every place it uses cryptography, decide which of the standardized algorithms to move to, re-encrypt data and transport without rebuilding everything at once, and then prove to someone that it did. We built ten tools that sit at different points on that path. This post says what each one is, what it actually runs, which are demonstrations, and which run post-quantum cryptography at all, because a migration plan built on a vendor's adjectives is worse than no plan.

An earlier, shorter version of this note said the tools shared "one cryptographic substrate", promised "zero vendor lock-in", and said each product page stated its status. All three were looser than the truth. What they share, where one vendor dependency remains, and where the status lives are corrected below.

One path, five stages

The path has five stages: discover what you have, benchmark the options, migrate in phases, comply with the regime you answer to, and extend into the systems that come next. The ten tools map onto those stages.

The ten, by stage

Discover

• Cryptographic Inventory. Scans source code and dependency manifests and emits a cryptographic bill of materials in the CycloneDX format. It states its own blind spots: cryptography reached transitively, compiled into binaries, loaded dynamically, or obfuscated can be missed. A bill of materials is an inventory, not a proof of correctness.
• Store-Now-Break-Later Risk Score. Ranks assets by their exposure to harvest-now, decrypt-later collection. The version you can run in the browser applies the published rule directly: an asset is exposed when the years it must stay protected plus the years its migration takes exceed the horizon you plan against. It is a forward-looking ranking, not detection of anything happening now.

Benchmark

• Algorithm Selector. Recommends among the standardized families for a given use. The version you can run in the browser today is a JavaScript port of the engine. One family, SLH-DSA, is marked as not buildable in our environment.
• Quantum Hardware Connector. Translates circuits and estimates the resources they would need. It does not submit jobs to any device. The machines its estimates target are IBM's cloud quantum processors, which is why it is the one tool in this set that cannot be fully on-premises.

Migrate

• Crypto-Agility Planner. Groups assets dependency-first, so the plan orders each asset after the things it relies on, and phases the work from classical to hybrid to post-quantum only.
• Key Management Service. Exposes an API compatible with AWS KMS so existing integrations keep working. Software only. Not FIPS 140 validated.
• Quantum Key Provenance. Built to certify seed and symmetric key material with an ML-DSA-87 signature that states where the entropy came from. Today its entropy pool runs on the operating system's random generator, so it says so and does not issue a quantum-entropy certificate. Post-quantum keypairs are outside its scope.

Comply

• Regional Compliance Bridge. Maps assets to the regimes in Costa Rica, Colombia, Mexico, Brazil, and Chile. It is a curated knowledge base, not legal advice.
• Migration Tracker. Evidence-gated: an asset counts toward compliance only when its migration has been verified, not when it has been declared. The public version is a seeded demonstration that saves nothing.

Extend

• Secure Agent Sandbox. Process-level isolation for running agent-generated code. Process-level is the honest description of what it does today.

What "one substrate" actually means

Every one of the ten writes to the same tamper-evident audit pipeline: a hash chain verified in both directions, so a record cannot be altered or removed without the break showing. That is the shared part, and it is why a migration run across several tools produces one continuous trail rather than ten logs.

The cryptography itself is not shared by all ten, because not all ten need it. Four of them, the Selector, Key Provenance, the Sandbox, and the Key Management Service, use a common engine that binds the standardized primitives. The other six do not use it. An inventory, a risk ranking, a migration plan, a compliance map, and a hardware estimate do not need to encrypt anything, and the Tracker is a demonstration.

Standards, not novelty

The engine is built on the NIST standards: ML-KEM-768 under FIPS 203 for key encapsulation and ML-DSA-65 under FIPS 204 for signatures, each backed by an executable round-trip proof in our registry. A hybrid envelope combines X25519 with ML-KEM-768, AES-256-GCM, and an ML-DSA signature, the intermediate shape of a phased migration before it goes post-quantum only. Other parameter sets are supported where a tool needs them. SLH-DSA under FIPS 205 is referenced but inactive. We are not inventing cryptography. We are making the move to the standardized algorithms tractable.

Sovereign by design

Nine of the ten are designed to run on infrastructure the organization owns, so that keys and inventory never have to leave its perimeter. The point of a migration is to end key-custody risk, not to relocate it to a new vendor's cloud. The tenth, the Hardware Connector, plans work for quantum processors that IBM owns, and no design choice of ours changes that. That is the one vendor dependency in the set, and the earlier version of this note should not have promised zero.

Status, stated plainly

• All ten are built, and each capability is bound to an executing test that passes.
• Three are usable in a browser today: the Selector, the Store-Now-Break-Later risk score, and the Tracker demonstration. A sample deliverable on the site shows the method run end to end on an invented bank.
• Eight run behind an API that has to be deployed alongside them. On this site they are described, not served.
• There is no production deployment yet. We are looking for the first deployment partners, and a first deployment will be reported as exactly that.

The reason to be this plain is the arithmetic that drives the whole field. If the time your data must stay secret, plus the time your migration will take, exceeds the time until a machine that can break today's public-key cryptography exists, you are already late. Nobody knows the third number. The first two are yours to measure, and the tools above exist to help you measure them.