Post-quantum readiness for financial systems: a NIST roadmap

Many boards believe post-quantum cryptography (PQC) can wait until large quantum computers are in commercial use. For financial institutions, telecom providers and operators of national infrastructure, the risk has already begun.

Why it is a problem today

Attackers are already collecting encrypted data to read later. This is known as “harvest now, decrypt later”. They intercept and store encrypted TLS traffic, interbank settlement streams and database backups today, certain that RSA-2048 and elliptic-curve cryptography (ECC) will be broken while that data still matters.

If you hold state secrets, long-term loans or permanent identity records, data that must stay confidential for 10 to 25 years is exposed the moment it leaves your network under today’s ciphers.

NIST has now published its final post-quantum standards, including FIPS 203 (ML-KEM) for encryption and FIPS 204 (ML-DSA) for digital signatures. Regulators and central banks are moving from advice to required migration timelines.

The hidden problem: cryptography built into old systems

Moving to post-quantum standards is rarely as simple as updating an OpenSSL library. When our principal engineers review established enterprise systems, three obstacles come up again and again:

• Hidden cryptography. Old ERP integrations, mainframe bridges and hardware security modules (HSMs) often use fixed cipher suites, pinned certificates or outdated key exchanges, buried deep in middleware nobody maintains.

• Bigger keys, heavier handshakes. Post-quantum keys and signatures, such as ML-KEM and ML-DSA, are much larger than RSA and ECDSA ones. On busy payment gateways or constrained OT and IoT networks, larger handshakes can split packets, overflow buffers and set off chains of timeouts.

• Partners that are not ready. Your own systems may support hybrid key exchange. But if your clearing house, card acquirer or tax gateway still requires old TLS settings, connections fail unless a proxy layer manages the difference.

A four-step roadmap to crypto-agility

At XSIS, backed by KONG GROUP’s heritage in cryptographic engineering, we take enterprises through the move to post-quantum cryptography without risking production uptime.

1. Map every key and certificate

You cannot migrate what you have not mapped. We combine passive network monitoring, code analysis and certificate discovery across your repositories, APIs and infrastructure. The result is a Cryptographic Bill of Materials (CBOM): every certificate, key length, cipher suite and cryptographic dependency.

2. Rank systems by risk

Not everything needs to move at once. We rank systems by how long their data must stay secret and how exposed they are. External host-to-host bank connections, national identity stores and links between data centres come before short-lived internal telemetry.

3. Add hybrid key exchange

Instead of a risky switch on a single date, we deploy hybrid modes that combine classic ECDHE with post-quantum ML-KEM at the ingress controller, the API gateway and the service mesh. Older systems keep working, existing FIPS compliance holds, and traffic is protected against “harvest now, decrypt later” from that day on.

4. Build in crypto-agility

We move encryption and signing in your applications behind shared cryptographic providers and post-quantum-ready HSMs. When algorithms change or new rules arrive, you rotate cipher suites by changing a policy, not by rewriting code.

Where to start

Post-quantum migration starts with knowing what you have. Book a Readiness Review with an XSIS principal cyber architect to scope a non-intrusive inventory of the cryptography in your banking, ERP and cloud systems.