PKIMM Evidence Note: This CBOM table format, seven assets, with algorithm, vulnerability status, proposed replacement, and priority tier, is the exact output format that PKIMM assessors expect to see as evidence of practical training at Level 3. When you complete the Mini CBOM Exercise at the end of Unit 3, your deliverable will look like this table, populated from the Meridian Agency profile. Keep it, it belongs in your PKIMM evidence package.
Unit 3 · Level 2 → Level 3 · Inventory, CBOM & Crypto Agility
Reading a Real CBOM —
Structure and Fields
In Lesson 3.1, you learned what a CBOM is and why it comes first. Now we open one up. By the end of this lesson, you will be able to read a CycloneDX CBOM the way you read a spreadsheet, not perfectly, but functionally.
Part 1
What Format Does a CBOM Come In?
Before you can read a CBOM, you need to know what you are looking at. CBOMs produced in the CycloneDX format come as either JSON (JavaScript Object Notation) or XML (Extensible Markup Language) files. JSON is the more common format today, it is human-readable, compact, and supported by all major tooling.
If you have never worked with JSON, do not worry. JSON is structured text. Every piece of data has a label (called a key) and a value. That is all it is. Here is the pattern:
"key": "value"
// Example:
"algorithm": "RSA"
"keySize": 2048
// Example:
"algorithm": "RSA"
"keySize": 2048
You do not need to write JSON. You need to read it, to look at a CBOM file and understand what each field is telling you about your cryptographic assets. That is the skill this lesson builds.
📌 CycloneDX Version
The examples in this lesson use CycloneDX 1.6, which introduced the dedicated cryptography schema. The cryptoProperties object, where all the cryptographic details live, was added specifically to support CBOM use cases. Earlier CycloneDX versions (1.4 and below) do not have this schema.
Part 2
The CycloneDX CBOM — Top-Level Structure
A CycloneDX CBOM document has a predictable structure. Think of it as a container with three main sections: a header that identifies the document, a metadata section that describes when and how it was created, and a components array that lists every cryptographic asset.
{
"bomFormat": "CycloneDX", // ← Always "CycloneDX"
"specVersion": "1.6", // ← Schema version
"version": 1, // ← Document revision number
"serialNumber": "urn:uuid:...", // ← Unique document ID
"metadata": { /* when, who, what tool */ },
"components": [ // ← THIS is where every crypto asset lives
{ /* Asset 1 */ },
{ /* Asset 2 */ },
...
]
}
"bomFormat": "CycloneDX", // ← Always "CycloneDX"
"specVersion": "1.6", // ← Schema version
"version": 1, // ← Document revision number
"serialNumber": "urn:uuid:...", // ← Unique document ID
"metadata": { /* when, who, what tool */ },
"components": [ // ← THIS is where every crypto asset lives
{ /* Asset 1 */ },
{ /* Asset 2 */ },
...
]
}
The components array is where your cryptographic assets live. Each entry in that array is one cryptographic asset, one certificate, one key pair, one algorithm implementation. Everything else in the document is administrative context for those entries.
Now let's go inside a component entry and understand each field.
Part 3 — Hands-On
Interactive Field Explorer
Below is a real CycloneDX CBOM component entry for a TLS certificate. Click any highlighted line on the left to reveal a plain-language explanation on the right. Work through every field, together they build your CBOM reading ability.
Quick-jump to any field:
meridian-cbom.json
CycloneDX 1.6
← Click a highlighted line
{
"type": "cryptographic-asset",
"name": "Website TLS Certificate",
"bom-ref": "cert-tls-website-001",
"description": "TLS cert for meridianagency.com. AWS ACM. Renews annually.",
"cryptoProperties": {
"assetType": "certificate",
"algorithmProperties": {
"algorithm": "RSA",
"keySize": 2048,
"nistQuantumSecurityLevel": 0,
"primitive": "pke"
},
"certificateProperties": {
"subjectName": "meridianagency.com",
"issuerName": "Amazon Root CA 1",
"notValidBefore": "2025-03-01",
"notValidAfter": "2026-03-01"
},
"relatedCryptoMaterialRefs": ["key-rsa-website-001"]
}
}
👆
Click any highlighted line in the JSON to see a plain-language explanation of that field.
type
Component Type
This field tells the parser what kind of BOM entry this is. For a CBOM, it will always be "cryptographic-asset". This distinguishes cryptographic components from software libraries, services, or hardware in a mixed SBOM/CBOM document.
Why it matters
When a tool reads a CycloneDX document, it uses this field to route the entry to the right processing logic. Without it, a TLS certificate and an npm package would be indistinguishable at the top level.
Value in this entry
"type": "cryptographic-asset"
name
Human-Readable Asset Name
A plain-language name for the asset, something a human can understand without decoding a UUID or a certificate fingerprint. Good names describe what the asset is and what it protects. This is the field you and your team will actually read when working through the CBOM.
Why it matters
In a real CBOM, this field is what makes the document useful in a meeting. "Website TLS Certificate" is immediately understandable. "cert-001" is not. Invest time in naming assets clearly, it pays off during migration triage.
Value in this entry
"name": "Website TLS Certificate"
bom-ref
Bill of Materials Reference ID
A unique identifier for this entry within the CBOM document. It is how other entries can reference this one. Think of it as the row ID in a database, it is what the
relatedCryptoMaterialRefs field points to when describing dependencies between assets.Why it matters
CBOMs capture relationships between assets, for example, a TLS certificate and the private key that goes with it. The bom-ref creates the link. Without it, the CBOM is a flat list rather than a connected dependency map.
Value in this entry
"bom-ref": "cert-tls-website-001"
description
Asset Description
Free-text context about the asset. This is where you record things that the structured fields cannot capture, who manages this asset, how it is deployed, which system it protects, and any operational notes relevant to migration planning.
Why it matters
When it comes time to migrate this asset, someone needs to know how it is managed and where it lives. "AWS ACM. Renews annually." tells a migration engineer exactly where to go. The description field is where institutional knowledge lives inside a CBOM.
Value in this entry
"description": "TLS cert for meridianagency.com. AWS ACM. Renews annually."
cryptoProperties.assetType
Cryptographic Asset Type
A controlled vocabulary field that classifies what kind of cryptographic asset this is. CycloneDX 1.6 defines the following types:
algorithm
certificate
related-crypto-material
protocol
An algorithm is the math. A certificate is the signed credential. Related-crypto-material includes keys, IV/nonces. A protocol is the communication standard (e.g., TLS 1.3).
Why it matters
Asset type determines what other fields are available. A "certificate" entry has a certificateProperties section with subject name and expiry. An "algorithm" entry does not. The type tells you what to expect in the rest of the entry.
Value in this entry
"assetType": "certificate"
algorithmProperties.algorithm
Cryptographic Algorithm
The specific algorithm this asset uses. This is the most important field for post-quantum migration planning — it is what determines quantum vulnerability. Common values you will see in the wild:
RSA — broken by Shor's ECDSA — broken by Shor's ECDH — broken by Shor's AES-128 — weakened by Grover's AES-256 — monitor only SHA-384 — monitor only
RSA — broken by Shor's ECDSA — broken by Shor's ECDH — broken by Shor's AES-128 — weakened by Grover's AES-256 — monitor only SHA-384 — monitor only
Why it matters
When you see RSA or ECDSA in this field, you are looking at an asset that needs to be replaced. That replacement is your migration task. This field is what drives the vulnerability classification and priority tier in your CBOM output.
Value in this entry
"algorithm": "RSA" // ← Broken by Shor's algorithm. Immediate priority.
algorithmProperties.keySize
Key Size (in bits)
The size of the cryptographic key, measured in bits. Key size affects both classical and quantum security levels. For RSA: 1024-bit is deprecated classically; 2048-bit is current classical minimum; 4096-bit provides more classical security but does not change the quantum picture: Shor's breaks RSA regardless of key size.
Why it matters
Key size tells you how much classical security margin exists. RSA-2048 is classically acceptable today but quantum-broken. RSA-1024 is broken by both classical and quantum computers, it is a double priority. For AES, key size determines the post-quantum security tier: AES-128 is weakened, AES-256 is acceptable.
Value in this entry
"keySize": 2048 // RSA-2048: classically OK, quantum broken.
algorithmProperties.nistQuantumSecurityLevel
NIST Quantum Security Level
A number from 0 to 5 that maps to NIST's Post-Quantum Security Levels, the same levels used to categorize the new FIPS 203/204/205 algorithms. This field explicitly states the quantum resistance of the algorithm:
Level 0 = No quantum security. Broken by a quantum computer. (RSA, ECC)
Level 1 = Equivalent to AES-128 post-quantum security.
Level 3 = Equivalent to AES-192 post-quantum security.
Level 5 = Equivalent to AES-256 post-quantum security. (Highest.)
ML-KEM-768 is Level 3. ML-DSA-65 is Level 3. SLH-DSA-SHAKE-256 is Level 5.
Level 0 = No quantum security. Broken by a quantum computer. (RSA, ECC)
Level 1 = Equivalent to AES-128 post-quantum security.
Level 3 = Equivalent to AES-192 post-quantum security.
Level 5 = Equivalent to AES-256 post-quantum security. (Highest.)
ML-KEM-768 is Level 3. ML-DSA-65 is Level 3. SLH-DSA-SHAKE-256 is Level 5.
Why it matters
This single number tells you immediately whether an asset is quantum-safe. Level 0 = migrate. Level 3+ = acceptable for most use cases. This field is the CBOM's answer to the question "is this safe against a quantum computer?"
Value in this entry
"nistQuantumSecurityLevel": 0 // ← Level 0. Must be replaced.
certificateProperties
Certificate-Specific Properties
This sub-object appears only for entries with
subjectName — Who or what this certificate identifies (the domain, server, or entity)
issuerName — Which CA signed this certificate (the trust chain)
notValidBefore / notValidAfter — The certificate's validity window
The expiry date is particularly important for migration planning, it creates a natural migration window. A certificate expiring in 6 months is already on your timeline.
assetType: "certificate". It captures the certificate's identity and lifecycle information:
subjectName — Who or what this certificate identifies (the domain, server, or entity)
issuerName — Which CA signed this certificate (the trust chain)
notValidBefore / notValidAfter — The certificate's validity window
The expiry date is particularly important for migration planning, it creates a natural migration window. A certificate expiring in 6 months is already on your timeline.
Why it matters
Certificate expiry creates migration deadlines. If this cert expires in March 2026 and PQC certificates are available from your CA by then, that renewal is your migration opportunity. The CBOM's certificateProperties field surfaces these windows explicitly.
Key fields
subjectName: "meridianagency.com"
issuerName: "Amazon Root CA 1"
notValidAfter: "2026-03-01" // ← Migration window
issuerName: "Amazon Root CA 1"
notValidAfter: "2026-03-01" // ← Migration window
✅ What you can now do
You can read a CycloneDX CBOM component entry. You know what each field means, why it exists, and what it tells you about migration priority. That is the functional literacy the course design document specifies for Lesson 3.2 — you have reached it.
Part 4
A Complete CBOM Entry — All Fields Together
Now let's look at the same entry as a completed CBOM row, the way you would see it in a working spreadsheet or the output of a discovery tool. This is how the CBOM is most often reviewed by non-technical stakeholders and migration planners.
| Asset Name | Asset Type | Location / Owner | Algorithm | Key Size | Quantum Level | Vulnerability Status | Proposed Replacement | Priority |
|---|---|---|---|---|---|---|---|---|
| Website TLS Certificate | Certificate | AWS ACM / meridianagency.com | RSA | 2048 | 0 | Broken by Shor's | ML-KEM-768 hybrid cert (when CA support is available) | Medium-term |
Notice that the spreadsheet format is a translation of the JSON fields into something any stakeholder can read in a meeting. The JSON is the machine-readable source of truth; the table is the human-readable working view. Both represent the same data.
In the Mini CBOM Exercise at the end of Unit 3, you will produce your output in this table format. The six columns, asset name, algorithm, vulnerability status, proposed replacement, and priority, are the same six fields we identified in Lesson 3.1.
Part 5
Reading Multiple Entries: The Meridian Agency CBOM
A real CBOM has many entries. Below is the complete CBOM for Meridian Creative Agency — the fictional 48-person marketing agency you will analyze in the Unit 3 deliverable. Study this table carefully. At the end of Unit 3 you will be asked to produce this yourself from the agency profile, using this as your answer key.
Read each row and notice: the vulnerability status and priority are determined entirely by the algorithm column. That column is the decision-maker in every migration project.
| # | Asset Name | Location / System | Algorithm | Quantum Vulnerability | Proposed PQC Replacement | Priority Tier |
|---|---|---|---|---|---|---|
| 1 | Website TLS Certificate | AWS ACM, meridianagency.com | RSA-2048 | Broken by Shor's | Hybrid PQC cert (ML-KEM) when CA support is available via AWS ACM | Medium-term |
| 2 | Google Workspace TLS (Provider-Managed) | Google Cloud — email & collaboration | RSA / ECDSA (provider) | Broken by Shor's | Monitor Google's PQC migration roadmap. No direct action required, track vendor announcements. | Medium-term / Monitor vendor |
| 3 | WireGuard VPN — Key Exchange | WireGuard daemon — all remote endpoints | Curve25519 (ECDH) | Broken by Shor's | Upgrade to a PQC-hybrid WireGuard implementation (e.g., WireGuard + ML-KEM). Monitor upstream project. | Immediate |
| 4 | Internal File Server — Self-Signed Certificate | Windows Server 2019 — internal network | RSA-2048 | Broken by Shor's | Replace with internally-issued PQC certificate or enroll in internal CA. Decommission self-signed cert. | Medium-term |
| 5 | Code Signing Certificate | Build server — software distributed to clients | RSA-2048 | Broken by Shor's | Replace with ML-DSA-65 signing cert when code signing CAs support PQC. High impact: client-distributed software. | Immediate |
| 6 | Legacy Invoicing App — RSA Authentication | On-premise server — accounts department | RSA-2048 | Broken by Shor's | Migrate authentication to PQC-capable method or replace legacy application. Architectural decision required. | Immediate |
| 7 | File Server Encryption at Rest (AES) | Windows Server 2019 — BitLocker / EFS | AES-256 | Not affected | No replacement required. AES-256 retains ~128-bit post-quantum security. Document and monitor. | Monitor |
⚠ Observation: Three "Immediate" Items
Notice that three of the seven assets carry an Immediate priority rating, the WireGuard VPN, the code signing certificate, and the legacy invoicing application. These are immediate because they either protect data in transit (VPN), carry supply chain trust implications (code signing), or represent a legacy system that is hard to update and carries long-lived authentication credentials. Immediacy is not just about algorithm vulnerability, it is about exposure level and migration difficulty combined. This is the triage logic that the CBOM makes possible.
🏛️
Persona Perspectives
Working With CBOMs at Your Level
Reading a CBOM looks different depending on your role. Select your persona.
Persona A — The Motivated Learner
The CycloneDX schema is a professional differentiator. Most people in security roles, even experienced ones, have heard of SBOMs but have never opened a CycloneDX CBOM file. The fact that you can now navigate one, understand every field, and explain why each field matters for migration puts you meaningfully ahead.
If you are pursuing SSCP or CISSP, understanding CBOM structure is directly relevant to the "Cryptography" and "Risk Management" domains. If you are aiming for a role in PKI or security consulting, this is the kind of hands-on literacy that distinguishes a candidate who understands the ecosystem from one who has only read about it.
Suggested next step: After this lesson, look up the CycloneDX 1.6 specification on cyclonedx.org and browse the example CBOM files in the GitHub repository. Seeing real-world examples from actual tooling output will deepen the structural literacy you just built here.
Persona B — The SMB Decision-Maker
You do not need to produce a CycloneDX JSON file yourself. What you need is two things: to understand what your IT provider is doing when they say they are producing a CBOM for you, and to be able to read the table output they hand you.
The table in Part 5 of this lesson, the Meridian Agency CBOM, is exactly what a good MSP or IT vendor should deliver. Seven rows, each with an asset name, algorithm, vulnerability status, proposed action, and priority. If someone hands you a 40-page PDF with no structured table, that is not a CBOM. That is a report. Ask for the structured table.
💬
How to ask your IT vendor or MSP to produce a CBOM for you
Persona B — Copy and sendUse this prompt verbatim in an email or meeting with your IT provider or managed service provider. It uses language they will recognize, and it specifies the output format so you receive something useful rather than a generic security assessment.
We are beginning our post-quantum cryptography migration planning and need a Cryptographic Bill of Materials (CBOM) for our organization. Please produce a structured inventory of all cryptographic assets in our environment, including TLS certificates, VPN configurations, email certificates, code signing certificates, authentication credentials, and any encryption used in applications or on servers.
For each asset, we need: (1) the asset name and where it lives, (2) the algorithm and key size in use, (3) whether it is vulnerable to quantum attack per NIST guidance, (4) the proposed post-quantum replacement, and (5) a priority tier (Immediate / Medium-term / Monitor).
Please format the output as a structured table. We are targeting PQCMM Level 3 maturity and will use this inventory as a compliance artifact in a PKIMM assessment. The CycloneDX 1.6 format is preferred if your tooling supports it, but a structured spreadsheet in the format above is acceptable.
For each asset, we need: (1) the asset name and where it lives, (2) the algorithm and key size in use, (3) whether it is vulnerable to quantum attack per NIST guidance, (4) the proposed post-quantum replacement, and (5) a priority tier (Immediate / Medium-term / Monitor).
Please format the output as a structured table. We are targeting PQCMM Level 3 maturity and will use this inventory as a compliance artifact in a PKIMM assessment. The CycloneDX 1.6 format is preferred if your tooling supports it, but a structured spreadsheet in the format above is acceptable.
What to expect back: A good MSP will use a discovery tool (we cover these in Lesson 3.4) to scan your environment and produce the table. This typically takes 2–4 hours of their time for an organization at your scale. If they quote significantly more than that, ask what the added scope includes.
Persona C — The IT Professional
You now have the field-level knowledge to both produce and validate a CycloneDX CBOM. Producing means either using a discovery tool (covered in Lesson 3.4) or manually documenting assets in CycloneDX-compatible format. Validating means checking that a CBOM produced by a vendor, tool, or colleague is complete and correctly structured.
The field that deserves your particular attention is nistQuantumSecurityLevel. Not all tools populate this correctly, some discovery tools will flag AES-128 as "Level 1" when the context is key wrapping using RSA (which is Level 0). Always cross-check the quantum security level against the algorithm field. If they contradict each other, the algorithm field wins.
On scope: For your first CBOM, consider scoping to a single system or network segment rather than the whole organization. The Meridian Agency exercise (7 assets) is representative of what a well-scoped first pass looks like. A single business-critical application will typically surface 3–8 cryptographic assets. Start there, validate the methodology, then expand.
On tooling: Lesson 3.4 covers discovery tools in depth. If you want a preview: IBM Guardium Quantum Safe, Cryptosense Analyzer, and open-source scanners like cq-quantum-safe all produce CycloneDX CBOM output. You do not need to build the JSON by hand.
Comprehension Check
3 QuestionsQuestion 1 of 3
In a CycloneDX CBOM entry, the nistQuantumSecurityLevel field is set to 0 for an RSA-2048 certificate. What does this value tell you, and what action does it imply?
Question 2 of 3
In the Meridian Agency CBOM, Google Workspace TLS is listed as "Medium-term / Monitor vendor" priority rather than "Immediate", even though its algorithm (RSA/ECDSA) is broken by Shor's algorithm. Why?
Question 3 of 3
A colleague reviewing the Meridian CBOM says: "The file server's AES-256 encryption is safe, so we can skip it in the CBOM, no point documenting something that doesn't need to be replaced." What is wrong with this reasoning?