How PQCClear Protects the CBOMs Banks and Vendors Trust Us With

We didn’t arrive at this by accident. Holding cryptographic detail across many banks and vendors is the core of what PQCClear does, so getting the custody question right isn’t a feature request. It’s a design responsibility that comes with the business itself.

A few of the specific mechanisms below are still being built out as our assessment and scanning capability rolls out. Where that’s the case, we’ve said so plainly rather than describing something as live before it is. The principles underneath them are locked regardless of build sequence.

1. 01

   Full detail is gated. Summaries aren't. A vendor's score and certificate status are built to be checked quickly, including by a bank at a lower risk tier that hasn't opened a full technical file. The complete assessment record, including CBOM detail, sits behind its own access point rather than being bundled into anything that circulates freely.

2. 02

   Opening the full record means stepping back through the door. Full assessment files are designed to require credential re-authentication before they open, even for someone already signed into the platform. A valid session isn't treated as permanent permission to pull the most sensitive document in the account.

3. 03

   Every access leaves a record. Who opened a file, and when, is captured in an organization-level audit trail rather than left to be inferred after the fact. This applies whether the person opening it is at the bank, at the vendor, or anyone else with legitimate reason to be in the account.

4. 04

   Records don't quietly change after the fact. An assessment is dated and tied to the specific model and scan version that produced it, and it doesn't get silently recalculated later if the underlying methodology changes. If you're looking at last quarter's result, it should still say what it said last quarter.

5. 05

   One institution's data doesn't bleed into another's. Your institution's assessments, questionnaire answers, and scan results are private to your account. The only thing ever visible outside your institution is a vendor's own public certificate lookup, which the vendor controls and which never includes another institution's underlying assessment.

Part 9 also raised a harder, more structural question: what protects the platform itself, the infrastructure actually holding all of this. That’s a real, ongoing question for any organization in this position, PQCClear included, and it deserves a more specific answer than a single paragraph at the end of an introductory series can give it. We’d rather flag that honestly than gesture at a level of assurance we haven’t fully detailed yet.

The same care we’re asking vendors to bring to their own systems is the care we owe to what they hand us.

Ten posts ago, this series opened with a simple question: why would anyone need an inventory of their own encryption? Everything since has been that one idea, unfolded a layer at a time. Why the timeline compressed. Why it becomes a vendor’s problem, and then a bank’s problem, whether either one asked for it. What a real answer sounds like, versus a reassuring one that says nothing. Which document to reach for, and when. And finally, once all of it exists, who should be trusted to see it.

If you started this series not knowing what a CBOM was, that gap should be closed now. If you’re working out how to put any of it into practice, whether as a bank building a vendor assessment program or a vendor preparing to answer the questions this series has walked through, that’s exactly what PQCClear is built for.