The PQC Migration Evidence Workflow composes two nodes: structurally linting a pasted CBOM and classifying its declared algorithms, then computing per-row CNSA-2.0 migration deadlines for a declared system inventory. Each returns a receipt binding an execution_hash to its declared inputs and its structural findings. Read this before treating a receipt as proof that your organisation is, or isn't, post-quantum ready.
asserted from your declared inputs, not observed. A receipt from this workflow proves this structural lint and this date arithmetic over these declared inputs. It is not a statement that your systems are actually vulnerable, that your inventory is complete, or that a deadline is legally binding in your jurisdiction — verifying the declared inputs against reality is a separate, human step this workflow does not perform.
Stage 1 is the entry point: paste a CBOM, get classified findings. Stage 2 is the terminal receipt: declare an inventory row per system — informed by Stage 1's quantum-vulnerable findings — and get its applicable deadline.
Validates a pasted CycloneDX 1.6 Cryptography Bill of Materials against a hand-derived field subset (algorithm, key size, certification level, crypto functions) and classifies each declared algorithm asset as quantum-vulnerable or CNSA-2.0 target-aligned. A missing required field marks that component structurally invalid rather than guessed at.
For each declared inventory row (system class, asset type, deployment date, FIPS 140-2 certification), computes the applicable CNSA-2.0 deadline, days remaining, the earliest binding constraint, and a FIPS 140-2 Historical-list exposure flag. Every deadline carries a source citation, so a regulatory date shift is a declared re-pin, never a code change.
| The receipt proves | The receipt does NOT prove |
|---|---|
| The pasted CBOM's declared components match (or fail to match) the required CycloneDX 1.6 field subset. | That the CBOM is complete, or that it reflects every cryptographic asset actually in use. |
| Which declared algorithms match a fixed quantum-vulnerable or CNSA-2.0 target pattern list. | That an undeclared or misdeclared algorithm asset exists somewhere in your estate. |
| The CNSA-2.0 deadline, days remaining, and FIPS 140-2 exposure that follow arithmetically from a declared inventory row. | That the declared deployment date or system class is accurate, or that the deadline is legally binding for your organisation. |
That a third party can independently replay the arithmetic from the same declared inputs and reach the same execution_hash. | Any security posture assessment, audit opinion, or compliance determination whatsoever. |