Why Vendor Category Should Shape Cryptographic Risk Assessment

Recent industry research has made a version of this argument at the asset level: different categories of enterprise systems, from customer-facing platforms to backend cryptographic infrastructure, carry meaningfully different exposure profiles, and treating them identically obscures more than it reveals. We think the same logic applies one layer further out, to the vendors themselves.

A fintech vendor that processes payment transactions is exposed to a different shape of risk than a vendor that provides the underlying cryptographic infrastructure other companies build on, which is different again from a vendor operating blockchain custody or network-level protocol infrastructure. Asking all three the same questions, with the same depth, and weighting their answers the same way, produces a score that’s internally consistent but not actually calibrated to what each vendor is exposed to.

PQCClear’s assessment methodology is built around a fixed set of risk factors applied to every vendor:

1. 01

   Algorithm strength. The strength of the cryptographic algorithms in use.

2. 02

   Data sensitivity. The sensitivity of the data those algorithms protect.

3. 03

   Sensitivity lifetime. How long that data remains sensitive.

4. 04

   Migration readiness. How easily the vendor could migrate to stronger cryptography if needed.

5. 05

   Counterparty exposure. How exposed the vendor is through its own network of counterparties and dependencies.

What varies by vendor category is not which factors apply. It’s how much assessment weight and verification depth each factor receives, based on what’s actually relevant and checkable for that category of vendor. Two of the five factors, how sensitive the data is and how long it stays sensitive, are properties of the data itself, so they’re assessed consistently regardless of vendor type. The other three vary meaningfully by category, because what’s actually diagnostic of risk for a payment processor is not the same as what’s diagnostic for a blockchain infrastructure provider.

The reasoning behind each elevated cell follows directly from what the vendor category actually does. A core software or API provider’s product largely is its cryptographic surface, so algorithm-level scrutiny carries more diagnostic value there than it does for a vendor where cryptography is one component among many. A vendor whose core business is cryptographic infrastructure or protocol-level operation lives or dies on how readily it can adapt when standards change, so migration readiness gets more weight. A vendor deeply embedded in a network of payment counterparties carries more exposure through those relationships than a vendor with a narrower, more self-contained footprint.

The same five factors apply to every vendor. Where the assessment actually digs should not be the same for any two of them.

A readiness score that comes from an identical, undifferentiated process across every vendor category invites a false sense of comparability. Two vendors with the same numeric score, assessed through a process that didn’t account for what each vendor actually does, are not necessarily carrying the same real risk. A bank relying on that score for a third-party risk decision deserves to know the assessment behind it was built with that distinction in mind, not flattened for the sake of a simpler questionnaire.

This is also where we’d point to a broader industry pattern worth noting. Recent analyst commentary on financial-sector cryptographic risk has separately argued that compliance and reputational risk should be tracked as distinct from technical cryptographic risk, rather than blended into one number. That’s consistent with how PQCClear treats regulatory context on a vendor’s report: informative for a bank’s own compliance picture, but kept separate from the technical readiness score itself, rather than mixed into a single figure that would obscure which kind of risk is actually driving it.