Is Your Vendor Ready for PQC? The Questions, Ranking and Contract Terms in Thailand's SEC Quantum Guide Which PQC questions to send vendors, how to rank providers, and the six TOR terms in chapter 7 and Tool 4 of Thailand's SEC quantum guide, before you renew.
Is Your Vendor Ready for PQC? The Questions, Ranking and Contract Terms in Thailand's SEC Quantum Guide
Consider this hypothetical example: the IT team at a Thai securities firm emails its back-office software vendor to ask whether the product is ready for the quantum threat. The reply is one line: "Our product supports PQC." The team files it in the risk register and closes the item.
Under the quantum risk governance guide that Thailand's Securities and Exchange Commission (SEC) published in September 2569 (2026), that reply is not enough. Chapter 7, on supply-chain risk, recommends asking for supporting evidence instead of accepting a bare statement of PQC support (p. 22).
Post-quantum cryptography (PQC) is cryptography designed to resist attacks from both conventional and quantum computers (p. 38). TOR means Terms of Reference, the document defining the scope of work (pp. 22–23).
Short answer: rank vendors by business impact; ask for evidence that names the version, the standard, test results, limits and a usable date; put the terms in the TOR before choosing a vendor; and show the board a one-page view of key vendors before significant renewals.
The guide is guidance, not regulation: it calls itself preliminary advice, not a legal requirement (PDF p. 2), and sets no deadline. The full map of the guide is in the main article of this series .
Why your own readiness is not enough
Cloud, packaged software, trading and payment systems, key-protection hardware, certificates and external links all run on someone else's cryptography. The guide notes that if a key provider cannot migrate in time, the firm may be left with residual exposure, or unable to deliver a service, even when its own systems are ready. The risk does not move to the provider: when a vendor cannot answer clearly, record it as a risk with a follow-up date (p. 22).
Chapter 5 says the same from the inventory side: the cryptographic inventory (CBOM) must cover what the firm does not control directly, such as cloud, APIs and vendor hardware (p. 17). For related inventory work, see our article on asset inventories and ransomware prevention . How to start a CBOM is in the CBOM and crypto agility article .
Rank first: which vendors get the detailed questions
The guide advises against using the same assessment for every provider without adjusting its intensity to the service's importance and business impact (p. 23). Instead, start with providers whose failure or late migration would hurt most, such as cloud, core systems, trading and payment, certificate providers, key-management hardware and API connections, then rank them on several factors together (p. 22). The certificate authority behind your public websites counts; if you are unsure what you expose, start with an external attack surface review . The right-hand column is our illustration.
Factor in the guide (p. 22) Capital-market example Importance of the service Order routing, settlement Data the provider can reach KYC files, long-retained client trade records Use of digital signatures or authentication Online account opening, signed trade confirmations Difficulty of switching provider A core system tied to firm-wide data and processes Time the provider needs to update its product Hardware needing new firmware or replacement
The guide lists factors without assigning weights. Each firm should choose a prioritization method suited to its risks. The aim is a short list of vendors whose delay becomes your delay.
The questions to send
Page 22 lists five things a firm should at least know from each provider. Page 23 notes that obtaining a full CBOM may be possible only from some providers, because some have not prepared one or face trade-secret restrictions, and recommends defining the minimum information needed to assess risk instead: what each algorithm is used for, supported standards, product version, update schedule and the parts the firm must do itself.
Combined, that gives seven questions. The middle column is our wording.
Question to the vendor Evidence to expect Page 1. Which version supports which standard? Version and standard number 22, 23 2. What does cryptography do in the product? e.g. key exchange, signing 23 3. Must software, firmware or hardware change? Update, or hardware swap 22 4. Which systems was it tested with? Results and test environment 22 5. Performance and compatibility limits? Effect on speed and connected systems 22 6. When can we actually use it? A date tied to a version 22, 23 7. What must we do ourselves? e.g. configuration, new certificates 23
For zcr product pricing, see the pricing page .
For question 1, insist on the standard number. The guide cites NIST's FIPS 203–205 as the first PQC standards (pp. 9, 38). Per NIST, which published them on 13 August 2024, FIPS 203 specifies ML-KEM for establishing a shared secret key, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) cover digital signatures. Those names come from NIST, not the SEC guide.
The CISA, NSA and NIST Quantum-Readiness factsheet (August 2023) adds that discovery tools may miss cryptography embedded in products, so ask vendors to list it, and ask when and how they will ship PQC updates, at what cost.
Reading the answers
Tool 4 in Appendix ก records each vendor's PQC plan as confirmed, partly confirmed or not confirmed, with a ready date (p. 36). The guide does not define the three, but chapter 7's second question is a good yardstick: does the evidence state the product version, supported standards, test results, what the customer must change and the usable date (p. 24)?
Our suggestion, not a definition in the guide: use the five items to check completeness. The responsible owner should review the evidence, product version, test scope and availability for the firm's systems before assigning a status. Complete fields alone do not confirm readiness. Want to discuss this yardstick? Talk to our team ; hands-on vendor assessment is delivered through partners.
Then link the answers to your CBOM, as page 23 recommends, so you can see which vendor's delay would hold up which system.
TOR, contracts and renewals
The guide recommends a board policy that includes PQC and crypto-agility readiness in every new procurement from the requirements stage, with procurement, legal and the system owner jointly responsible and periodic reporting to the board on implementation (p. 22).
For important services, it lists at least six items TOR or contract terms should cover (pp. 22–23):
The standards and products the vendor must support
Delivery dates and the product update plan
Advance notice when the vendor changes its plan
Joint testing
The right to request information or carry out a review
What happens if the vendor cannot deliver on time
The strength of the terms should match the importance of the service. The guide gives headings, not contract wording; that is for your legal team. Its do/don't table also warns that choosing a vendor first and negotiating PQC later can weaken your bargaining position (p. 23).
For existing vendors, the lever is renewal. Management compiles and certifies Tool 4 and presents it on the Tool 3 reporting cycle and before significant contract renewals, with a renewal-date field and an option to review contract terms (p. 36). Chapter 9 asks whether the transition plan is tied to renewal cycles (p. 28); chapter 5 asks how the CBOM is updated at renewal (p. 19). Our practical suggestion: use renewal discussions to review the six items with procurement and legal, tailoring the terms to the importance of the service.
Contingency: decide before the vendor says it will be late
Page 23 suggests the board ask for contingency plans and decision points set in advance for key providers. Options include limiting the data or services used, isolating the connection, temporary measures, bringing forward an upgrade or preparing an alternative provider, each with impact, cost, time and decision-maker worked out beforehand. Industry cooperation, it adds, may reduce duplicate assessments. This may be useful if several firms depend on the same providers.
Tool 4: the one page the board should see
Tool 4 summarizes, on one page, the vendors whose late migration would affect critical systems or services (p. 36). Besides a header and boxes for the plan's key constraints and the decisions requested, it has five columns:
Column What gets filled in Vendor / provider name Name, owner Dependent systems and level of dependency Systems; high / medium / low PQC plan and ready date Confirmed / partly / not confirmed; date Impact if late / fallback / renewal date Impact, fallback, renewal date Urgency and proposed decision High / medium / low; set a timeframe, approve fallback, review contract terms, consider accepting the risk
Caution: Tool 4's sample row is a fictitious company, and the vendor timeframe in the Tool 3 dashboard example is illustrative too; the guide notes those figures are not requirements or SEC expectations (p. 34). Use the structure, set your own timeframes.
FAQ
Has the SEC set a deadline for vendors to be PQC-ready?
No. The 2026–2035 timeline in the guide comes from the National Cyber Security Agency's draft framework, which firms may consider aligning with (pp. 2, 27).
What if a vendor will not share its CBOM?
Ask for the minimum information (p. 23). If it still cannot answer, record a risk and a follow-up date (p. 22).
Where to start this month
Pull vendors from the contract register and shortlist them with the five factors.
Send the seven questions with a reply date you set.
Record answers in a Tool 4-style form linked to your CBOM.
Sort renewal dates and hand the six TOR items to procurement and legal.
Separately from vendor PQC plans, consider the provenance of software dependencies used through npm, PyPI, Go and Maven. zcrX supply-chain posture verifies the provenance of those dependencies by cryptographic proof or Agent attestation on enrolled hosts and build systems; a host without an Agent shows as not measured, not assumed safe. It checks software dependencies, not a vendor's PQC plan, so steps 1–4 stay with your team and partners. The PQC Readiness page explains what zcrX measures.
More in this series: The SEC quantum guide for directors · CBOM and crypto agility
Get in touch
Want a second opinion on which vendors to ask first? Talk to our team — the consultation is free. zcr supplies the software; hands-on assessment, deployment and transition planning are delivered through partners.
Sources
Thailand SEC, IT Risk Supervision and Inspection Department — คู่มือการกำกับดูแลความเสี่ยงจากเทคโนโลยีควอนตัม (Quantum Risk Governance & PQC Transition) สำหรับกรรมการบริษัท, September 2569 (2026) , in Thai — chapter 7 (pp. 22–24), Appendix ก Tools 3–4 (pp. 34, 36), chapter 5 (pp. 17, 19), chapter 9 (pp. 27–28), status statement (PDF p. 2). Read 27 October 2026.
CISA, NSA and NIST — Quantum-Readiness: Migration to Post-Quantum Cryptography (21 August 2023) — embedded cryptography; asking vendors about update timing and cost. Read 27 October 2026.
NIST — FIPS 203 , FIPS 204 , FIPS 205 — titles, algorithm names, publication date 13 August 2024. Read 27 October 2026.
Products | Pricing | Resources | Insights | Contact 