Taking Inventory: You Can't Migrate the Cryptography You Can't See

The FIPS 140-3 rebuild left me with a validated cryptographic floor and an unfinished question. A validated floor means the algorithms underneath the platform are approved ones. It says nothing about which algorithms are actually in use above it, or how many of them a quantum computer breaks. Knowing that takes an inventory, and producing one turned out to need software the open-source scanners don't provide.

This is the fourth post in a series built on the same infrastructure. The first covered why it exists, the second the governance layer on top, and the third the FIPS 140-3 foundation this one stands on. This post is what came next: the tool that takes the cryptographic inventory, and the first deliverable of FEDLIN's Post-Quantum Readiness service that grew out of it.

For a Federal System, the Inventory Isn't Optional

For a federal system the inventory is a mandate. OMB M-26-15 (June 2026, superseding the 2022 M-23-02) directs agencies to inventory the systems running quantum-vulnerable cryptography and phases the migration out to 2035, with agency plans due that October. Executive Order 14412 put deadlines behind the migration that inventory feeds: key establishment by the end of 2030, digital signatures by 2031. The document those mandates ask for and the first artifact of a migration plan are the same object: a Cryptographic Bill of Materials.

What a given agency must file, and by when, is a program question that belongs to the people who own the compliance program. My part is producing the artifact and the engineering underneath it. That line matters, and I keep to it.

The Commercial Version of the Same Question

A company with no federal mandate arrives at the same inventory from a different direction. PCI DSS 4.0 asks anyone handling cardholder data to document where cryptography is used and review it every year (requirement 12.3.3); a customer's security questionnaire asks what you're doing about post-quantum; and the certificate lifecycle keeps shrinking, so knowing every place a key or a certificate lives stops being optional bookkeeping. The deliverable is the same (the same CBOM, the same verdicts), but for a commercial system it is usually less a one-time filing than the start of keeping cryptography inventoried and agile as it keeps changing.

A CBOM Is the Machine-Readable Version of the Question

A CBOM inventories the cryptography a system uses: the algorithms, the key sizes, the certificates, the protocols, and where each one lives, written in CycloneDX, the format (ECMA-424) that SBOM tooling already speaks. It is machine-readable and diffable, and it is precise about its own edges: it covers what static and runtime analysis can detect, and it flags where a finding is only heuristic. What it reports, it can defend.

Where the Open Source Ends and the Build Begins

Most of the discovery is already solved and open source. CycloneDX is a format; CBOMkit reads cryptography out of source, cbomkit-theia reads it out of container images and filesystems, and cdxgen inventories the dependencies. I use all of them. Two gaps sat between those tools and a deliverable, and those two gaps are what I built.

The first is the running system. The scanners read code and images, but a live system's real exposure is in what it negotiates (the TLS and SSH key exchange, the certificates in use, the key stores), and there was no turnkey way to turn that into a validated CycloneDX inventory. So I wrote the capture: it reads public certificate metadata, the effective SSH and TLS configuration, and the names and counts of key objects, and it emits schema-validated CycloneDX. It works from that public metadata, not from private keys or secret values.

The second is the judgment. A raw inventory lists what you have. Deciding where each asset has to go, its CNSA 2.0 verdict and migration target, is a deterministic ruleset I wrote and version. All of it, the open-source scanners and the code I added, runs as one container I can carry into an environment and run in place, air-gapped if the site requires it. Then I pointed it at my own cluster.

What a Running System Made the Tool Handle

Pointed at a live cluster, the capture sorts what it finds into what a quantum computer leaves alone and what it eventually breaks, the shape every one of these runs has. The data-at-rest encryption (AES-256) comes back quantum-resistant, so the tool records it and moves on; the asymmetric cryptography that sets up connections and proves identity (RSA on the internal PKI, ECDH carrying the key establishment) is the part that has to move. But a tally was the easy part. The reason to build against a running system was the cases a source scan never reaches, and those cases shaped what the capture had to do.

The clearest cases were in what the cluster negotiates, not what its code declares. A source tree tells you which cryptographic libraries are present; only the running system tells you the key establishment a service actually settles on when it answers a connection, and key establishment is exactly what the federal timeline moves first, by 2030. That is also the canonical harvest-now-decrypt-later surface: an adversary can record encrypted traffic today and hold it until the exchange protecting it no longer stands. A scan of source or images can't tell which exchange is really in force on the wire; reading the running system can. That gap is the reason the runtime capture exists at all, and the reason I couldn't have built this against a repository alone.

The SSH layer surfaced a genuine tension worth capturing rather than resolving: OpenSSH on the cluster offers an ML-KEM hybrid key exchange, and FIPS mode disables it, so the quantum-resistant option and the validated-module requirement point in opposite directions until the standard and the modules meet in the middle. Teaching the tool to record that as a documented finding on the migration path, rather than flattening it to pass or fail, was the kind of judgment the build is really made of.

A Cluster Is One Shape; Most Estates Are Another

Building against my own cluster was step one, and in some ways the easy one: it is a rich target: a running control plane, source repositories, container images, an SSH layer to read. Most estates this deliverable is for are a different shape. Plenty run their workloads on someone else's cloud (AKS on Azure, EKS on AWS) rather than OpenShift; there the capture is built to detect the platform and read Ingress TLS in place of routes, skipping the OpenShift-only surfaces cleanly instead of guessing. Others are thinner still: an agency that mostly consumes SaaS, or runs a handful of servers behind its edge, with no cluster to point the capture at and no first-party source to scan; its cryptography lives at its TLS endpoints, and whatever sits inside an authorized SaaS provider is that provider's inventory to migrate, not the agency's. So the tool grew a path for that shape too: give it a hostname and it reads the certificate and the key-exchange algorithm straight off the live TLS handshake. No cluster, public metadata only, the same secret-safe contract, nothing leaving the environment but the handshakes it opens.

An edge scan is a first pass, not the whole inventory, and the pipeline is built to say so. The endpoint reader is one collector among several (source dependencies, container images and filesystems, host configuration) that fold into a single CycloneDX CBOM, so the systems behind the edge come into view as each collector is pointed at them. And the whole thing travels as one air-gappable container. I proved that the way I prove everything in this series, by doing it: I stood up a throwaway VM in a commercial Azure boundary, loaded the container into it, and ran the endpoint scan end-to-end under FIPS, with a schema-validated inventory coming back out and no cluster anywhere in the picture. Generalizing from the one system I run to the many I don't (the estate with no cluster, the site that permits no egress) was most of the engineering. My cluster proved the method; a throwaway VM in a commercial cloud showed the container runs and returns a validated inventory outside it.

The Verdicts Are Tested Against Known Answers

A tool that renders a verdict on your cryptography has to be right, and "trust me" is not a validation strategy. So the classifier runs against a known-answer test bank: a certificate for each algorithm class, from RSA and ECDSA through the post-quantum signatures, each paired with the verdict it ought to return. Every change is checked against that bank before it goes anywhere near a real system. The verdict itself is a deterministic ruleset with no model in the loop at decision time: the same input always yields the same call, which is the property a piece of compliance evidence has to have. When a row says an asset is quantum-vulnerable, that call is reproducible and defensible, not a guess.

What the Overlay Decides

The scanners produce the raw inventory; the overlay I wrote decides where every asset goes, and that's where the value sits. Where an asset has to end up depends on whether the system is national-security or commercial, and putting the wrong target on an asset makes the roadmap worse than none. (The national-security path uses ML-KEM-1024 for key establishment, ML-DSA-87 for signatures, and the stateful hash-based schemes (LMS and XMSS) for firmware signing; the commercial path leans on ML-KEM and SLH-DSA.) Ranking the rows by how soon each breaks and how long its data has to stay secret is what turns an inventory into a sequenced migration roadmap.

Your Assessor Already Has a Place for Every Finding

The report reads in the terms an assessor already uses. Every row maps to a NIST 800-53 control the system is already assessed against. The inventory itself answers CM-8. Key establishment is SC-12; certificates, SC-17; the approved-algorithm verdict, SC-13; transport, SC-8; data at rest and the harvest-now exposure, SC-28. The CBOM is the CM-8 evidence and the Phase 1 cryptographic inventory M-26-15 calls for, in a single document. This is a readiness assessment and an engineering roadmap. The assessor renders the opinion, the program owner files it, and I produce the evidence and the plan beneath it.

The First Deliverable Is the Cryptographic Readiness Report

The pieces that inventoried my cluster (the runtime capture, the CNSA 2.0 overlay, and the container that keeps everything in place) are the engine behind the first deliverable of FEDLIN's Post-Quantum Readiness service, the one the executive-order deadlines make urgent. That deliverable has a name: the FEDLIN Cryptographic Readiness Report. For a client engagement the run is the same one described above, executed inside their boundary: the container goes to the data, the cryptographic map never leaves their environment. What comes back is the Report:

The Report ships signed with a detached SLH-DSA attestation over the artifacts. Verifying it re-hashes the report and checks the hash against the signature, so a recipient can tell whether anything changed after I produced it.

Prove It Where You Own the Stack First

The capture, the overlay, the validation discipline, the container that keeps the data in place: all of it ran against infrastructure I operate and maintain before any of it was offered to anyone. Operating the thing changes what recommending it means: I live with the findings on my own systems before I carry the method to anyone else's. That is the standard the whole series has been about: the infrastructure comes first, and the work I offer is what running it taught me.