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 Cryptography Bill of Materials expressed in CycloneDX 1.7, 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 or cdxgen, 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.7 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. On arrival, nothing is taken at face value: the document is validated against the CycloneDX schema, its internal references are checked, and so is its signature when one is required. An invalid CBOM is rejected with an explicit reason. Every authentication failure is audited, with the source address and the reason for refusal, so that a gateway open to pipelines does not become a silent back door.
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".
What an estate export actually contains
An inventory that only covers certificates is not a CBOM. The PKIFactor estate export brings together three layers on top of the certificates themselves.
The first is the TLS actually served. For each managed certificate, the export carries the latest observation of every endpoint: negotiated version, decomposed suite, key exchange group. The configuration is not assumed, it is read back from the wire.
The second is the key inventory. Signing keys, certificate private keys held by the platform, the SCEP registration authority key, data encryption keys and the master key, service TLS keys: each one appears with its algorithm, size, state, dates and protection mode. On our demo estate, that amounts to 39 private and secret keys, in addition to the certificates' public keys. The non-negotiable point: the inventory is built from metadata only. No key is decrypted to be inventoried, and no secret material ever leaves in the document.
The third is SSH. The cryptography of an information system does not travel over TLS alone. As an option, the network scan reads an SSH server's algorithm offer and its host key, without ever authenticating. Key exchange, cipher and integrity algorithms are mapped onto the same canonical catalog as TLS, and weak choices are flagged. On an OpenSSH 9.2 server in our lab, the same scan surfaces both an offered post-quantum hybrid key exchange, sntrup761, and an HMAC-SHA1 still accepted. Both are true at the same time, and that is exactly what a CBOM must show.
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.
Three degrees of certainty: 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 posture of a network scan, one of the CBOM sources (demo data): deprecated TLS versions are observed, post-quantum risk is projected and capped, and the signed CBOM export starts from this view.
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.
That is what the PKIFactor export does for every observed service: the negotiated TLS suite is broken down into its algorithms, key exchange, authentication, encryption and integrity, each with its family, its OID and its NIST quantum security level. The document is validated against the official CycloneDX 1.7 schema.
A real excerpt of a CBOM exported by PKIFactor (demo data): a decomposed TLS suite, and the ML-DSA-65 signature covering the whole document.
A CBOM you cannot verify is worthless
An unsigned security inventory is just a document. PKIFactor signs every export in JSF, the enveloped signature native to CycloneDX 1.7, over an RFC 8785 canonicalization, and by default with a post-quantum signature, ML-DSA-65. No export leaves unsigned. 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, a single Python file you can read, checks the document's integrity offline, and its provenance as soon as the signer key is pinned, air-gapped, without trusting the interface.
Offline verification: the signature and the attestation to inventory binding hold, and a single altered character invalidates the document. Tool output shown in French.
Readable by the ecosystem, honest about its limits
A CBOM that only its producer can read is a dead end. We tested our exports against the tools on the market, and the result is mixed, so we report it as it is.
The reference tool cyclonedx-cli validates our documents. The CBOMkit viewer reads our export and extracts 46 cryptographic assets from it, with their primitives and functions. The share shown as "unknown" there is structural: the tool only rates algorithms, not certificates, keys or protocols.
A PKIFactor export read by the CBOMkit 2.3.0 viewer (demo data). The non-compliance banner is expected: the demo estate still contains RSA and TLS 1.0, precisely what the CBOM must make visible.
The real obstacle is the signature. The CycloneDX Java libraries cannot yet parse an ML-DSA signature enveloped in the document. Rather than weaken the default signature, PKIFactor offers a second export for tools: the CBOM without the enveloped signature, together with a detached ML-DSA-65 signature over its digest, verifiable by the same offline verifier. Integrity remains provable, and the document remains readable.
Finally, a limit we prefer to state: Dependency-Track 4.x does not yet ingest CycloneDX cryptographic assets, whoever the producer. Likewise, the quality of the code part of a CBOM depends on the tools that produced it. PKIFactor validates, normalizes and signs it, it does not reinvent it. A stated limit is worth more than an assumed compatibility.
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.
