Counting the Trust Anchors in a Single Cross-Border Payment

A Dutch importer instructs a €250,000 payment to a manufacturer in Singapore on a Tuesday morning. Draw the transaction and you get seven arrows or so: customer app to bank front end, front end to core, core to payments hub, hub to the SWIFT gateway, gateway to a correspondent, correspondent to the beneficiary bank, and a settlement leg through a central bank system. Every arrow gets a label, and the label is almost always the word “encrypted”.

That diagram is a good teaching aid. As the schema for a cryptographic bill of materials, the artefact your regulator and your migration programme both want, it fails in a way we can predict in advance. The first arrow on its own contains four distinct cryptographic objects, owned by three different teams, renewed on three different calendars, with three different answers to the question of what a quantum-capable adversary could do to them. The diagram compresses all four into one word.

So we are going to walk the same payment, sorted differently. Rather than following the money through the network, we sort every cryptographic object it touches into five classes. The class is what predicts the three things an inventory has to answer: who can change the object, how long it has to remain valid, and what fails first when RSA and elliptic curve cryptography stop being safe assumptions.

The deadlines behind the exercise are regulatory rather than speculative. PCI DSS v4.0 requirement 12.3.3 asks for the cipher suites and protocols in use to be documented and reviewed at least once every twelve months. It was future-dated on publication and became a full requirement on 31 March 2025. NIST’s draft IR 8547, Transition to Post-Quantum Cryptography Standards, proposes 2030 as the year RSA-2048 and 256-bit elliptic curve cryptography become deprecated for federal systems and 2035 as the year they are disallowed. Vendor roadmaps and supervisory expectations follow those dates with a lag. An inventory built on the wrong schema will pass its first audit and fail its first migration.

Why the Hop Diagram Fails as an Inventory Schema

Take the first arrow and open it. The customer authorises the transfer in a mobile app, and four cryptographic objects do work in that single interaction.

The server certificate and its private key. Platform engineering owns it, a public certificate authority issues it, and its lifetime is set by nobody in the bank. Under the CA/Browser Forum baseline requirements, publicly trusted TLS server certificates are currently capped at 398 days, and the pressure to shorten that comes from individual browser and root programs rather than from the forum. The direction of travel converts renewal from a diary entry into a pipeline that has to work unattended. The inventory row here is the private key, its algorithm, its physical residence, and the automation that rotates it.

The ephemeral key agreement. There is no stored key to record. What you record instead is a configuration: which key exchange groups the server offers, and in what order. This row determines harvest-now-decrypt-later exposure, the pattern where an adversary records ciphertext today and decrypts it years later once the key agreement can be broken. It is also the only one of the four rows that changes when you switch on a post-quantum key exchange.

The pinned public key inside the app binary. Mobile engineering owns this one. Its lifetime equals the app release cadence plus the long tail of customers who don’t update. Pinning failures don’t raise a security alert; they raise a support queue.

The transaction-signing seed. Identity and access management owns it, it is usually an HMAC-SHA-256 secret behind a one-time code, and it sits inside a hardware security module (HSM), a tamper-resistant device that performs key operations without ever releasing the key, or inside a vendor’s equivalent service. Being symmetric, its quantum exposure is limited to the square-root speedup from Grover’s algorithm, which a 256-bit secret absorbs comfortably.

Four objects, three owners, three renewal calendars, one arrow.

The same compression happens everywhere else on the diagram. The arrow from the bank to its SWIFT gateway holds at least the subscriber signing key in an HSM, the subscriber authentication key, the session protection between the gateway and SWIFT’s infrastructure, the smartcards or tokens that operators use to release messages, and the code-signing certificate SWIFT applies to its own software distributions. Five objects, five failure modes, and only two of them are inside your change control.

This is the pattern we see most often in inventory workshops. Teams inherit the architecture diagram, treat each arrow as a row, and produce a document with the right number of lines and the wrong unit of analysis. The fix is a different sort order: object first, owner second, hop last.

Five Classes of Cryptographic Object

The classes below are not a taxonomy for its own sake. They group objects that answer the same three questions the same way, which means a decision you make about one member of a class usually generalises to the rest.

Sort by what you can change unilaterally, by how long the object has to stay trustworthy, and by what a cryptographically relevant quantum computer would let an attacker do to it. Those three properties cluster, and they cluster into five groups.

Ephemeral Session Keys

Every arrow on the diagram runs over one of these. Customer TLS, mutual TLS inside the service mesh where both ends present certificates, the tunnel from the SWIFT gateway, the IPsec connection to a domestic clearing system, the TLS on the message queue between the payments hub and the core, the encrypted link to the central bank’s real-time gross settlement platform. T2, which replaced TARGET2 across the Eurosystem in March 2023, is reached over the same kind of protected session as everything else on the list.

None of these keys survives the conversation. There’s nothing to rotate, nothing to escrow, and no ceremony. What goes in the inventory is the negotiated algorithm set and the recordability of the traffic.

This class carries the whole of your harvest-now-decrypt-later exposure and almost none of your authentication exposure. It is also the easiest class to migrate, because both ends of most of these sessions are inside your own estate and hybrid key agreement is already shipping. ML-KEM (CRYSTALS-Kyber), standardised as FIPS 203 in August 2024, is deployed in production TLS today in hybrid combination with X25519, and the combination fails only if both halves fail.

A worked note on scale. A bank running a mesh of four hundred services does not have four hundred inventory rows here. It has one policy row plus an exceptions list, and the exceptions are what matter: the message queue manager on an operating system the vendor stopped patching, the network appliance whose cipher suites are fixed in firmware, the file transfer host that a correspondent’s batch process still reaches over an older protocol. Build the exceptions list first. It is shorter than the estate and it is the actual work.

Long-Lived Identity Certificates

These are the objects that name you. Server certificates, client certificates for partner APIs, workload identities in the mesh, the eIDAS website-authentication and seal certificates that European open banking requires of third-party providers, participant certificates issued by a central bank, and the SWIFT subscriber certificates bound to your Business Identifier Code (BIC), the code that names your institution on the network.

Two properties separate this class from the previous one. First, the private key persists, so its residence is an inventory field and not a footnote. Second, the renewal calendar belongs to the issuer. SWIFT renews on SWIFT’s schedule. A central bank renews on its own. Your migration timeline for this class is somebody else’s roadmap, and the useful work is engagement rather than engineering.

The error we correct most often is recording the certificate and not the key. A scanner reports two endpoints with structurally identical certificates. One of those private keys was generated inside a validated HSM and has never existed outside it. The other was generated by a script in 2019 and sits in a file named server.key with permissions nobody has reviewed since. Same row in the scan output, entirely different risk, entirely different migration path. SWIFT’s own certificate policy has long required subscriber private keys to be generated and held in validated hardware, which is exactly why the SWIFT rows in a good inventory look different from the general TLS rows.

One field in this class is about to go stale on its own. Plenty of inventories record HSM assurance as “FIPS 140-2 Level 3”. FIPS 140-2 validations are scheduled to move to the CMVP historical list during 2026, and the successor is FIPS 140-3. The value in the field isn’t wrong today, but it stops being a current statement shortly, and any control that reads that field will need re-pointing.

Quantum exposure here is forgery rather than decryption. Nobody retroactively breaks an identity certificate that expired in 2027. The risk is an attacker who can derive a private key from a public one and then present themselves as your BIC, which is a Q-Day problem and not a recording problem.

Symmetric Key Hierarchies at Rest

Transparent data encryption (TDE), or whole-database encryption applied at the storage layer, on the core banking platform. Column and field encryption on account identifiers and personal data. The tokenisation vault that replaces card numbers with surrogate values. Backup and archive keys. The card key hierarchy behind PIN verification, which is the last place three-key Triple DES survives in most banks, and which NIST disallowed for new encryption after 2023 under SP 800-131A Rev. 2.

The inventory unit in this class is the hierarchy, not the key. A row that reads “AES-256, TDE, core banking” is a summary of something three layers deep, and the depth is where the interesting facts hide.

Envelope encryption is the mechanism worth walking through, because most learners meet it as a diagram and then fail to recognise it in a real estate. The data is encrypted under a data encryption key, or DEK. The DEK is itself encrypted, or wrapped, under a key encryption key, or KEK. The KEK stays inside the HSM or the cloud key management service and never appears in the clear, while the wrapped DEK is stored next to the data it protects.

The data is AES-256 and Grover’s algorithm doesn’t threaten it. But the wrap is frequently RSA, particularly where a cloud key management service is doing the wrapping. So a row that looks entirely symmetric, and therefore entirely quantum-safe, has an asymmetric operation underneath it that an attacker with a recorded wrapped DEK could eventually undo. Whether that recording is realistic depends on where the wrapped key is stored and who can read it, and answering that question is the point of writing the hierarchy down rather than the summary.

Signing Keys With Legal Weight

This is the class that inventories miss most often, and it is the class where migration takes longest.

The members: the SWIFT message signing key that binds an outbound instruction to your institution, the authorisation records behind SWIFT’s Relationship Management Application (RMA), the bilateral permission list that decides which counterparties may send you which message types, the detached signatures required on open banking payment initiation requests, the key your authorisation server uses to sign access tokens, the hashes chaining your audit log, the maker-checker approval records that tie a named employee to a released payment, and the settlement confirmations you receive back from a central bank.

What unites them is a verification that happens later. A session key protects a conversation for a few hundred milliseconds. A signature over a payment instruction may need to verify in a dispute, an investigation, or a supervisory review years after the money moved. When a bank’s records retention policy says seven years, the signing keys behind those records have a seven-year trust requirement attached to them, whatever their own rotation schedule says.

A worked example that catches people out. The token signing key on the authorisation server issues tokens with a fifteen-minute lifetime, so the team classifies it as short-lived and leaves it out of the long-term plan. Meanwhile the key itself rotates quarterly, the tokens are written into the audit log, and a fraud investigation two years later depends on being able to confirm that a particular token was genuinely issued by that server. Three different lifetimes on one row: the token, the key, and the evidentiary requirement. Only the third one drives migration urgency.

The second property of this class is that you can’t move unilaterally. Turning on hybrid key agreement needs your endpoint configuration. Turning on ML-DSA (CRYSTALS-Dilithium), standardised as FIPS 204, for message signing needs a counterparty who can verify it, a message format with room for a larger signature, and usually a scheme rulebook that permits the algorithm. ISO 20022 migration changes the message format across cross-border payments without changing this dependency at all. The bottleneck is coordination, and coordination has a lead time you cannot compress by staffing it harder.

Note also what does not apply here. Harvest-now-decrypt-later is irrelevant to signatures. Recording a signed MT103 today gives an attacker nothing in 2035, because the signature was already verified and the instruction already settled. The exposure is prospective forgery, and the mitigation is to have moved before the capability exists rather than to have moved before the traffic was recorded.

Code and Firmware Signatures

The last class is the one you do not own.

Vendor signatures on SWIFT interface software updates. HSM firmware signed by the manufacturer, which the device verifies before it will load. Operating system package signatures. Container image signatures. UEFI secure boot chains. The hash allow-list that prevents unapproved executables running in the segregated SWIFT zone. Your own internal code signing certificate, which is the one exception, sits alongside them.

Your inventory entry for most of this class is a dependency and a supplier question, not a key. You can’t rotate a hardware root of trust. In practice you replace it by replacing the hardware, which means this class has the longest lead time in the entire payment stack and the least ability to be accelerated by your own effort.

Two things follow. Start the supplier conversation early, well ahead of the point where you need an answer, and ask for a dated roadmap rather than a statement of intent. And expect hash-based signatures to appear here first. SLH-DSA, standardised as FIPS 205, is conservative and stateless, and the stateful hash-based schemes LMS and XMSS were approved for firmware signing under NIST SP 800-208 several years before the main post-quantum standards landed. Firmware is where the industry has been comfortable with hash-based signatures the longest, which makes it the class most likely to move without anyone in your payments team noticing.

The Three Ownership Gaps

Sorting by class exposes a second problem that the hop diagram also hid. Some of these objects have no owner inside your organisation, and they fall into three groups.

Keys held on your behalf. A managed SWIFT service, a cloud key management service, a payments hub delivered as software as a service, an outsourced tokenisation vault. The key exists, it protects your transactions, and the row in your inventory is answered by reading a contract rather than running a scan. The field you need is not the algorithm; it is the notice period you get before the provider changes it.

Keys inside a boundary you can see but cannot touch. Your correspondent’s signing key is the clearest case. Your MT103 is signed on its way out, verified on the way in, and at no point do you handle the counterparty’s private key or set its renewal date. You are trusting the network’s verification and the counterparty’s controls. That is a reasonable thing to trust, and it should still appear in the inventory as an assumption with a named dependency rather than as a blank space.

Keys nobody has claimed. Every mature estate has them. An appliance still using the default certificate it shipped with. An observability agent that negotiated its own tunnel. An SFTP host key generated by a contractor in 2011 for a file feed that three downstream reports still depend on. These are the rows that no scan surfaces cleanly, because the tools inventory what they were pointed at.

The discovery technique we teach for the third group is a reconciliation rather than a scan. Take three lists that already exist and were built for other reasons: the certificate management system’s records, the HSM partition allocations, and the firewall rules permitting outbound sessions. Anything that terminates an encrypted session and appears in none of the three is a candidate. It is a crude method and it finds things, which is more than can be said for waiting on a complete asset register.

Some of you will already have all five classes represented in your inventory, and if so the next question is the one that determines whether the document survives contact with a migration plan: who renews each row, and on whose calendar?

What the Schema Changes About Sequencing

The five classes produce a migration order almost by themselves, because they differ in exactly the properties that determine sequencing.

1. Ephemeral session keys go first. You can change them unilaterally, hybrid options exist today, a mistake is recoverable in a configuration rollback, and this is the only class where delay increases exposure to traffic that has already been recorded.

1. Symmetric hierarchies are mostly an audit, not a replacement. AES-256 stays. The work is tracing each wrapping chain to its base and finding the asymmetric wrap underneath, plus retiring the Triple DES that survives in card key hierarchies.

1. Identity certificates move at the issuer’s pace. Your contribution is inventory accuracy and early engagement, so that when SWIFT or your central bank publishes a date you already know how many of your rows are affected and which of them have private keys sitting in files.

1. Signing keys with legal weight need counterparties. Longest coordination time, shortest list of things you can do alone. Start by identifying which signatures have a multi-year verification requirement, because those are the ones where the deadline is earlier than it looks.

1. Code and firmware finish last but start first. The engineering finishes when the hardware refresh cycle allows. The supplier conversation should be open years before that.

One observation about the market. Most product claims about crypto-agility currently describe the first class, which was already the most agile part of the stack. Agility in classes four and five is the harder property, it is rarely demonstrated in a datasheet, and it is worth asking a supplier to describe in terms of a specific past algorithm change they actually shipped.

Building the Skill

The transferable part of this exercise is not the list. It is the schema, and it survives across payment types, across institutions, and across the next round of standards.

Run it on something small before you run it on the payment estate. Take one customer-facing service, open every arrow into its constituent objects, assign each object a class and an owner and a renewal calendar, and count how many rows you end up with against how many arrows you started with. The ratio is usually somewhere between three and five to one. That ratio is the size of the gap between an architecture diagram and a cryptographic bill of materials, and knowing it changes how you scope the full exercise.

Quantum Academy’s programs teach cryptographic inventory as an object-and-owner discipline, with worked payment and messaging estates rather than abstract examples, and with the migration sequencing that falls out of a well-structured inventory. You can review the current program catalogue at quantumacademy.com/.

Two companion resources are worth having open alongside the work. The Post-Quantum Cryptography Framework covers migration methodology and programme governance once the inventory exists. And for the layer-by-layer walk of this same payment, tracing the instruction through each hop rather than sorting its contents, see The Cryptography Inside an Interbank Payment on PostQuantum.com.