What substitutability cannot see
An institution runs four hardware security module vendors, three TLS terminators and two certificate providers. Its third-party register shows nine suppliers behind one payment service, exit plans on file for each, substitutes identified. Under the tests financial regulation currently applies, that estate is diversified, and the assessment moves on.
The Cryptographic Concentration Framework exists because the assessment should not move on. Resolve each of those nine suppliers to the cryptographic components executing underneath and the count can collapse to one or two. Every vendor implements RSA and elliptic-curve cryptography. Several of their post-quantum implementations descend from a common ancestor. Some share a hardware random number generator design. The framework’s cover states the finding as its maxim: “Switching vendors moves the contract, not the dependency.”
What the two regimes ask
DORA asks two questions of a critical arrangement. Article 28(4)(c) asks whether it reinforces concentration risk, and Article 29 asks whether the provider is substitutable. If this provider fails, can the service move to another? The analysis is principally expressed in terms of ICT third-party providers and their substitutability or connectedness, and it does not expressly require resolving the common cryptographic dependencies beneath those providers.
The UK built its answer as an oversight regime rather than a firm-side test. The critical third parties regime took effect on 1 January 2025 under PS16/24, the joint Bank of England, PRA and FCA policy statement. It applies to a given provider only once HM Treasury designates it, with the first designations following in 2026, and it complements rather than replaces firms’ own third-party duties. Designation attaches to a provider. So does every duty that follows from it.
Both instruments operate at the vendor layer, and at that layer both work as designed. Our claim is narrower. The failure mode that concerns us is invisible at that layer, no matter how well the tests are run.
Beneath the register
Substitutability answers one question, whether the contract can move. A vendor register is, in the end, a list of who invoices you, and the register’s unit of analysis is the counterparty. Implementation lineage, firmware family and key generation design are not columns in it.
A test defined over the register cannot fail on facts the register doesn’t record. Five suppliers whose implementations descend from one upstream codebase pass it as five, and a defect in that one codebase reaches all five on the same day.
The pattern has a history in finance itself. Through 2007, the counterparty lists at the institutions writing credit protection were long and reassuring, AIG’s most famously among them, and diversification was measured across those names. The exposure underneath was one asset class.
When US housing prices fell, the names failed together, because the risk had never been distributed across the counterparties in the first place. It had been distributed across signatures on the same underlying. Counting contracts answered a real question, just not the one that mattered in 2008, and counting vendors is not the one that matters for a shared cryptographic defect.
The market has adapted to what the tests examine. Much of what is sold as vendor diversity is rebadging, and a procurement exercise that adds a fifth supplier from the same lineage adds invoices, onboarding cost and audit surface while leaving every layer’s count where it was.
Measuring beneath it
The framework resolves each important business service at six layers where a single defect crosses nominally independent vendors: algorithm, implementation lineage, trust root, key custody platform, protocol negotiation and key generation design. Each layer reports two figures, an index over what executes and the reach of each shared upstream failure domain. The worked retrodiction shows what those layers read on the best-documented below-vendor failure on record.
For the register itself, the framework’s integration action is procedural rather than philosophical. Extend the concentration assessment with a cryptographic-dependency dimension, record lineage, firmware family and manufacturer origin behind each critical provider, and add lineage disclosure to the due-diligence questionnaire. That single step converts the assessment into a procurement control.
The claim, on the record
As at August 2026, no published analysis we can find argues that DORA and UK CTP substitutability tests structurally miss shared-lineage concentration, and no published concentration metric operates below the vendor layer. Both positions are stated, with the survey method behind them, on our provenance page, where anyone can file the counterexample. We would rather correct that page than defend it. The document set that makes the argument computable is published at ccframework.org, release-candidate labelled, open items listed.