PQC Basics · Part 5 of 10
Third-Party Risk Management and Encryption: Why Vendor Cryptography Is Your Problem Too
August 21, 2026 · PQCClear · 6 minute read
The first four posts stayed inside one organization looking at its own systems. Here's where that changes. If you work in banking or credit unions, you've likely heard the term third-party risk management already. This post is about why encryption just became part of it, explicitly and by name.
A Bank's Own Encryption Is Only Part of the Picture
A bank can do everything right with its own encryption and still be exposed, because a huge amount of what touches customer data was never built by the bank at all.
Core banking platforms, payment processors, digital banking apps, fraud detection tools, identity verification services. Most banks and credit unions run on a stack of vendor software, not homegrown systems. Customer data flows through all of it. Whatever encryption each of those vendors chose to use, or didn’t, becomes part of the bank’s actual security posture, whether the bank ever looked at it or not.
An Old Idea Getting a New Item on the Checklist
Third-party risk management, usually shortened to TPRM, already exists as an established practice at every bank and credit union. It’s the discipline of assessing vendors before signing a contract and periodically afterward, covering things like financial stability, data handling practices, business continuity planning, and general cybersecurity posture. None of that is new, and none of it started with post-quantum cryptography.
What’s new is narrower and more specific: encryption itself is becoming its own named line item inside a process that already existed. Not a new discipline. A new, specific question inside an old, familiar one.
Why Encryption Specifically Travels Through the Chain
Most TPRM questions are about a vendor’s practices in general terms: do they have a security program, do they patch known flaws, do they have a plan if something goes wrong. Encryption is different in one important way. It’s not just a practice. It’s a specific, checkable technical property of how a vendor actually protects data in transit and at rest, the same kind of thing we defined two posts ago with a CBOM.
Step 1
Bank
Sends customer data to a vendor as part of a normal service.
Step 2
Vendor's systems
Encrypt, or fail to properly encrypt, that data using their own choices.
Step 3
Outcome
Whatever the vendor chose becomes the bank's actual exposure.
The bank never sees step 2 directly. It has to ask, and the vendor has to have an answer better than a general assurance. Which is exactly the gap a CBOM exists to close: not “do you take security seriously,” but “which algorithm, which key size, protecting which data, right now.”
In practice
The exposure isn't hypothetical
Payment processors, core banking vendors, and digital banking platforms routinely handle account numbers, transaction histories, and authentication credentials. That's precisely the data category most worth protecting well, and most worth an attacker's patience.
Institution size
Smaller institutions rely on vendors more, not less
A large bank sometimes builds core systems in-house. A community bank or credit union usually can't, and leans on third-party platforms even more heavily. That makes vendor cryptographic risk a bigger share of total exposure for smaller institutions, not a smaller one.
A bank’s cryptography is only as strong as its weakest vendor’s.
That sentence is the whole argument for this post. It also sets up a complication that makes the timeline for fixing it more urgent than it might first appear. Knowing a vendor’s encryption is weak today is one problem. What happens to the data that vendor already handled, before anyone asked the question, is a different and sharper one. That’s next.
The complication that raises the stakes
Part 6 covers a specific risk that turns “we’ll ask our vendors eventually” into “the exposure may have already happened.” It’s the single most important idea in this series for understanding why the timeline compressed.
Read part 6PQC Basics is an ongoing series from PQCClear explaining post-quantum cryptography readiness in plain language, one idea at a time. This post represents PQCClear’s own editorial explanation and should not be construed as technical, legal, or regulatory advice.
Key sources: the Interagency Guidance on Third-Party Relationships: Risk Management (Federal Reserve, FDIC, and OCC, June 2023); the FFIEC Information Technology Examination Handbook; NCUA Supervisory Letter 07-01 on evaluating third-party relationships.