← All articles

The certificate plumbing behind payment networks

On this page

1. What a certificate chain is
2. Payment networks run their own trust
3. Why certificates make migration slow
4. Cards: certificates in your wallet
5. What a bank can do now
6. Sources and further reading

Many signed payment messages, secure connections to payment networks and chip-card checks depend on certificates: digital documents that vouch for a public key. Not every trust relationship works this way; some rely on keys that are agreed and loaded in advance. But where certificates are used, they form chains of trust that payment networks and card schemes manage for their members, and post-quantum migration has to replace them, typically with ML-DSA or another post-quantum signature. The way those chains are built shapes the order, pace and difficulty of the work. This piece explains the plumbing in plain English.

What a certificate chain is

A certificate binds a public key to an identity, such as a bank or a server, and is signed by a certificate authority that vouches for it. That authority's own certificate is usually signed by a higher one, up to a trust anchor, often called a root, that each system has been configured to trust. When a bank's system checks a signature, it builds a path from the sender's certificate back to one of its configured trust anchors and checks each certificate along the way.

Root authorityThe trust anchor systems are configured to accept. Long-lived, rarely changed, and the hardest to replace.

Intermediate authoritiesIssue certificates on the root's behalf, so the root key can stay offline.

End-entity certificatesBelong to individual banks, servers, applications or cards. Numerous and shorter-lived.

Payment networks run their own trust

The public web relies on certificate authorities that browsers trust. Payment ecosystems may use public, private or mixed certificate infrastructures. What matters for migration is who defines the trust policy: which authorities are accepted, which algorithms are allowed, and when that changes. For many messaging networks, high-value payment systems and card schemes, that's the operator, and members can't change those choices on their own.

That has two consequences for post-quantum migration. One operator can coordinate a change across all members, which is an advantage the open internet doesn't have. But members also move on the operator's timetable, so a bank's readiness for signed payment messages depends on its network's plan as much as its own.

Why certificates make migration slow

• Dependencies set the order. An authority needs post-quantum keys before it can sign post-quantum certificates, and verifiers need the new trust anchors before they'll accept them. Operators manage this in different ways: running new chains alongside old ones, deploying new trust anchors in stages, cross-certifying between old and new authorities, or overlapping chains during a transition.
• Everything that checks must understand the new algorithm. A new certificate is useless until every system that verifies it, across all members, has been updated to accept it.
• Roots live a long time. They're deliberately long-lived and widely embedded, sometimes in hardware that's hard to update, so replacing one is a major, coordinated event.
• Size adds up. Each certificate carries a public key and a signature, and post-quantum versions of both are much larger. How much that matters depends on the encoding, the extensions included and how many certificates are sent in a chain, and it shows up in messages, constrained devices and storage.
• The transition needs both at once. For a period, systems may need to accept both old and new chains, or certificates that combine both kinds of algorithm. Any combined approach should be assessed against the standards and network rules that apply to it.

Cards: certificates in your wallet

Some EMV chip-card authentication flows use certificates too. A card can prove it's genuine to a terminal using keys and certificates that chain up to its card scheme, whose public keys are loaded into terminals. Several things make that hard to change quickly: chips have limited memory and processing power, cards stay in wallets for years, terminals and ATMs are replaced on long cycles, and certification of new cards and terminals takes time. Moving card authentication to post-quantum signatures depends on card schemes, card manufacturers and terminal makers moving together, and on testing whether larger keys and signatures fit within the chip's limits.

For certificates, a bank's job is less "replace them" and more "be ready the day the network moves": know what you hold, automate renewal, and test the new chains early.

What a bank can do now

1. Inventory certificates and trust relationships, ideally as part of a cryptographic bill of materials like my illustrative payment-flow inventory, including those controlled by networks, vendors and card schemes: which trust anchor each depends on, who operates it, what it's used for and when it expires.
2. Automate certificate issuance and renewal where you control it, so thousands of replacements are routine rather than heroic.
3. Ask each network and card scheme for its post-quantum plans, and record them as dependencies with owners and review dates.
4. Check that internal certificate authorities, hardware security modules and verification software can support the new algorithms.
5. Test longer chains and larger signatures in message flows and devices before the network requires them.

The banking guide's chapter on vendors and payment networks covers how to track those dependencies, and what post-quantum changes in payment messages covers the signatures that certificates support.

Sources and further reading

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. Dates and figures were checked against these sources on 12 October 2026. Spotted an error? Email hello@plainquantum.com and it will be corrected, with a note.

1. ExperimentProject Leap phase 2: quantum-proofing payment systemsBIS Innovation Hub, 2025
2. StandardFIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)NIST, 2024
3. Government guidanceNIST IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography StandardsNIST, 2024
4. Government guidanceG7 Cyber Expert Group: coordinated roadmap for the transition to post-quantum cryptography in the financial sectorG7 Cyber Expert Group (via US Treasury), 2026
5. StandardPost-Quantum Cryptography project (status of FN-DSA and other work)NIST Computer Security Resource Center
6. ReferencePost-quantum cryptographic inventory of a wire-payment flow (illustrative CBOM)Muhammad Atif, 2026