Everyone is about to ask you for a CBOM. Few will tell you that a naive CBOM is worse than none: it gives you the illusion of knowing. The post-quantum migration fits in one sentence. You cannot migrate what you cannot see. The cryptographic inventory has become the artifact that NIST, national agencies and your auditors now demand. But listing three algorithms and two TLS versions is not enough. The real question is not "which algorithms do I have", it is "what do I know, with what certainty, and is it still true right now".
A CBOM is far more than algorithms
A CBOM, a Cryptographic Bill of Materials expressed in CycloneDX 1.6, is not a list of algorithms. It is the inventory of all your cryptographic assets: primitives like RSA, ECDSA, AES or SHA, but also protocols (TLS and SSH versions and suites), X.509 certificates, keys and their state, and the cryptography living in your code, the libraries and functions your applications call. The trap is twofold: reducing it to algorithms, and freezing it in a file. Your cryptography lives in three places, in the code, at runtime and on the wire, and it changes constantly.
Absorbing the CBOM of an entire information system
Watching the wire is not enough. The cryptography of your applications is born in the code and executes at runtime. PKIFactor aggregates these layers through an ingestion gateway. Your continuous integration pipelines already produce a CBOM, with tools like CBOMkit, cdxgen or Syft, and push it to a single endpoint. PKIFactor normalizes it onto its canonical algorithms, so that an RSA detected by cdxgen becomes the same asset as the one observed on the wire, with no duplicate and no contradiction. It tags the provenance of each asset, code or runtime, then folds it together with the observed inventory and the managed inventory into a single signed CycloneDX 1.6 document.
The sensitive point is identity. A client never declares which application it represents: its identity is proven, and that identity is the correlation key for the merge. Three mechanisms coexist. The first, and strongest, is mTLS: the client presents a certificate issued by PKIFactor itself, verified by a dedicated endpoint. Since PKIFactor is your authority, it issues the identities its own clients use. The second is workload OIDC: a GitHub Actions or GitLab CI pipeline authenticates with its native token, verified against its JWKS, with no secret to store. The identity is the repository itself, and an allowlist by repository or by organization controls who may push. The third, a scoped bearer token hashed at rest, serves as a fallback. In every case, the application feeding the inventory is the one identity proves, never the one a parameter claims.
Every cryptographic asset in the information system, whether it comes from the code, the runtime or the wire, lands in a single CBOM, dated, signed, with its provenance. This is what turns "seeing the exposed TLS" into "knowing all the cryptography of an information system".
A living inventory, not a snapshot
A frozen CBOM is stale the day it is produced. PKIFactor takes successive snapshots and computes drift. A weak algorithm that appears, an authority that flips, a service that regresses to TLS 1.0: all of it is detected when it happens, not at the next audit. The CBOM stops being a compliance deliverable and becomes an operational signal.
Epistemic honesty: observed, declared, projected
This is what separates a useful CBOM from a noisy one. Every finding carries an evidence status. An observed finding is seen on the wire, in real time: the served TLS handshake, the negotiated version, the actual key exchange group. Its severity is full, because it is a fact. A declared finding is read from the certificate or the record, a quantum-vulnerable authority, an RSA-1024 key: its severity is full as well, the fact is certain. A projected finding is a conditional threat, awaiting observation, like the well-known "harvest now, decrypt later". The decisive point: only the projected is capped. Crying quantum wolf across an entire estate is noise that drowns the real signal. PKIFactor caps the theoretical, leaves the declared at full severity, and raises a projected finding the moment it becomes observed.
The detail almost everyone misses
Exposure to quantum harvesting is a property of the service, the key exchange group negotiated and observed on the wire, not of the certificate's signing key. An ECDSA certificate is no more exposed than an RSA one to that threat: it is transport confidentiality that is exposed, and it is measured at the handshake, not by analyzing the certificate subject. From there comes a rigorous decomposition by scheme. An RSA-SHA256 is not a primitive: it is a signature, vulnerable to Shor, plus a hash, SHA-256, that Shor does not break. Conflating the two distorts the entire ranking. A serious CBOM separates signature, hash and key exchange, and assigns each its own level of quantum resistance.
A CBOM you cannot verify is worthless
An unsigned security inventory is just a document. PKIFactor signs its CycloneDX 1.6 export, with RFC 8785 canonicalization, and by default with a post-quantum signature, ML-DSA-65. The CBOM that speaks of quantum risk is itself signed in a quantum-resistant way. The verdicts, the attestation, are served separately from the inventory, the facts. A standalone verifier validates provenance and integrity offline, air-gapped, without trusting the interface.
From CBOM to lifecycle
None of this is a separate product. It is the projection of the platform that already discovers, classifies and manages these assets, PKIFactor, our CLM. The same engine that absorbs an entire certificate directory, classifies each certificate by real usage and automates ACME issuance on your existing PKI produces the signed attestation you hand to the auditor. All of it stays fully on premise, with no outbound call. An inventory of your cryptography has no business in someone else's cloud.
A CBOM is not a list you cannot trust, produced once for the audit. It is a living finding, up to date, that you can prove.
