Harvest Now, Decrypt Later Explained: Using Mosca's X + Y > Z to Decide Which Capital-Market Data Moves First Harvest Now, Decrypt Later explained for directors: use Mosca's X + Y > Z from Thailand's SEC guide to rank trade records, KYC files and long-dated contracts.
Harvest Now, Decrypt Later Explained: Using Mosca's X + Y > Z to Decide Which Capital-Market Data Moves First
Picture someone quietly copying the encrypted traffic between a broker and its partners: client trade histories, KYC files, contract drafts. They can't read it today, and they don't need to. They are waiting for a quantum computer that can.
Thailand's Securities and Exchange Commission (SEC) calls this Harvest Now, Decrypt Later (HNDL) in its September 2026 guide on quantum-risk governance for company directors, and makes it the first reason to start now: important data "may be harvested today, to be decrypted once the technology is ready" (executive summary, PDF p. 2; quotes are our translation from the Thai).
Short answer for directors: the damage comes later, but the harvesting can happen today. The guide uses Mosca's inequality, X + Y > Z: if the time data must stay secret (X) plus the time you need to migrate (Y) exceeds the time you expect to have left (Z), that data may already be at risk.
The guide calls itself preliminary guidance, "not a legal requirement or regulation" (PDF p. 2). This article summarises the guide's recommendations and separately identifies our examples and proposed approach. For the whole guide, see our summary of the SEC quantum-risk and PQC guide .
How HNDL works
The guide's infographic (p. 6) shows four steps: harvest the encrypted data → keep it while it is unreadable → wait for a sufficiently capable quantum computer → decrypt and expose the secrets. The guide describes attackers retaining encrypted copies for possible future decryption (p. 6), so the day data is intercepted and the day it is read may not be the same.
The exposed layer is public-key cryptography. Account opening, order routing, clearing and settlement rely on RSA and ECC for key exchange and digital signatures, which a capable quantum computer could break with Shor's algorithm; symmetric encryption such as AES is far less affected and manageable with suitable key sizes (p. 5). So the board's job is not to order all encryption replaced, but to have management separate what is high-risk, what can be fixed in-house, and what must wait for partners.
A 2023 joint factsheet from CISA, NSA and NIST likewise warns that threat actors may already be targeting data with a "long secrecy lifetime" through harvest now, decrypt later operations.
Which capital-market data should worry you
The guide (p. 6) gives examples; the table extends them with everyday broker and asset-manager cases. The right-hand column is our commentary.
Data What sets how long it must stay secret (X) Our note Trade history and investor data Legal retention periods (pp. 5–6) and the sensitivity of investment behaviour Deletion removes your copy, not the harvested one KYC files Personal data protected under Thailand's PDPA (p. 18) An ID number and birth date stay sensitive after the account closes M&A deals, research, large orders The period before disclosure (p. 6) Negotiation details may stay secret after the announcement Long-dated contracts Confidentiality terms, which the guide treats as one source of X (p. 13) Secrecy can outlast the contract Published market data Almost nothing secret HNDL is not the issue; order-signing systems still matter
Leaked personal data can add legal liability to business damage (p. 18); if your PDPA work is unfinished, our eight-point PDPA checklist is a good start.
Mosca's inequality: X + Y > Z
Chapter 3 (p. 12) moves the board away from guessing the year quantum computers arrive, towards asking whether the organisation could migrate in time if it came sooner than expected. The summary box on p. 13 defines the values:
X — how much longer the data must stay secret: for example customer data, trade secrets or M&A information.
Y — how many years the organisation needs to migrate: covering discovery, procurement, testing, legacy systems and partners / service providers.
Z — how much time the organisation expects to have left: there is no definite answer yet, so try the calculation for early, expected and late cases.
If X + Y > Z, the organisation should speed up prioritisation and begin migrating, because the data may already be at risk today.
The p. 12 illustration calls the danger zone the Quantum Exposure Window and sums up: the longer X or Y, the sooner you need to start.
X is not your retention period. Retention is an input; the question is how long the data must stay secret . The guide asks management to set X from business, legal and contractual requirements (p. 13), so data owners, legal and compliance must help answer it.
Y includes the work from discovery through retirement. The p. 12 illustration lists discovery, testing, procurement, partner coordination, cut-over and retiring the old system. A packaged system may wait on the vendor's next release even when your team is ready (p. 22).
Nobody knows Z, and the guide gives no number. It cites the Global Risk Institute's Quantum Threat Timeline report, which suggests the risk may become significant from the 2030s, while noting no one can say for certain (p. 1). Management should test at least three cases and see which systems would miss the line if the threat came early (pp. 12–13). The guide's 2030 and 2035 dates are planning frames, not Z (see the FAQ).
Assessment can begin before Z is certain. Management can gather X and Y for each system and test them against the three Z scenarios above, as the guide recommends (pp. 12–13). Use the results alongside the five prioritisation factors on p. 17. Our suggestion is to use the calculation to identify items needing further assessment; X + Y alone does not establish migration priority.
Which data and systems go first
Secrecy is not the only input. Chapter 5 (p. 17) asks for at least five factors together: how long the data needs protection, how critical the system is, whether it uses quantum-breakable cryptography, the risk of impersonation or forged signatures, and dependence on partners, providers or legacy systems. Page 18 rules out a fixed "over 10 years means high risk" line, and notes that authentication, signing and transaction systems can rank high without long-lived data, because a forgery hurts immediately. The guide calls this forgery risk Trust Now, Forge Later (TNFL); an order-routing system may have a short X and still belong near the front.
A sequence we suggest, assembled from pp. 12–18 of the guide:
List data types with an X for each , and where each figure came from.Map data to the systems that store or carry it, and the cryptography they use. This mapping forms part of the cryptographic inventory (CBOM), which should also identify cryptographic functions, system owners and dependencies (p. 17). The next article in this series covers it, and it is the same lesson as ransomware prevention starting with knowing which machines you have .Estimate Y per system , including procurement, testing and waiting on providers. Unsure where to start? Talk to our team .Run the three Z cases and flag systems that cross the line in the early case.Rank with the five factors into a list of systems to tackle first, with reasons, owners, timeframes and remediation options (p. 18).
Do and don't, from chapter 3 (p. 13)
✓ Do ✗ Don't Ask management to base the work on the organisation's own data , for both secrecy lifetimes and migration timesSubstitute industry averages throughout , overlooking legacy systems or organisation-specific dataHave management assess at least three cases: early, expected and late , to identify systems that may not migrate in timeFix on a single forecast year , then stop and wait when experts disagreeUse 2030–2035 as a frame for planning and prioritising work , not as the date the event is expectedTreat the migration plan as the incident date , or assume systems are certainly safe until that yearHave management prioritise critical systems first and propose targets based on risk and the readiness of systems and partners / providersSet the same timeframe for every system without regard to impact or the time actually needed
Scope and pricing models are on the pricing page .
Questions directors can ask at the next meeting
From the guide's governance questions:
Which of the organisation's data or transactions need protection for a long time and are at risk of being harvested today for decryption later? (p. 8)
Which data types must stay secret the longest, and how has management set X from business, legal and contractual requirements? (p. 13)
Does Y for critical systems include discovery, procurement, testing, legacy fixes and coordination with partners / providers, and what evidence supports it? (p. 13)
Has management calculated the early, expected and late cases, and if the event comes sooner than estimated, which systems might not migrate in time? (p. 13)
Expect evidence (Appendix A, p. 30, lists secrecy lifetimes with business impact, and key risks with reasons), not an "in progress" report with no scope, which the guide lists as a don't (p. 7).
FAQ
If data has already been harvested, does moving to PQC later help?
Our inference from the HNDL mechanism on p. 6 is that later changes to the organisation's systems do not alter the encryption of a copy already held by an attacker. How well data within the organisation is protected depends on the migration's scope and test results.
Does the SEC require migration to be finished by 2030?
No. The guide is guidance, not regulation (PDF p. 2, p. 4). The 2030 and 2035 dates follow the draft 2026–2035 quantum-readiness framework of Thailand's National Cyber Security Agency (NCSA), which the SEC says organisations "may consider" aligning with (p. 2). The guide's target table says systems holding long-secret data "should" reduce risk or migrate high-risk parts by 2030, and a note beneath it says the timeline is for planning, not a forecast of when the threat will occur (p. 3).
A last practical tip: put your X list next to your algorithm list
For the certificate and algorithm part of step 2, zcrX has a cryptography posture view that scores the inventory on hosts running its Agent as quantum-safe, ready or not ready; a host without an Agent shows as not measured rather than assumed safe. The team can compare not-ready items with secrecy lifetimes confirmed by data owners, using both as inputs alongside the guide's five prioritisation factors (p. 17). Cryptography posture measurement covers hosts running an Agent, and the guide warns against relying on one discovery tool (p. 18). Setting X, Y and Z, planning and migration stay with your team and your partner. The PQC Readiness page explains what zcrX measures.
More in this series
Get in touch
Want to talk through where your organisation should start estimating X and Y? Talk to our team — the consultation is free. zcr supplies the software; hands-on discovery, planning and migration work is delivered through partners.
Sources
All read on 27 October 2026.
Thai SEC — คู่มือการกำกับดูแลความเสี่ยงจากเทคโนโลยีควอนตัม (Quantum Risk Governance & PQC Transition) สำหรับกรรมการบริษัท, September 2026 (in Thai) — guidance status (PDF p. 2, p. 4), HNDL and TNFL (pp. 1, 5–6), NCSA draft framework (pp. 2–3), Mosca's inequality (pp. 12–13), prioritisation factors and PDPA (pp. 17–18), do/don't tables (pp. 7, 13), governance questions (pp. 8, 13), Appendix A evidence (p. 30)CISA, NSA and NIST — Quantum-Readiness: Migration to Post-Quantum Cryptography (August 2023, PDF) — harvest now, decrypt later; data with a long secrecy lifetime Products | Pricing | Resources | Insights | Contact 