Four of the nine things federal reporting asks for cannot be scanned. They do not exist in your infrastructure.
Federal cryptographic reporting asks for nine data items per system. Only some of them describe cryptography. The others describe the system’s identity: its FISMA system number, its FIPS 199 impact level, whether a program office designated it a High Value Asset, and where it is hosted.
No scanner can find those, at any quality. A certificate does not know the impact level of the system it protects. A config file does not know whether anyone called this an HVA. CISA’s own guidance says most of the nine are collected by hand, and GSA states plainly that no known tool captures all nine.
So PQCAT stops trying to scan them and reads them from your system of record instead. It ingests an eMASS, CSAM, Xacta or CSV export, your HVA list, and your records schedule, and binds every discovered cryptographic asset to the system that owns it.
The part that matters is not the nine. It is that every cell records how it got its value.
Each value is marked discovered by a scanner, imported from a named export with that file’s digest recorded, or asserted by a named person on a date under a stated authority. Anyone can hand you a nine-column spreadsheet by typing the missing six columns. That spreadsheet is an opinion formatted as a table, and nothing in it tells you which cells a person invented.
The provenance is sealed inside the same commitment as the values, under one ML-DSA-44 signature covering both the inventory and the reporting table. Change an impact level after the fact and it fails closed. Relabel a cell from imported to something you asserted yourself and that fails closed too, because how each cell was established is committed alongside what it says.
Coverage is recomputed from the sealed table, never claimed. A partial registry reports partial, and assets that matched no system are reported as unbound rather than dropped, because a tool that drops them reports better coverage than it achieved.
Built on that binding: a reconciliation against your last submission that separates newly discovered assets from newly deployed ones with per-asset evidence, so a higher count reads as a better inventory rather than a worse posture; a shared-responsibility proposal splitting your boundary between you and your cloud provider; a published Cryptographic Agility Index for a mandate that defines no metric; and a draft migration plan covering all nine required plan sections. In the CLI, in the air-gapped Enclave build, and in the Pro and Cloud dashboards.