What Is a CBOM? Building a Cryptographic Inventory and Crypto Agility under Thailand's SEC Quantum Guide What a CBOM (cryptographic inventory) is, how to start and prioritise one, and how crypto agility lets you swap algorithms without downtime, per SEC Thailand.
What Is a CBOM? Building a Cryptographic Inventory and Crypto Agility under Thailand's SEC Quantum Guide
An independent director at a Thai securities firm asks, mid-meeting, "Which of our systems still use RSA?" IT answers for the website at once. But the signatures on trade confirmations? The API to the e-KYC provider?
Chapter 5 of the SEC Thailand guide on quantum risk governance (September 2026) starts right there: a firm can't plan a cryptographic transition until it knows where its cryptography is (p. 17). This is part 3 of our series on the guide; the overview is the SEC quantum risk guide, summarised for boards .
Short answer: a CBOM (Cryptographic Bill of Materials) is a register of which system uses which cryptography, for what, who owns it and whom it depends on (p. 17). Crypto agility is the ability to replace or retire an algorithm in time, without interrupting service or rebuilding systems each time (p. 20). The CBOM shows where to change; agility lets you change while the business keeps running.
The guide calls itself preliminary guidance, "not a legal requirement or regulation" (executive summary; quotes from the guide are our translation from the Thai). What we summarise from the guide below is advice for each firm to adapt to its own context; the examples and the tool note are ours.
What a CBOM is, in boardroom terms
The executive summary makes the CBOM step 2 of 5, built "so that it is known which encryption algorithm each system uses, who is responsible and which service providers it depends on, for use in prioritising the transition." Chapter 5 adds that its value lies in showing where the risk is, what must change first, and which systems or providers a change would hit, not in its length (p. 17).
Cryptography hides in websites, apps, system connections, signatures, certificates, databases, devices and partner services (p. 17). The guide gives the board six completeness questions, shown beside an example we invented:
What the CBOM must answer (p. 17) Hypothetical example: a client trading app Which system is it in? The link between the mobile app and the order server What data or process does it protect? Client logins and orders What does it do? Key exchange; proving the server is genuine Who owns it? The business line running the channel (IT handles the technical side) Which providers does it depend on? The certificate provider; the app developer What happens next? Get the certificate provider's plan; schedule testing with the developer
Technical detail (algorithms, keys, certificates, protocols, libraries) belongs to system owners, with someone keeping it reviewed and current (p. 17). The guide sets no file format or mandatory fields, but a bare list of algorithms with no system, protected process or owner doesn't count (p. 18).
Weighing a tool to collect the technical side, such as certificates and algorithms on production hosts? See our pricing page and have a partner confirm scope first.
Where to start
This sequence draws mainly on chapter 5, plus the executive summary (the guide doesn't call them steps):
Start with critical systems and name the gaps. An example first-year outcome is "a cryptographic inventory of critical systems, identifying the parts not yet fully surveyed" (executive summary, marked as an example). That beats a progress percentage with no scope (p. 15).Count what you don't control: cloud, packaged software, APIs, payment systems, certificate providers and vendor equipment. Your change can stall on a provider that can't move in time (p. 17).Use several sources: system owners, documentation, discovery tools and vendor data, joined to the existing asset register (p. 18). One tool or one questionnaire doesn't prove coverage (p. 18). Gaps in the asset register can leave gaps in the CBOM if coverage isn't cross-checked against other sources (p. 18; see why you need to know what machines you have ), and certificates on forgotten domains count too (on the external attack surface ).Prioritise on at least five factors: how long data must stay protected, business criticality, use of quantum-breakable cryptography, risk of impersonation or forged signatures, and dependence on providers or legacy systems (p. 17). The guide rejects a fixed cutoff under which only data kept over 10 years is high risk, and notes that authentication, signing and transaction systems can rank high without long-lived data (p. 18). The data-lifetime logic is in our Harvest Now, Decrypt Later piece .Finish with an actionable list: systems to tackle first, each with a reason, owner, timeframe and remediation options (p. 18).Keep it current as systems, certificates, software and provider contracts change. A one-off CBOM is on the guide's don't list (p. 18).
Crypto agility in practice: changing algorithms without stopping the business
NIST has published standards, so why agility? The guide cites only "FIPS 203–205" (p. 9); NIST's own pages name ML-KEM (FIPS 203, for establishing a shared secret key) and ML-DSA and SLH-DSA (FIPS 204 and 205, for digital signatures). Those names are NIST's, not the guide's. Yet the guide's glossary notes that further alternative signature standards are still in preparation (p. 38), and chapter 6 says even approved algorithms may need replacing after a new weakness, a new requirement or a poor fit with some systems (p. 20).
So the question is how fast you can change again without clients noticing. Chapter 6 gives four pointers:
Don't hard-wire one algorithm. Critical systems should switch encryption methods without edits in many places or a rebuild. The board sets the expectation and asks for evidence; management and the technical team are responsible for architectural and development details (p. 20). Ask which critical systems still have an algorithm or certificate fixed inside them, and whether a funded, owned fix plan exists (p. 21).Lock down the configuration point. Centralised control without strong safeguards can become a prime target, so ask for evidence of segregated rights, approvals, logging and a backup plan (pp. 20–21).Know the answers before an urgent change: where to edit, how long it takes, who approves, which system or provider is the bottleneck. The guide says the CBOM should be the basis for those answers (p. 20), which is why the two have to be built together.Test under real load, with a rollback plan. PQC differs in key size, signature size and processing load, which can show up in login times, transaction speed, networks and devices (p. 20). For an order system at the market open, a test that only proves it connects is not enough (p. 21).
The guide recommends approving hybrid approaches (classical cryptography alongside PQC) only where they align with standards and have a supporting rationale, with management defining the combination method and exit conditions; a flawed combination can add weaknesses (p. 21). And agility covers hardware, firmware, certificates and external services, not only in-house apps (pp. 20–21).
You can view the demo before discussing scope with your channel partner.
Plugging it into the SDLC, procurement and audit
Step 5 of the executive summary says to integrate the work "into the system development lifecycle, procurement and audit." Phase 5 of the chapter 9 roadmap repeats the three, aiming for an organisation that "can maintain continuous visibility of its cryptographic algorithm use and does not slip back into a state of lost visibility" (p. 28).
Touchpoint What the guide recommends A boardroom question SDLC Expect new systems to be able to change algorithms; management confirms it's in design and procurement (p. 21) "Are new systems and new contracts prevented from adding work that will need fixing later?" (p. 30) Procurement PQC readiness and crypto agility in criteria for every new purchase, from the requirements stage (p. 22); existing providers' assessments linked to the CBOM (p. 23) Does the CBOM update on contract renewals and certificate changes without a new full survey? (p. 19) Audit Under the Three Lines Model, audit focuses on evidence: scope completeness, prioritisation rationale, exception approvals, remediation tracking (p. 14) "How does management prove the CBOM is complete and accurate, and has it cross-checked system owners, discovery tools and vendors?" (p. 19)
Appendix A adds evidence for the routine phase, including CBOM update records and the results of an emergency crypto-change drill (p. 32). A drill answers "how many days?" with a measured number.
Questions that tend to follow
Does this guide set a CBOM completion deadline?
This guide sets no mandatory CBOM completion deadline. The p. 3 table places CBOM work in 2026–2027, but that is the national planning frame from the National Cyber Security Agency's draft framework, which firms "may consider" aligning with (p. 2), and it is not a prediction of when the threat arrives (p. 3).
Must the CBOM be finished before any testing?
No. High-risk systems can go first, and phases can run in parallel with adequate controls (p. 28).
Can one scanning tool do it?
No. Discovery tools are one source among several (p. 18), and the guide endorses no product (p. 42). A tool sees which algorithm a host uses; the protected process and owner come from the system owner.
That said, not all of the technical side has to be entered by hand; tools can help collect it. zcrX uses lightweight Agents on the hosts and build systems you enroll to collect a certificate and algorithm inventory, scored quantum-safe, ready or not ready; a host with no Agent shows as not measured rather than assumed safe. zcrX shows the certificates and algorithms on hosts with an Agent installed. Identifying which process each item protects and who owns it, covering cloud or partner systems that can't run an Agent, prioritising, and planning the transition remain work for your team and your partners. The PQC Readiness page explains what zcrX measures.
More in this series
Get in touch
Questions about collecting a certificate and algorithm inventory, or want to see the real screens first? Talk to our team; the consultation is free. zcr supplies the software; hands-on surveying, testing and migration are delivered through partners.
Sources
NIST pages read on 27 October 2026. Page numbers are those printed in the guide; "executive summary" is the unnumbered Executive Summary page (page 2 of the PDF). The guide is in Thai; quotations are our translation.
SEC Thailand — Quantum Risk Governance & PQC Transition guide for company directors (September 2026, Thai) — executive summary; introduction (pp. 2–3); chapter 2 (p. 9); chapter 4 (pp. 14–15); chapter 5 (pp. 17–19); chapter 6 (pp. 20–21); chapter 7 (pp. 22–23); chapter 9 (p. 28); Appendix A (pp. 30, 32); glossary (p. 38); preparation note (p. 42)NIST — FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard — ML-KEM, for establishing a shared secret key; published 13 August 2024NIST — FIPS 204: Module-Lattice-Based Digital Signature Standard — ML-DSA, for digital signatures; published 13 August 2024NIST — FIPS 205: Stateless Hash-Based Digital Signature Standard — SLH-DSA, for digital signatures; published 13 August 2024 Products | Pricing | Resources | Insights | Contact 