In July 2026, we were invited by the Thai Bankers' Association (TBA) to present on preparing for post-quantum cryptography (PQC) migration in the banking sector. The session covered the regulatory landscape, the practical realities of cryptographic migration, and what banking sector guidelines should prioritise as PQC timelines accelerate.
This post summarises the four core recommendations from that presentation, along with the reasoning behind each.
The banking sector sits at the intersection of three factors that make PQC migration uniquely urgent.
First, banks hold long-lived financial data. Mortgage records, treasury positions, sovereign bonds, and compliance archives must remain confidential for 10 to 30 years or more. Data encrypted today with algorithms that a future quantum computer can break is already at risk through harvest-now-decrypt-later collection.
Second, banking infrastructure is cryptographically dense. TLS certificates are the visible layer, but underneath sit SSH keys, JWT session tokens, API authentication, cloud key management, database encryption, and source code dependencies. Most organisations do not have a complete inventory of what cryptography they are running, where, or in what configuration.
Third, banks operate across multiple regulatory jurisdictions simultaneously. A single institution may need to satisfy requirements from NIST (United States), the Bank of Thailand's IT Risk Management Guidelines, NACSA Directive 9 (Malaysia), and SBV Circular 50 (Vietnam), among others. Each of these frameworks is beginning to reference quantum-safe cryptography, and the timelines are converging.
A peer-reviewed study published in MDPI Computers (Campbell, December 2025) mapped the full dependency chain of enterprise PQC migration, including internal factors like personnel, budget, governance, and legacy systems, and external factors like vendor ecosystems, regulatory mandates, and HSM certification cycles.
The findings are sobering. Small enterprises face an estimated 5 to 7 year migration timeline. Medium enterprises face 8 to 12 years. Large enterprises and critical infrastructure operators face 12 to 15 years or more. These are not technology constraints alone. They reflect the operational reality of inventorying cryptographic assets, upgrading infrastructure, migrating applications, coordinating with partners and supply chains, and maintaining hybrid classical/quantum-safe operation throughout the transition.
The regulatory calendar does not wait for these timelines. NIST will deprecate RSA-2048 and elliptic curve cryptography by 2030 and remove all quantum-vulnerable algorithms by 2035. The US CNSA 2.0 framework requires new national security system acquisitions to support post-quantum algorithms from January 2027. Thailand's own NCSA announced a national PQC roadmap in June 2026. ISO published its first PQC algorithm standard (ISO/IEC 18033-2 Amendment 2) in June 2026, incorporating ML-KEM into the international encryption framework.
The gap between how long migration takes and how soon these deadlines arrive is the core risk calculation. Organisations that begin now have a chance of meeting them. Organisations that wait will be reacting under pressure.
The following recommendations are drawn from ExeQuantum's experience working with banking and financial services organisations across multiple markets, aligned with Thailand's NCSA PQC roadmap and international best practice.
The most common mistake in PQC planning is jumping to algorithm selection before understanding what cryptography is currently deployed. You cannot migrate what you cannot see.
Banking sector guidelines should recommend cryptographic inventory as the mandatory first step. This means producing a Cryptographic Bill of Materials (CBOM) that maps every cryptographic asset across the organisation: certificates, keys, protocols, algorithms, configurations, and dependencies. The CBOM is becoming a regulatory and procurement expectation globally. India's DST National Quantum Mission explicitly references cryptographic inventory in procurement requirements from FY 2027-28. CNSA 2.0 guidance assumes organisations know what they are running before they can plan a transition.
Cryptographic discovery also surfaces value immediately, independent of any quantum threat. Organisations routinely discover deprecated algorithms, weak key lengths, and misconfigured protocols that represent classical vulnerabilities today. These findings often go undetected by traditional penetration testing because pentests evaluate application-layer security, not cryptographic configuration at depth.
Algorithms will change. HQC was added to the NIST PQC portfolio in 2025, well after the initial selections. FrodoKEM received ISO standardisation in June 2026. Future algorithm changes, additions, or deprecations are a certainty.
Banking sector guidelines should require architectures that can switch algorithms without re-engineering. This means avoiding hard-coded algorithm dependencies at the application layer and instead managing algorithm selection through configuration, not code changes. The goal is an infrastructure where a new algorithm standard can be adopted through a dashboard update, not a multi-month development cycle.
Locking banks into today's algorithm selections would repeat the mistake that created the current migration challenge in the first place.
Not all systems need to migrate at the same pace. Long-lived data and internet-facing systems should be prioritised first because they have the highest exposure to harvest-now-decrypt-later risk. Internal systems with shorter data lifespans can move on a longer horizon.
This phased approach aligns with the methodology outlined in NIST IR 8547 and with Thailand's NCSA PQC roadmap. It also reflects the practical reality that most organisations cannot migrate everything simultaneously. A risk-ranked approach ensures that the systems with the greatest exposure move first, while the broader infrastructure transitions over a manageable timeline.
For banking specifically, the priority order typically follows: treasury and long-lived financial records first, then payment and settlement infrastructure (SWIFT, interbank messaging), then digital banking channels (mobile APIs, internet banking TLS, OAuth flows), and finally core banking systems and compliance infrastructure.
When an organisation scans its cryptographic infrastructure, the resulting data is extraordinarily sensitive. A complete cryptographic inventory is effectively a map of every vulnerability, every weak point, and every migration gap in the organisation's security posture. Where this data is stored, who can access it, and who can be compelled to produce it are not secondary considerations.
The US CLOUD Act (2018) grants US law enforcement the authority to compel any US-headquartered company to produce data stored anywhere in the world. This means a US-based PQC vendor hosting scan data in Singapore, Bangkok, or Kuala Lumpur can still be compelled to hand it over, regardless of local data protection laws including PDPA (Thailand), PDPA (Singapore), or the Vietnam Cybersecurity Law.
Banking sector guidelines should require that cryptographic scan data remains under the bank's own control, in infrastructure the bank provisions and manages. The question is not "where is the data stored?" but "who can be legally compelled to access it?" The strongest answer is an architecture where the vendor never holds the data at all, making the vendor's jurisdiction irrelevant. A contract cannot override a court order, but an architecture that never stores the data makes compulsion a moot point.
PQC migration is not an event. It is a multi-year programme of discovery, planning, implementation, and continuous monitoring. The organisations that start with visibility, build for agility, phase their timelines by risk, and maintain sovereign control over their cryptographic data will navigate this transition from a position of readiness rather than reaction.
Thailand's NCSA has taken the first step with a national PQC roadmap. The TBA is well positioned to operationalise that strategy for the banking sector. We were grateful for the opportunity to contribute to that conversation and look forward to continuing the engagement.
For organisations beginning their PQC readiness journey, the first step is always the same: understand what cryptography you are running today. Everything else follows from there.