Most tools in this space stop at a scan. They show you a list and ask you to believe it. This platform is built on a different premise: an inventory is only half the job. The other half is producing evidence a third party can verify — without an account, and without trusting us.
Here's what that takes.
The classification engine
The question that matters for post-quantum readiness isn't "do you contain cryptography." It's "what primitive is it, what is it doing, and when does that become a liability."
Primitive-first, never name-first. A component named crypto-utils tells you nothing. A component named rsa-signer might not even use RSA. The engine never classifies from a name. It resolves each asset's actual cryptographic primitive through a deterministic chain — declared properties, then the CycloneDX 1.7 (ECMA-424) cryptographic-asset model with its standardized algorithm families and elliptic-curve registry, then function inference, then a deliberately conservative fallback when evidence is ambiguous. Anything it can't resolve is flagged as unresolved — never silently passed as clean. Absence of a finding means "not yet detected," not "nothing here."
Usage-aware, because usage is the finding. "You have RSA" is trivia. "You have RSA doing key establishment on a high-value path — disallowed after 2030 and exposed to harvest-now-decrypt-later today" is a finding. The engine separates what a library implements from what an application actually uses, and maps each primitive-plus-usage to its obligation under Executive Order 14412:
- Key establishment → the 2030 deadline, plus harvest-now-decrypt-later exposure today.
- Digital signatures → the 2031 deadline.
- Sub-112-bit or legacy strength → weak today, quantum or not.
Reproducible against a pinned ruleset. The rules are versioned. Every result is attributable to the exact ruleset revision in force when it was produced, so a receipt issued today can be re-evaluated tomorrow against the same criteria. On top of risk classification, the engine runs structural conformance rules that check the integrity of the CBOM itself.
The output isn't a color. It's a structured, defensible, usage-resolved assessment.
The receipt
This is where it departs from every tool that ends at a dashboard.
A check is a private, perishable answer for you. A receipt is a portable, tamper-evident, cryptographically signed artifact that proves a specific manifest was assessed against a specific ruleset at a specific time and produced a specific result — and that a skeptic can verify on their own.
Content integrity. Each receipt binds its verdict to the exact input assessed. The normalized manifest is fingerprinted with SHA-384, and a Merkle root is computed over its components — so tampering is detectable down to a single component. Change one line of input and the receipt no longer verifies.
Classical and post-quantum, both. The receipt is a signed JWS carrying an RS256 signature and, over the identical signing input, an ML-DSA-65 (FIPS 204) post-quantum co-signature. The evidence that your cryptography is quantum-ready is itself signed with a NIST-standardized post-quantum algorithm.
It cannot lie about itself. The post-quantum claim is declared inside the signed payload. Before attaching the post-quantum signature, the signer verifies its own signature. If post-quantum signing is unavailable or fails self-verification, the claim is stripped and the payload re-signed as classical-only — and that's stated honestly in the receipt. There is no code path that produces a receipt claiming to be post-quantum-signed unless it verifiably is. The signer proves its capability with a sign/verify round-trip before advertising it, and fails open to classical rather than faking the claim.
That's the whole philosophy in one mechanism: the system is architecturally incapable of the exact lie this category is full of.
Independent verification
A receipt only the issuer can verify is not a receipt.
No account. No payment. No trust in us. Anyone holding a receipt can verify it, in the browser. It fetches the published key set, selects the signing key by its key ID, verifies the signature, and reports the key's status and validity window — was this key valid at the moment it signed? It surfaces and independently checks the post-quantum co-signature. The core check doesn't depend on our servers being online. The evidence stands on its own.
A transparent, rotating key set. Keys rotate on validity windows with key-ID resolution, published openly, with explicit statements about custody. Old receipts stay verifiable against the key valid when they were signed. Where a legacy field appears on an older receipt, the verifier surfaces and discredits it rather than quietly honoring it — the tooling warns you about its own history.
Hand the receipt to an auditor, a customer's security team, or a regulator, and let them prove it without asking you anything.
The intelligence layer
Higher tiers turn an inventory into a worklist:
- Live vulnerability correlation against OSV, the NVD, and GHSA, so cryptographic exposure is cross-referenced with tracked vulnerabilities, not assessed in isolation.
- License-risk surfacing alongside the cryptographic findings.
- Receipt-to-receipt comparison to track cryptographic drift across releases and prove what changed.
- Status badges for a live posture indicator.
Platform rigor
- The free check is stateless — full engine, retains nothing.
- The receipt path is abuse-resistant — bot mitigation, per-tier quotas and rate limits, hard ceilings.
- Fulfillment is idempotent — safe against retries by construction.
- Fail-open where safety demands it, fail-honest always.
The principle underneath
Every decision resolves to one rule: claim only what is true, and make the true claims checkable.
It's why the inventory resolves primitives instead of trusting names. Why unresolved assets are flagged, not hidden. Why the receipt fingerprints its own input, signs itself with a post-quantum algorithm, verifies itself before making the claim, and strips the claim if it can't stand behind it. Why verification needs no account and no server. And why, when something genuinely cannot be computed, it says so instead of printing a comforting zero.
You cannot migrate cryptography you cannot see. You cannot prove a posture you cannot verify. This is built for both — and the proving is the part almost everyone else skips.
Built on open standards: CycloneDX 1.7 / ECMA-424, FIPS 204 (ML-DSA), JWS, and the EO 14412 / NIST IR 8547 timeline. Verification is open to anyone, for any receipt, at any time.
Top comments (1)
One design call I went back and forth on the most: when post-quantum signing isn't available at issue time, should the signer fail OPEN (drop the PQ co-signature, issue a classical-only receipt, and say so explicitly) or fail SHUT (refuse to issue at all)?
I chose fail-open + honest declaration — the receipt states plainly whether the ML-DSA-65 co-signature is present, and there's no code path that lets it claim PQ when it isn't. My reasoning was that a verifiable classical receipt is more useful than no receipt, as long as it never overstates itself.
But I can see the argument the other way: fail-shut means every receipt that exists carries the same guarantee, no asterisks. No "well, this one's only RS256."
Curious how others would've called it — especially anyone who's shipped signing infrastructure. Where do you land: fail-open with honest downgrade, or fail-shut for a uniform guarantee?