"Where are we using RSA?" is a question that takes most enterprises six months to answer with confidence — and the answer always includes "in places we hadn't thought to look". That is the single most important fact to internalise before you write a PQC migration plan. The plan you can write today is, by definition, a plan against the assets you already know about. The risk you face is in the assets you don't.
What a CBOM is, plainly
A Cryptographic Bill of Materials is a structured inventory of the cryptographic assets in a piece of software, a system, or an organisation. The dominant standard is CycloneDX, an OWASP project, which added first-class cryptographic asset modelling in version 1.6. Where an SBOM lists packages and their licences, a CBOM lists algorithms, protocols, keys, certificates, and the libraries and hardware that implement them.
The six asset categories in a well-formed CBOM:
- Algorithm assets. RSA, ECDSA, ML-KEM, AES-GCM, SHA-256. Captured with family, mode, padding, parameter set, and the role the algorithm plays.
- Protocol assets. TLS 1.2 / 1.3, IKEv2, SSH, Kerberos. Captured with version, cipher-suite configuration, supported named groups, and signature algorithms.
- Related crypto material — keys. Asymmetric keypairs, symmetric keys, DEKs and KEKs, derivation chains. Captured with storage location, rotation policy, and the principals authorised to use them.
- Certificates. X.509 leaves, intermediates, roots. Captured with issuer, subject, validity, signature algorithm, public-key algorithm, and chain depth.
- Library components. OpenSSL 3.x, BoringSSL, AWS-LC, BouncyCastle, Java JCE providers, .NET CNG. Captured with version, FIPS mode, and build flags.
- Hardware tokens. HSMs, TPMs, smartcards. Captured with make, model, firmware level, FIPS certification level, and slot or partition population.
The point of separating these six is that each is a different lens. A row in the algorithm table doesn't tell you where the algorithm lives; the row in the certificate table tells you that. A row in the certificate table doesn't tell you what cryptographic library actually validates it; the library row does. PQC migration touches all six rows because the algorithm change cascades through every one of them.
Passive discovery, active discovery, and the gap
There are two common discovery patterns. Passive discovery walks artefacts you already have — source repositories, package manifests, configuration files, certificate stores, network capture. Active discovery probes running systems — TLS scans against advertised ports, PKCS#11 enumeration of HSM partitions, authenticated configuration reads.
Both miss the same thing: cryptography that lives in artefacts neither method can reach. Three categories where this consistently shows up:
- Vendor binaries. Banking applications shipped as compiled JARs, WARs, or native binaries with cryptography baked in. No source to scan. Documentation may or may not enumerate the primitives used.
- Embedded firmware. POS terminals, ATM controllers, card readers, IoT devices on the branch network. Each runs cryptographic code that the bank rarely controls and the vendor rarely documents.
- Operational scripts. Cron jobs, batch wrappers, archive utilities, backup encryption tools that accumulated over a decade. The certificate they pin or the cipher suite they enforce isn't in any system of record.
What good CBOM output looks like
A useful CBOM has three properties beyond the data model itself:
- Linkage. A certificate row points at the algorithm it uses, which points at the key it represents, which points at the HSM partition the key lives in, which points at the library that calls the partition. Without linkage, the CBOM is a stack of disconnected lists and PQC migration cannot be planned against it.
- Provenance. Every entry records how it was discovered (scanner X, configuration file Y, vendor attestation Z) and when it was last verified. Stale entries are dangerous because they look authoritative.
- Diffable output. The CBOM lives in a repository, gets regenerated periodically, and diffs cleanly between versions. Migration progress is the diff over time.
How to start, this quarter
Three concrete things in the first 90 days:
- Pick a small estate slice and CBOM it across all six categories. Two or three production services, every asset type. The goal is not coverage; the goal is learning what the tooling and process feel like before scaling.
- Capture the long tail in interviews. Two-hour sessions with the application owner, the platform team, the SOC, the PKI team. Write down what the scanners couldn't find. Most of the truly load-bearing crypto in any bank is in someone's head; the CBOM has to extract it.
- Wire CBOM regeneration into CI. The moment the CBOM is a once-a-quarter artefact, it starts rotting. The moment it regenerates on every release, it starts being useful.