Quantum-safe readiness for banks and insurers in India and the Gulf

Summary

Banks and insurers hold data that must stay confidential for years: account records, identity documents, transaction history, policy and claims files. A sufficiently large quantum computer would break the public-key cryptography protecting much of that data in transit and at rest. Because traffic can be recorded today and decrypted later, the risk starts before such a computer exists.

NIST published the first post-quantum standards in August 2024 (FIPS 203, 204 and 205) and has proposed, in draft NIST IR 8547, to deprecate today's quantum-vulnerable algorithms after 2030 and disallow them after 2035. Regulators in India and the Gulf are issuing their own guidance. This paper sets out a practical sequence for the next three years.

1. Build the inventory

List every place cryptography is used: certificates, keys, libraries, protocols, HSMs, VPNs, code signing, and vendor products. Record it as a cryptographic bill of materials that auditors can query. Expect this to take longer than planned; most of the effort is finding owners.

2. Rank risk by data lifetime

For each system, combine three factors: how long its data must stay confidential, how exposed it is (internet-facing, partner links, internal only) and how hard it will be to change (in-house code, vendor product, embedded firmware). Systems with long-lived data and high exposure move first, even if they are hard.

For a bank, that usually means customer identity and onboarding records, card and payment interfaces, open-banking APIs and inter-bank links. For an insurer, policyholder and health data with long retention periods.

3. Make the estate crypto-agile

Before swapping algorithms, make them swappable. Centralise key and certificate management, wrap cryptographic libraries behind interfaces, and make algorithm choice a configuration setting. This work pays off twice: post-quantum algorithms are new, and some parameter choices will change again.

4. Test, then migrate by system group

Introduce ML-KEM and ML-DSA first in hybrid mode alongside current algorithms, in a test environment. Measure handshake latency, message size, HSM support and compatibility with partners. Then migrate system group by system group in the order set in step 2.

5. Govern it like a programme

Name an owner, track coverage of the inventory and the share of high-risk systems migrated, and report to the board on a fixed rhythm against the dates that apply to you. Put post-quantum requirements into vendor contracts and procurement now, so new systems do not add to the backlog.

A realistic three-year shape

How Constient helps

We run the inventory, the risk ranking and the migration engineering, and our quantum research team keeps the hardware timeline realistic. See quantum-safe services or write to consult@constient.com for the full paper in PDF.