How it works
This page is in two parts. The first describes the Discovery Engine — what it reads, what it produces, and what it refuses to guess. The second is the roadmap, written as a roadmap.
Part A · What runs today
The Discovery Engine
You cannot migrate cryptography you cannot see. The Discovery Engine finds it, records where it is, and says what it means under the published standards. Everything on this page can be shown to you on a call.
Command-line discovery — in development
autopqc scan ./repository
What it reads
Source code in Java, Python, C#, Kotlin, Go and JavaScript/TypeScript, and dependency manifests. PEM and DER certificate files; PKCS#12 and Java key stores are recorded but not opened. TLS settings written in code.
What it produces
A Cryptographic Bill of Materials in CycloneDX format. Every finding carries its evidence: the file, the line, the API that was called, a redacted snippet, and the rule and versions that produced it.
The verdict on every asset
Each asset carries a post-quantum verdict drawn from a published, versioned classification table with its sources cited — NIST IR 8547, FIPS 203, 204 and 205, SP 800-131A and others. The table is public; you can disagree with a row and point at it.
What it could not do
The scan states plainly which parts of the scope it could not examine and which findings it could not resolve. Unknown is a reported result. The scanner does not guess.
The output
One report per scan
Every scan produces a single report. It opens in a browser, it needs nothing installed, and every line in it traces back to the scan that produced it.
- An exposure score, with the published method that produced it.
- What breaks by 2030 and what breaks by 2035, next to the documents that set those dates — NIST IR 8547 and SP 800-131A.
- The items to deal with first.
- Every asset found, each with its evidence attached.
- Which regulation cares — NIST, the EU Cyber Resilience Act, DORA, MAS and CSA.
- What the scan could not examine, and what it could not resolve.
How it behaves
The questions a security team asks first
The tool is designed to be approved by the people who have to approve it. Five properties, each of which you can verify yourself before you run it on anything that matters.
- It runs on your machine. Nothing is sent to us.
- It reads files. It never executes your code and never builds it.
- It opens no network connection.
- Secrets are redacted before anything is written.
- It never writes into the folder it is scanning.
How the releases are built
Releases are signed with Sigstore and are reproducible — you can rebuild one and check it matches. Each ships with its own SBOM, and with the CBOM of our own code. We run our discovery on ourselves first.
On accuracy
Accuracy is measured against public benchmarks and our own labelled corpora, and published with the method that produced it. We do not quote a figure here — a number without its method is not a measurement.
How we measure and report errorPart B · Where the platform is going
The roadmap
Everything below is planned work, described as planned work. None of it ships until it can be demonstrated, and each item moves to Part A on the day that is true.
Mapping
Each discovered asset will be matched, by the cryptographic role it plays, to its successor under the NIST standards — key establishment to FIPS 203, signatures to FIPS 204 and 205. Every mapping will cite the standard it follows.
Prioritization
The inventory will be ordered so that migration starts where it matters: what is reachable, what holds data with a long confidentiality life, and what a published deadline already covers. Every ranking will carry the reasoning that produced it.
Performance evaluation
Before a system changes, the platform will measure what the change costs — the classical algorithm against its post-quantum successor, on your own workloads rather than on ours.
Signed attestations
Attestations are planned to be signed under ML-DSA-65 with an SLH-DSA co-signature: two signature families with different mathematics and different failure modes, so that one falling does not take the record with it. The format is published today as a specimen; the signing, the key ceremony and the public lookup are not yet available.
Wider discovery
Live TLS endpoints, container images, key stores and hardware security modules, remote access configuration, code-signing pipelines and data transports. Each will be announced when it ships, with its own status label — not before.
The attestation format is published as a specimen so it can be reviewed before it exists in production.
See the specimen attestation formatThe engagement
Four moves, in order, every time
Around the product runs the engagement — the same four moves on every scope, each ending in something you keep. Every engagement produces a Discovery report first; nothing is prioritised or mapped before the inventory exists.
01
First read
- One conversation maps the estate's cryptographic surface and where its recording exposure actually sits.
- We name which engagement fits — one, a combination, or none. If you do not need us yet, we say so and stop.
- Nothing from the conversation is published, quoted or reused.
You keepA one-page position note: what we heard, what fits, what we would read first.
02
The letter
- A written scope with a boundary: what the work covers, what it deliberately leaves out, and the artefacts you keep at the end — named before anything begins.
- Access is read-only and scoped. We do not take write access, and we decline key material.
- The letter is amended in writing or not at all. There is no second letter hiding inside the first.
You keepThe engagement letter: scope, boundary, named artefacts.
03
The work
- The engagement runs as its page in the catalogue describes — same scope, same artefacts, same stated limits.
- Evidence accumulates as the work runs: coverage against the letter, the exception register's delta, and hours against what the letter said.
- Where anything changes in the estate, a rollback path is preserved and rehearsed before it is needed.
You keepThe evidence pack, updated as the work runs — not assembled after the fact.
04
The hand-off
- The register and artefacts are handed off with a decision log: what was found, what was decided, and what was deliberately left.
- The scope is recorded against the method version it was assessed under.
- Nothing is handed over that we cannot show you the evidence for.
You keepThe inventory, the evidence pack and the decision log, in one delivery.
Begin with certainty.
See what the Discovery Engine reads, what its report contains, and where its scope ends.