Marin Ivezic
A cryptographic bill of materials, or CBOM, is an inventory of the cryptographic assets a system depends on: the algorithms, keys, certificates, protocols, and libraries, together with the relationships between them. It extends the idea behind a software bill of materials from “which components are in this build” to “which cryptography does this build actually rely on, and where does that cryptography live.” Leading migration guidance treats a cryptographic inventory as the foundation of a migration program: the National Cybersecurity Center of Excellence (NCCoE) at NIST runs a migration project whose practice guides begin with discovery and inventory, and US federal memoranda direct agencies to inventory their cryptographic systems before any replacement work starts. The Payment Card Industry Data Security Standard (PCI DSS) v4.0 now requires payment organizations to maintain an inventory of trusted keys and certificates, which is a narrower version of the same idea with regulatory force behind it.
The first question anyone commissioning a CBOM has to answer is not which tool to buy. It is where the inventory stops.
That question is harder in payments than almost anywhere else, and the reason is that a mobile banking payment is not one system with a cryptographic layer bolted on. It is a chain of institutions, each of which decrypts what it receives, validates it, re-signs it with its own keys, re-encrypts it under the next party’s parameters, and writes an integrity-protected log of having done so. Cryptography is the mechanism by which one institution’s assertion becomes another institution’s obligation, and that is a larger job than moving the payment from one place to another.
So this article does something specific. We walk a single payment from the moment a phone powers on to the moment funds settle, and at each layer we ask three questions that a scoping exercise has to answer anyway: what cryptography is operating here, can we see it, and do we control it. Those last two questions are different, and the difference is where most scoping exercises go wrong.
Three boundaries, not one
Before the walk, a piece of vocabulary this article uses throughout.
An inventory boundary is the line around the cryptographic assets your CBOM will actually enumerate. Drawing it is a decision, not a discovery, and it turns on two independent axes.
The first axis is observability. Can a discovery tool see this cryptography at all? Some of it sits in source code you compile, where static analysis reads it directly. Some sits in a third-party SDK shipped as a hardened binary, where you might infer library usage from imported symbols but cannot read the algorithm selection logic. Some executes inside a secure element or a hardware security module (HSM), where by design nothing outside the tamper boundary can observe the operation.
The second axis is control. Can you change this cryptography? You can change the cipher suite your API gateway negotiates. You cannot change the signature algorithm in Apple’s secure boot chain, and neither can your vendor’s account team.
Cross the two axes and you get three categories that a scoping document should name explicitly:
Owned. Observable and controllable. Your application code, your backend services, your API gateway configuration, your certificate estate, your HSM key hierarchy. This is the CBOM proper, and it is where migration work actually happens.
Attested. Not directly observable, but contractually reachable. Your payment HSM vendor’s firmware roadmap. Your token service provider’s algorithm support. Your correspondent bank’s PKI. You inventory these as dependencies with an owner and a review date, not as algorithm entries.
Assumed. Neither observable nor controllable. Silicon-fused root keys. The secure enclave’s internal implementation. The scheme operator’s internal message security. You record that they exist, note what breaks if they fail, and move on.
Most failed scoping exercises collapse these three into one and then either drown, by trying to enumerate everything, or under-scope, by inventorying only what a source-code scanner happens to find. The walk below sorts each layer into one of the three.
Layer one: the device, before the app exists
The chain starts in silicon, and it starts before any bank software runs.
When a phone powers on, the first code to execute is immutable boot code etched into the processor during manufacture. On Apple silicon that code holds Apple’s root certificate authority public key, and its job is to verify the digital signature on the next boot stage, which verifies the next, and so on to the operating system kernel. The secure enclave, a separate coprocessor with its own processor core, runs its own parallel boot verification. Android does the same thing with different plumbing: root-of-trust keys burned into system-on-chip fuses, verified boot checking boot partitions and system images, and boot state bound to the operating system version and security patch level so a rollback to a vulnerable build can be detected.
Every one of those verifications is a signature check using RSA or elliptic-curve cryptography. Every one of them is quantum-vulnerable in principle. And not one of them belongs in your CBOM as an algorithm entry.
That is not a contradiction. It is the boundary doing its job. You cannot inventory what you cannot observe, and you cannot migrate what you do not control. Apple and Google have not published post-quantum roadmaps for boot-chain signatures, and a bank’s migration program cannot make them. What belongs in the scoping document is a single line in the assumed category: device boot integrity depends on vendor-controlled classical signatures, no visibility, no influence, revisit annually.
The reason to write that line down rather than ignore the layer is that everything above it inherits the assumption. Biometric authentication, hardware-backed key storage, device attestation, transaction signing from a device key: all of them are guarantees conditional on the boot chain having held. If a scoping document never records the dependency, nobody notices when it changes.
Where keys live
One layer up, the picture shifts.
Modern mobile platforms isolate cryptographic key material from the application processor. On Apple devices that isolation is physical: the secure enclave has its own processor core, its own encryption engine with side-channel countermeasures, its own public-key accelerator, and its own hardware random number generator. It holds a unique identifier fused into the silicon that no software, including Apple’s, can read. On Android, the hardware-backed keystore performs the equivalent function, executing operations either inside a trusted execution environment (an isolated execution mode within the main processor, walled off from the operating system) or inside StrongBox, a discrete tamper-resistant chip with its own processor and storage.
For a banking app, this is where the security-critical keys sit: the device binding key that proves device identity to the bank, the transaction signing key that authorizes payments, and biometric-gated keys that cannot be used without a fresh authentication event at the hardware level.
Here the boundary splits mid-layer, which is exactly the sort of thing a scoping exercise needs to catch.
The enclave’s internal implementation is assumed. You will never see inside it, and you should not try.
But the key policy is owned. Your application decides which curve to request, whether the key requires biometric authentication for every use, whether it is invalidated when biometrics are re-enrolled, and whether it is exportable at all. Those are algorithm and configuration entries, they are in your code, and they are the entries that will change during migration. Apple has begun deploying post-quantum cryptography in platform services such as iMessage, though general-purpose post-quantum primitives are not yet exposed through CryptoKit at the time of writing. As platform key APIs gain post-quantum options, the scoping question shifts to what your app asks for rather than what the platform supports.
The practical scoping instruction: inventory the key-generation parameters, not the enclave.
Biometrics and app integrity
Authenticating with a face or a fingerprint looks like a sensor read. It is a cryptographic exchange. The sensor and the enclave communicate over a channel encrypted under a session key derived from a factory-provisioned shared secret unique to that individual sensor-and-enclave pair. The enclave holds the enrolled template, performs the comparison internally, and returns one bit: match or no match. The raw biometric data never leaves the enclave and is never visible to the banking app.
All of that is assumed. Your CBOM records the dependency and nothing more.
App integrity is different, and it is the first layer where you have real work to do. Before a banking app can transact, it has to prove it is genuine rather than a repackaged clone running in an emulator. Attestation is the mechanism: the platform generates a key pair inside the secure enclave, tied to that specific app on that specific device, and issues a signed certificate chain that your backend verifies. Instead of the app presenting a static API key, which any attacker who unpacks the binary can extract, the device proves itself cryptographically each session using a hardware-bound key whose provenance traces back to the platform vendor’s attestation root.
Google has been evolving that attestation infrastructure on Android, deprecating RSA attestation roots in favor of elliptic-curve ones, which is a useful reminder that the attestation chain is not static and its algorithms are not yours.
The scoping split: the attestation root and its certificate chain are attested, because you depend on a vendor’s PKI and you will need to know when its algorithms change. The verification logic in your backend, which parses the chain, checks the roots, and decides what verdicts to accept, is entirely owned. So is your app signing key, which on Android sits under a scheme that supports proof-of-rotation structures, and rotation capability is worth flagging early because it is exactly the property a migration will need.
Layer two: the wire
The app now talks to the bank, and enters a domain where a lot of teams stop the analysis at “we use TLS.”
A TLS 1.3 handshake in a banking session does more than the phrase suggests. The client opens with its supported cipher suites and, in the same message, pre-emptive ephemeral public keys for likely curves. The server replies with its own. From that point everything is encrypted, including the server’s certificate, which travelled in the clear under TLS 1.2. Because both sides generate fresh ephemeral keys per session and discard them afterwards, compromise of a long-term server key cannot decrypt recorded past sessions. Session keys come out of a key-derivation function, and application data flows under an authenticated encryption cipher that provides confidentiality and integrity in one operation.
Certificate validation runs alongside: build a chain from the server’s leaf certificate through intermediates to a root in the device trust store, verify a signature at each link, check expiry and revocation, validate the hostname against the certificate’s subject alternative names.
Most banking apps then add certificate pinning, embedding the expected certificate or public-key hash at build time and rejecting anything that does not match even if it chains to a trusted root. Pinning the public-key hash rather than the whole certificate is the usual choice because it survives certificate renewal as long as the key pair is retained.
Every element of this layer is owned, and it is the densest owned territory in the entire walk. The cipher suites your app offers and your gateway accepts. The curves in the key exchange. The certificate estate itself, with its issuers, key algorithms, key sizes, and expiry dates. The pinned hashes and, critically, the process for rotating them.
Pinning is a genuine security improvement and it is a well-known cause of self-inflicted outages, because an unexpected certificate rotation on the server side bricks every installed app until users update. Any migration that changes certificate key algorithms will collide with pinning directly. If your scoping exercise does not surface the pinning configuration and its update path, the migration will discover it later, under time pressure.
Authorization
Above transport sits the API authorization layer. Mobile banking apps typically use OAuth 2.0’s authorization code flow with proof key for code exchange, which binds the authorization code to a per-session secret so an intercepted code is useless on its own. Access tokens are signed, usually with an RSA or elliptic-curve signature scheme, and sometimes additionally encrypted.
The Financial-grade API 2.0 security profile, finalized in early 2025, tightens this considerably for high-value transactions: pushed authorization requests, tokens cryptographically bound to the client that requested them through either mutual TLS or a proof-of-possession mechanism, and client authentication by private key or client certificate, with shared client secrets explicitly prohibited.
All owned. Token signing keys, their algorithms, their rotation schedule, the client credentials in device secure storage, the mutual TLS certificate estate if you use sender-constrained tokens. This layer also carries a specific migration hazard worth recording at scoping time rather than discovering later: post-quantum signatures are substantially larger than the elliptic-curve signatures typically used in compact tokens today, and token size assumptions are baked into gateway configurations, header limits, and middleware across a lot of estates.
Layer three: authorizing the money
Opening a session is preliminary. Authorizing a payment adds a requirement that transport security does not provide on its own: cryptographic proof tied to this amount, this payee, this moment.
In the European Union, the regulatory technical standards under the EU’s revised Payment Services Directive (PSD2) require that when strong customer authentication applies to a payment, the resulting authentication code must be specific to the amount and the payee the payer agreed to. This is dynamic linking, and it is best read not as a compliance sentence but as a cryptographic design constraint. If approval must be bound to amount and payee, then there has to be a canonical data structure representing the transaction, and a mechanism that commits the user’s authorization to exactly those fields such that altering either one invalidates the code.
In practice that means transaction signing. The bank registers a device-bound public key, usually after verifying the device’s attestation chain. When the user approves a payment, the app builds a canonical payload containing amount, payee identifier, timestamp, nonce, transaction identifier, and risk metadata, and signs it with the private key held in the secure enclave or hardware keystore. The backend verifies the signature against the registered public key before releasing funds.
This is the highest-value cryptographic operation in the whole chain, and it is fully owned. The canonical payload format, the signature algorithm, the key registration protocol, and the verification path are all yours. It is also the operation where migration is hardest to defer, because the signature algorithm appears on both sides at once: in the app running on millions of devices, and in the backend that verifies. Changing it means a coordinated rollout with a period during which both algorithms must be accepted.
A scoping exercise should treat transaction signing as its own line item rather than folding it into a general “signatures” category. The verification code, the key registry, and the canonicalization rules are three distinct assets with three distinct owners in most organizations.
Layer four: the parties beyond your walls
Once the payment leaves your API and enters payment rails, the character of the inventory changes completely. Up to this point every layer has been either yours or the device platform’s. From here, the payment crosses institutional boundaries, and each crossing is a cryptographic demarcation point.
The parties, in a realistic cross-border case:
Your own identity layer, API gateway, and core banking and payments orchestration. Owned, and typically the largest single body of work: mutual TLS between internal services, an internal certificate authority issuing those certificates, message signing, and HSM-backed operations underneath.
The domestic clearing or instant payment operator, if the payment stays in-country. Each scheme has its own participant authentication framework and message signing requirements. Attested: you hold a participant key pair and you follow a scheme specification you did not write.
Cross-border messaging, where a further complete PKI layer applies. Institutions hold key pairs stored in hardware, messages are digitally signed for non-repudiation, and the operator’s security program mandates hardware key storage, dual control for privileged operations, and periodic independent assessment. Your key pair and its storage are owned. The scheme’s PKI and its algorithm roadmap are attested.
Central bank settlement. Real-time gross settlement systems have their own signing keys and message authentication. This is the layer where the Bank for International Settlements ran Project Leap, testing post-quantum signatures in a real payment message flow, and the results are worth carrying forward for the sequencing discussion below.
The beneficiary institution, which verifies signatures, screens, posts, and generates confirmations back through the chain. Almost entirely assumed from your side.
The cryptographic surface multiplies at each institutional hop. Financial messaging does not encrypt once at origin and decrypt once at destination. At every institutional boundary, the message is decrypted, validated, re-signed under the receiving institution’s keys, re-encrypted for the next hop, and logged. Trust is re-established cryptographically at each crossing because no institution accepts another’s assertion transitively. That design is deliberate and it is correct, and it is also why “we will inventory the payment path” is not a scopeable statement.
The scopeable version: inventory the cryptography at every boundary you are on one side of. Your participant keys, your signing and verification implementations, your certificate lifecycle for each scheme, and your contractual mechanism for learning when a counterparty’s algorithms change.
Layer five: card rails, if the payment takes them
Many payments originating in a banking app end up on card rails: in-app purchases, wallet transactions, card-on-file. That path opens a parallel cryptographic world with its own inventory characteristics, and it is worth walking because it is where the assumed category is largest and the legacy dependencies deepest.
When a card is provisioned into a wallet, the network’s token service provider issues a device account number, a surrogate for the real card number, held in a vault the provider controls and restricted to a specific device or channel so it cannot be replayed elsewhere. On Apple devices the token lives in a secure element, a tamper-resistant chip physically separate from the main operating system. Google’s wallet takes a different approach, using host card emulation with limited-use keys derived on the provider’s servers and downloaded to the device with tap-count and time limits.
Per transaction, the device generates a cryptogram. In the EMV contactless case this is an authorization request cryptogram, or ARQC: a message authentication code computed over the transaction data (amount, currency, country, terminal results, a terminal-supplied unpredictable number, a transaction counter) under a session key. The session key derives from a card-specific key, which itself derives from an issuer master key held in the issuer’s HSM. The issuer reverses the derivation, recomputes the code, and compares. A match proves the transaction data was not altered and the card is genuine. The issuer then returns its own cryptogram, which the card validates, so the authentication runs both directions inside a sub-half-second budget.
EMV also supports offline data authentication, where a terminal verifies a card without contacting the issuer, using digital signatures chaining to the scheme’s certificate authority. This is where RSA is most deeply embedded in payments and hardest to move, because the verifying terminals include transit gates, in-flight systems, and connectivity-poor merchants, and they update on hardware-replacement timescales.
For a bank scoping a CBOM, nearly all of this is attested rather than owned. The token vault is the network’s. The scheme certificate authority is the scheme’s. The terminal estate belongs to acquirers and merchants. What you own is your issuer key hierarchy and your authorization system’s validation logic, and that is a substantial and specific inventory item.
The key hierarchy and the HSMs beneath it
Underneath the card layer sit the HSMs: tamper-resistant devices that hold keys and perform cryptographic operations inside a boundary that no software, including yours, can read into. A single card transaction may drive several HSM operations at the issuer: decrypting an encrypted PIN block, translating it between key zones, verifying the PIN, validating the transaction cryptogram, generating and verifying message authentication codes, and producing the response cryptogram.
The key hierarchy governing this runs from a local master key that never leaves the HSM, through key-encrypting keys and zone master keys used to exchange working keys with other institutions, down to the operational keys for PIN encryption, PIN verification, and card authentication. Keys are loaded under dual control and split knowledge: components are entered separately by two or more custodians and combined inside the module, so no individual ever holds a complete key.
Two standards in this layer are worth naming because they shape migration directly.
DUKPT, derived unique key per transaction, gives each transaction its own encryption key derived from a base derivation key through a tree structure, so that compromising one transaction key reveals nothing about its neighbours. The original triple-DES variant supports roughly a million transactions per initial key before the counter space exhausts; the AES variant extends that by orders of magnitude, and moving to it generally means moving PIN block formats as well.
And the messaging standards themselves, where message integrity is provided by symmetric message authentication codes between endpoints, placed in fields whose sizes were specified decades ago. This is the constraint that will bite hardest in migration: legacy message formats have field lengths designed for classical signature sizes, and post-quantum signatures do not fit in them.
Scoping guidance for this layer: the HSM interior is assumed, the vendor firmware roadmap is attested, and the key hierarchy itself, meaning which keys exist, what algorithms they use, which zones they bridge, and who the custodians are, is owned and is often the single most valuable output of the whole exercise. Many institutions discover during a CBOM that no current, complete map of their key hierarchy exists anywhere.
What the walk implies for migration sequencing
Sort the walk by category and the migration program starts to shape itself.
A cryptographically relevant quantum computer, or CRQC, is a machine capable of running Shor’s algorithm at sufficient scale to derive private keys from public ones. Against such a machine, every asymmetric algorithm in the walk fails: the key exchange in TLS, every certificate signature in every chain, code signing, attestation, device-bound transaction signing keys, token signing, the interbank PKI layers, and EMV offline data authentication.
Symmetric cryptography with adequate key lengths survives. AES-256 and the SHA-2 and SHA-3 hash families retain substantial security margin against the best known quantum attacks. The symmetric operations inside HSMs, meaning PIN block encryption, message authentication codes, key derivation, are not the problem.
But the qualifier matters more than the reassurance. Almost every symmetric key in the chain is established or distributed using asymmetric cryptography. A session protected by AES-256 is only as strong as the key exchange that produced the session key. Zone keys exchanged between institutions travel under asymmetric protection. The vulnerability does not stay in the asymmetric operations; it propagates to everything that depends on them for key establishment.
Then there is size and speed. In its second phase, Project Leap tested a lattice-based signature scheme in a real payment message flow and reported verification times materially above the RSA baseline. Post-quantum signature and key sizes are an order of magnitude larger than their classical equivalents. Set that against a contactless transaction budget under half a second and a message format with fixed-length fields, and the sequencing problem becomes concrete: this is not a find-and-replace on algorithm names.
Which produces a defensible ordering, derived from the three categories rather than from a generic checklist.
Owned and rotatable first. Backend TLS between your own services, internal certificate authority, token signing, message signing inside your estate. You control both endpoints, you can measure the latency impact against real traffic, and you can roll back. This is where hybrid key exchange gets piloted.
Owned and coordinated second. Transaction signing and anything else requiring simultaneous change in a deployed mobile app and a backend. Longer lead time because the rollout is gated on app adoption, and it needs a dual-acceptance period designed in from the start.
Attested, tracked continuously. HSM firmware, token service provider support, scheme PKI roadmaps, platform attestation roots. These are procurement and contract conversations rather than engineering ones, and they need starting early because payment HSMs are among the longest-lead-time components in the chain. Some HSM cryptographic accelerators are built for classical arithmetic and cannot be repurposed for lattice-based mathematics by firmware update alone, which turns a software upgrade into a hardware replacement cycle.
Assumed, reviewed annually. Boot chain, secure enclave internals, secure element internals, counterparty internal cryptography. Record the dependency, record what fails if the assumption breaks, and revisit on a schedule.
The G7 Cyber Expert Group has set out a roadmap targeting migration of critical financial systems by the early 2030s and completion by 2035. Whether those dates hold, the sequencing logic above does not depend on them, because the binding constraint for payments is not the arrival of a CRQC. It is data retention. Payment records subject to regulatory retention periods of seven to ten years are being created today, and any of them harvested now can be decrypted later. The deadline for protecting a given record is the date it is created, minus nothing.
What a CBOM does and does not deliver
Two honest limits, because a scoping document that overpromises will fail its first review.
A CBOM will not see inside hardware trust boundaries. Operations inside a secure enclave, a secure element, or an HSM are invisible to external tooling by design, and that is the property you are paying for. Discovery tools also produce incomplete results against obfuscated or hardened third-party binaries, which is most commercial mobile security SDKs. Where a tool cannot reach, vendor documentation is what you have, and vendor documentation is an attestation rather than an observation. Label it as such in the inventory.
Nor should completeness be the goal. No institution will map the cryptographic surface across every party in a cross-border payment, and attempting it burns the budget that should have gone into migrating the assets you actually control. You do not control the platform vendor’s enclave firmware, the network’s token vault, or your correspondent bank’s key hierarchy.
The value of a CBOM is narrower and more useful than a complete map. It makes the owned surface enumerable, so it can be prioritized. It converts the attested surface into a named list of dependencies with owners and review dates, so nobody assumes somebody else is tracking them. And it records the assumed surface explicitly, so the assumptions are visible when they change.
That is also the reason crypto-agility is the right end state rather than a completed migration. NIST frames it as the capability to replace and adapt cryptographic algorithms across protocols, applications, libraries, hardware, and firmware while preserving security and continuing operations. Project Leap’s finding on hybridization, running classical and post-quantum algorithms in parallel through a transition period, was that it requires substantial system change where agility was not designed in originally. Systems that hardcode algorithm choices into application logic, which describes most legacy payment infrastructure, pay that cost every time the algorithms change. Systems that abstract cryptographic operations behind a configurable service layer pay it once.
Where to start on Monday
Five actions, ordered by how much they unblock everything else.
Draw the three-category boundary before buying a tool. Take the walk above, apply it to your own architecture, and produce a one-page classification of owned, attested, and assumed. This is a two-week exercise with an architect and a payments engineer, and it determines what the tooling has to do rather than the other way round.
Inventory the key hierarchy first, not the code. In most institutions this is the highest-value and most neglected artifact: which keys exist, which algorithms and key lengths, which zones they bridge, who the custodians are, when they were last rotated. It is also the input every subsequent workstream needs.
Enumerate certificates and pinning configuration together. The certificate estate is the most tractable part of the owned surface, and the pinning configuration is the part most likely to break during migration. Treating them as one inventory item surfaces the collision early.
Start the HSM vendor conversation now, at the roadmap level rather than the product level. Ask specifically whether your installed modules can support lattice-based operations through firmware, or whether the accelerator hardware forces replacement. That answer sets your longest lead time.
Measure before you commit. Pilot hybrid key exchange on internal service-to-service TLS with your actual traffic patterns, and separately prototype post-quantum transaction signing to see what the signature size does to your token and message paths. Two measured numbers beat a shelf of vendor benchmarks.
None of this requires knowing when a CRQC arrives. It requires knowing which cryptography is yours, and that is a question you can answer this quarter.
Scoping and building a cryptographic inventory is the core skill this walk depends on, and it is what the Certified Post-Quantum Migration Specialist program is built to teach: how to classify a cryptographic estate, where to draw the inventory boundary, and how to turn a CBOM into a sequenced migration plan. For the underlying migration methodology, see the PQC Framework. For deeper technical background on payment cryptography and post-quantum transition, PostQuantum.com carries the long-form analysis.