Post-Quantum Cryptography for Financial Firms

No quantum computer can break your encryption today. Your RSA and elliptic curve keys are safe this morning, and they will be safe next year.

So why are we writing to you about post-quantum cryptography now? Because the data you send today can be copied today and decrypted later. If your client records, deal files, and research stay sensitive for a decade, then the clock that matters started some time ago.

This is a planning problem rather than an emergency, and the firms who treat it as planning will spend far less than the ones who leave it. Here is what to weigh up, and what to start.

Why harvest-now-decrypt-later makes this urgent

Adversaries with patience and storage are already intercepting encrypted traffic and keeping it. They cannot read it yet. They expect to.

Look at your own data and ask how long each type stays sensitive:

• Client personal data stays sensitive for the life of the relationship and beyond. GDPR does not expire.
• Trading strategies and proprietary research hold commercial value for five to ten years.
• M&A communications and deal files stay sensitive long after completion.
• Regulatory correspondence can matter indefinitely.

Now overlay the timeline. If a cryptographically relevant quantum computer arrives in ten to fifteen years — within the range of credible expert estimates — then anything captured today with a longer sensitivity window is already exposed. You just will not know about it for a while.

The National Cyber Security Centre has published migration guidance for exactly this reason, and asks organisations to complete the transition by 2035. Read that as a deadline with three parliaments in it, not a distant curiosity.

The three NIST post-quantum standards

Post-quantum cryptography means algorithms that hold up against both classical and quantum attack. In August 2024 the US National Institute of Standards and Technology published its first three:

• ML-KEM (FIPS 203) — from CRYSTALS-Kyber, for key encapsulation, which is how encrypted connections get established
• ML-DSA (FIPS 204) — from CRYSTALS-Dilithium, for digital signatures
• SLH-DSA (FIPS 205) — from SPHINCS+, a hash-based signature scheme

A fourth standard based on FALCON is expected to follow.

They are designed as drop-in replacements. In practice, dropping them in means testing and validating across every system you own, which is why you start early rather than fast.

A post-quantum cryptography migration in six moves

These are the considerations we work through with a financial services firm before moving to post-quantum cryptography. Take them as best practices for adopting PQC in a running business, in the order that costs you least.

1. Find every place you use cryptography

You cannot migrate what you cannot see. Catalogue where cryptography does work for you:

• Data in transit — TLS for web, email, APIs, VPN tunnels, and service-to-service traffic
• Data at rest — disk, database, backup, and archive encryption
• Authentication — certificates, code signing, secure boot
• Third parties — the cryptographic dependencies in your links to prime brokers, fund administrators, market data providers, and cloud platforms

The inventory tells you the size of the job, and it usually finds two or three systems nobody had on the list.

2. Rank your data by how long it stays sensitive

Not everything needs the same urgency. Sort it:

• High — sensitive for 10+ years: client PII, proprietary strategies, regulatory records
• Medium — three to ten years: financial reports, internal communications, operational data
• Low — short windows: published information, marketing material

This is what turns an overwhelming migration into a sequenced one.

3. Ask your vendors for their PQC roadmap

Most of the heavy work will be done for you, by Microsoft, your VPN vendor, your backup provider, and your trading platform. Your job is to know when. Ask each of them:

• What is your post-quantum migration roadmap?
• Which products support PQC algorithms today?
• When will it reach the versions we run?
• What will we have to change on our side?

The ecosystem is already moving. Chrome has supported hybrid post-quantum key exchange since version 124. Signal has protected messaging with PQC since late 2023. Microsoft has begun building PQC support into Windows and Azure. Vendor timelines still vary widely, which is exactly why you ask rather than assume.

4. Build in the ability to swap algorithms later

Crypto-agility means changing cryptographic algorithms without rebuilding everything around them. In practice:

• Keep cryptographic parameters out of your application code
• Use libraries and frameworks that negotiate algorithms rather than fixing them
• Run certificate management that can handle PQC certificate formats
• Test hybrid configurations that use classical and PQC algorithms together

This is worth doing whatever quantum computing does next. It also protects you if a weakness turns up in a classical algorithm, and it gives you clean ISO 27001 evidence for your cryptographic controls.

5. Track what your regulator expects on quantum risk

Financial regulators are folding quantum risk into their existing frameworks:

• The NCSC wants migration planning under way now, finished by 2035
• The ECB has named quantum computing as a risk to the financial system’s cryptographic foundations
• DORA requires you to stay aware of emerging ICT risks, and quantum sits inside that
• The FCA expects quantum risk to feature in operational resilience planning

Expectations will tighten as the standards mature and vendor support broadens. Being able to show a plan is most of the answer.

6. Protect your most sensitive data today

For the data most likely to be harvested now and read later, act before the migration:

• Use the strongest encryption available today, AES-256 for symmetric
• Turn on hybrid TLS where your platforms support it
• Delete what you do not need to keep, so there is less to harvest
• Review network security, so interception is harder in the first place

A realistic post-quantum migration timeline

For a typical London financial services firm, a sensible sequence looks like this:

2025-2026 — Complete your cryptographic inventory. Classify data by sensitivity. Start vendor conversations. Apply crypto-agility principles to anything you build new.

2027-2028 — Test PQC-enabled products and configurations outside production. Add PQC readiness to your procurement requirements.

2029-2032 — Move production systems to hybrid classical-plus-PQC configurations as vendor support matures.

2033-2035 — Finish the move to PQC for your highest-risk systems and retire the quantum-vulnerable algorithms.

That aligns with NCSC guidance and allows for the reality that interoperability testing always takes longer than the plan says.

Start your migration to post-quantum cryptography

We help London financial services firms work through the post-quantum transition at a pace that matches their risk: the cryptographic inventory, the vendor conversations, and the crypto-agile architecture that makes the eventual switch routine. It is practical cybersecurity work, not a research project.

If you want to know where your firm stands on quantum readiness, book a free IT assessment with Nerdster. You will come away with a clear picture of your position and a roadmap you can actually follow.