← Guide overview

Where cryptography lives in a payments estate

Quantum Readiness for Banking Professionals: all chapters

• 1. What quantum threatens in a bank, and what it doesn't
• 2. Where cryptography lives in a payments estate
• 3. Building a cryptographic inventory
• 4. Deciding what to fix first
• 5. Crypto-agility first
• 6. Vendors and third parties
• 7. Governance and the regulatory map
• 8. A phased roadmap
• Readiness self-assessment
• Glossary

On this page

1. Follow one payment
2. Four layers
3. The eight places cryptography hides
4. Five things that surprise people
5. Why signatures are a business risk, not just a technical one
6. Larkfield's first look
7. Five questions for your next steering committee
8. Sources and further reading

Chapter 1 established that the quantum problem is mostly about RSA and elliptic-curve cryptography. The obvious next question is: where is it? In most banks, the honest answer is "everywhere, and nobody has the full list". This chapter gives programme and governance leads a mental map of where cryptography lives, so you know what to ask for and who to ask.

Follow one payment

The easiest way to see how much cryptography a bank relies on is to follow a single transaction. A Larkfield business customer, a furniture importer, sends $25,000 to a supplier overseas using online banking. Here is the cryptography involved, step by step.

1. The customer logs in. Their browser and Larkfield's servers agree a session key using public-key cryptography, and Larkfield's website certificate proves it's the real bank.
2. The request moves inside the bank. It passes through an API gateway and several internal services. Each hop is its own encrypted connection, often with certificates on both sides so machines can prove their identities to each other.
3. The payment is approved and formatted. Larkfield's payments system turns it into a standard interbank message and authenticates it before release.
4. Keys are used inside hardware. The most sensitive signing and key-protection operations happen inside hardware security modules (HSMs).
5. The message leaves the bank. It travels over a secured network connection to the SWIFT network, where Larkfield's network certificate and signature prove the message really came from Larkfield and hasn't been altered.
6. The receiving bank checks it. On the other side, the supplier's bank verifies Larkfield's signature before acting on the instruction.
7. Records are kept. The payment record is stored and archived, encrypted, for Larkfield's seven-year retention period.
8. Underneath it all, software was trusted. Every system in that chain was installed from software updates digitally signed by its supplier.

That's eight distinct uses of cryptography for one payment, and at least six typically rely on RSA or elliptic-curve cryptography that a quantum computer would break. Larkfield processes millions of transactions like this a year, across dozens of channels.

Four layers

A useful way to organise all this is by layer, because each layer has a different quantum exposure and a different kind of owner.

Authentication and signingCertificates, payment message signatures, card authentication, signed software. Broken by quantum. Forgery becomes possible on the day a capable machine exists.

Key agreement and transportEncrypted connections between customers, systems, partners and payment networks. Broken by quantum. Recorded traffic is exposed already.

Key custodyPrivate keys held in HSMs and key-management systems. Broken by quantum if the keys are RSA or elliptic-curve, whatever the hardware.

Data protection and integrityEncryption of stored data, integrity checks and hashing. Weakened only. Encryption is fine with 256-bit keys; modern hashes are fine, though the right size depends on what each hash is used for.

One subtlety belongs here because it trips up inventories. Stored data is often protected by "envelope encryption": the data is encrypted with a symmetric key, and that key is itself locked with another key. If the outer key is RSA, the whole envelope is quantum-vulnerable, even though the data itself is encrypted with AES-256. When someone tells you "that archive uses AES-256, so it's fine", the follow-up question is: "and how is the AES key protected?"

The eight places cryptography hides

Within those layers, cryptography turns up in eight kinds of place. No single tool finds all of them, which is why inventory needs both scanning tools and people.

Where	What's there	Who usually knows
Source code and configuration	Cryptographic libraries, settings and occasionally hard-coded algorithms	Application development teams
Data in transit	Encrypted connections inside the bank and to the outside world	Network and infrastructure teams
Certificates and PKI	Thousands of certificates and the authorities that issue them	PKI or certificate management team
Key stores and HSMs	Keys by type and purpose	Cryptographic services or key management
Data at rest	Database, file, backup and archive encryption, and how those keys are protected	Data owners and storage teams
Third parties	Cryptography inside vendor products, partner connections and payment networks	Vendor management, relationship owners
Firmware and hardware	Secure boot, device certificates, ATMs, card terminals, network appliances	Infrastructure and device owners
Identity and tokens	Single sign-on, login tokens, API credentials	Identity and access management team

The right-hand column is the important one for a programme lead. Each row is a different team with its own priorities, tools and vocabulary. Inventory is therefore a coordination exercise across at least eight groups, which is why it needs a named owner rather than being left to whoever has spare capacity in security.

Five things that surprise people

Internal connections outnumber external ones. Modern banking systems are built from many services talking to each other, and each conversation is typically encrypted with certificates on both sides. These machine-to-machine links are often the least documented. Teams usually discover them the hard way, when an expired certificate takes a service down.

Test environments count. Development and test systems use real cryptography, often with weaker settings and less oversight. They are part of the estate and belong in the inventory.

Certificate chains move as a whole. A certificate is trusted because a chain of authorities vouches for it, from a root down to the individual system. If any link in that chain still uses a quantum-vulnerable algorithm, the whole chain can be forged at that point. Upgrading individual certificates without upgrading the authorities above them achieves little.

Much of it isn't yours. The cryptography inside a core banking platform, a card processor, a cloud service or a payment network is controlled by someone else. You can't change it, but you must still record the dependency and track the supplier's plan.

Not everything in the payments stack needs replacing. Some links, such as the local authentication between a messaging interface and the systems feeding it, use symmetric techniques that survive with adequate key lengths. Getting this right matters: over-scoping wastes budget and costs credibility with technical teams.

Why signatures are a business risk, not just a technical one

It's easy to treat broken signatures as an IT matter. In payments they underpin something far more fundamental. When Larkfield signs a payment message, that signature is a key part of the receiving bank's confidence that the instruction is genuine. Together with careful key custody, identity checks and record-keeping, it also makes the message hard to repudiate later. If an attacker could forge Larkfield's signature, they could inject instructions that look authentic, and the certainty that a message came from Larkfield would no longer hold.

That's why signature migration, although it isn't the most urgent item, has to be planned years ahead. It also explains why payment networks move their certificate infrastructure as a community, on their own timetable. An individual bank can't move faster than the network and its counterparties.

Larkfield's first look

Larkfield's architecture team spent two weeks on a quick first pass, using its certificate management tool and a network scan. The illustrative results were typical:

• about 9,000 certificates, a third with no recorded owner;
• around 600 externally reachable encrypted endpoints, plus an unknown number of internal ones;
• four HSM clusters, with no record of whether their firmware supports the new algorithms;
• more than 60 suppliers whose products clearly use cryptography, none yet asked about quantum readiness.

Nobody at Larkfield was alarmed by those numbers. Most banks would find something similar. The real finding was that nobody owned the picture. Chapter 3 is about turning a first look like this into an inventory the bank can actually plan from.

Five questions for your next steering committee

1. Which of the eight surfaces do we have any visibility of today, and which are blind spots?
2. How many certificates do we have, and what share have a named owner?
3. Where we use envelope encryption, how are the outer keys protected?
4. Do our HSMs support the new NIST algorithms, and if not, what's the supplier's plan?
5. Which payment networks and critical suppliers control cryptography we depend on?

Sources and further reading

Larkfield Bank is fictional and its figures are illustrative. Everything else is drawn from the public sources below. Tags show what kind of source each one is. A standard or government guidance is an official document; a peer-reviewed paper has been checked by other experts; a preprint has not been peer-reviewed yet; an experiment reports a real-world demonstration; a company announcement is the company's own account. Checked on 11 October 2026. Spotted an error? Email hello@plainquantum.com.

1. Government guidanceQuantum-Readiness: Migration to Post-Quantum CryptographyCISA, NSA and NIST, 2023
2. StandardNIST releases first 3 finalized post-quantum encryption standardsNIST, 2024
3. Government guidanceNIST IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography StandardsNIST, 2024
4. ExperimentProject LeapBIS Innovation Hub
5. StandardCryptography Bill of Materials (CBOM)CycloneDX / OWASP