Third-Party Cryptographic Risk: The Conversation Banks Should Carry On After Money20/20

‍Money20/20 USA (October 18 to 21, 2026, in Las Vegas) brought together the world of financial services around real-time payments, embedded finance, digital assets and AI-driven commerce. Every new partnership expands your bank’s capabilities and reaches new customers, but it also expands your cryptographic footprint through integrations you don’t directly manage or control. Many security teams are actively building post-quantum migration plans for their internal banking software, yet your overall exposure depends just as much on core card processors, fintech platforms, software providers and cloud infrastructure partners. If external connections still rely on legacy public-key encryption, your sensitive customer records, settlement files and wire transactions remain vulnerable across the broader financial supply chain.

‍

Executive Summary

• Third-Party Cryptographic Risk: The exposure a bank inherits from the encryption algorithms, keys and digital certificates used by vendors, processors and cloud partners to protect shared connections and data.

• Why Quantum Computing Makes It Urgent Now: Adversaries are capturing encrypted financial traffic today to decrypt it later once quantum hardware matures, an approach known as harvest now, decrypt later (HNDL).

• Single Action Plan for This Quarter: Align with enQase’s four-stage framework (Identify, Protect, Govern, Adapt) and carry out a thorough post-quantum vendor assessment, asking every critical partner for a machine-readable cryptographic bill of materials alongside their post-quantum roadmap.

‍

What Is Third-Party Cryptographic Risk?

Third-party cryptographic risk is the exposure a bank inherits from the encryption algorithms, keys and digital certificates used by its vendors, processors and cloud partners to protect shared data, API endpoints and authentication channels. When external partners rely on vulnerable algorithms, your institution remains exposed regardless of how robust your internal controls are.

A Simple Definition for Banking Leaders

Third-party cryptographic risk occurs whenever an outside vendor encrypts, transmits, digitally signs or stores your bank’s data using keys, certificates or algorithms that your security operations team cannot directly see, manage or update.

For example, think of a core card processor that terminates Transport Layer Security (TLS), the standard protocol that encrypts web and API connections, using legacy public-key algorithms for key exchange. Even if your bank stores customer records securely in an encrypted database, every payment transaction or account query passing through that processor’s connection uses an algorithm vulnerable to future quantum decryption. If an attacker intercepts and stores that network stream today, they could decrypt it once quantum capability arrives, despite your strict internal policies.

How It Differs from Traditional Third-Party Risk Management

Traditional vendor reviews rely on periodic questionnaires. Procurement teams typically ask vendors simple questions such as: “Do you encrypt customer data at rest and in transit?”

While a vendor might check “yes,” traditional questionnaires rarely investigate the deeper technical details:

• Which specific public-key algorithms perform the key exchange?

• What are the key lengths, cipher suites and certificate expiration schedules?

• Who generates the underlying root keys, and is the entropy source validated?

• What is the vendor’s concrete timeline to transition to post-quantum standards?

Simply knowing that data is “encrypted in transit” is no longer enough. Standard questionnaires confirm that an encryption lock is present, but they tell you nothing about whether that lock can withstand emerging quantum threats.

‍

Why Is Third-Party Cryptographic Risk a Quantum Security Problem?

Third-party cryptographic risk is fundamentally a quantum security problem for banks, because today’s commercial connections depend on public-key encryption that quantum computers are expected to break. When external payment networks and software providers use legacy encryption, they expose your long-lived banking data to intercept-and-decrypt attacks happening right now.

Q-Day and the Vulnerability of RSA and Elliptic Curve Cryptography

Q-Day refers to the point when a cryptographically relevant quantum computer becomes operational. A cryptographically relevant quantum computer running Shor’s algorithm would break Rivest–Shamir–Adleman (RSA) and Elliptic Curve Cryptography (ECC). No one knows when one will exist, but estimates of the resources needed keep falling.

RSA and ECC are the foundational public-key algorithms that secure almost every vendor connection, digital certificate, software signature and API gateway across modern financial institutions. Once Shor’s algorithm runs on such hardware, these algorithms will no longer provide confidentiality or digital signature verification. To prevent widespread disruption, banks and their vendor ecosystems must transition to post-quantum cryptography, which relies on mathematical problems that resist both classical and quantum attacks.

Harvest Now, Decrypt Later Across the Payment Chain

You might wonder why vendor encryption matters today if large-scale quantum computers are still years away. The reason is an active threat: harvest now, decrypt later.

Adversaries are intercepting and archiving encrypted network traffic moving between banks, core processors, fintech apps and cloud services. While attackers cannot read this traffic today, they can hold the encrypted data until quantum capability matures and decrypt it then.

This poses a severe threat to long-lived financial records, including:

• Customer identity profiles and Know-Your-Customer (KYC) documentation

• Long-term mortgage and commercial loan applications

• Historic account ledgers and tax records

• Cross-border wire transfers and settlement logs with multi-year retention mandates

The financial data with the longest legal retention requirements is often the very same data moving through the highest number of third-party vendors.

Your Migration Is Only as Fast as Your Slowest Vendor

A bank can spend millions upgrading its internal core infrastructure to post-quantum cryptography, but its external connections remain vulnerable if payment partners, cloud providers or fintech aggregators lag behind.

Modern API integrations and secure file exchanges require both sides of a connection to support matching encryption protocols. If your partner’s system cannot support post-quantum key exchange, the connection must fall back to legacy RSA or ECC. Your overall quantum security posture is therefore bounded by your least prepared vendor, making third-party readiness a primary gating factor in your enterprise migration timeline.

‍

Where Does Cryptographic Risk Hide in a Bank’s Vendor Ecosystem?

Cryptographic risk hides at every integration point where data leaves your direct control, including payment messaging rails, cloud application interfaces, open banking aggregators and underlying fourth-party software libraries.

Core Banking, Card Processing, and Payment Networks

Payment infrastructure relies on deep layers of public-key cryptography that run quietly behind daily operations across institutional boundaries:

• Message Signing: Digital signatures that verify the origin and authenticity of payment messages across International Organization for Standardization (ISO) 20022 messaging rails.

• Inter-Institutional Key Exchange: Secure key agreement protocols that enable real-time gross settlement systems and clearinghouses to exchange financial data securely.

• Hardware Security Modules (HSMs): Specialized cryptographic hardware that manages root keys, PIN translation and card verification values across payment networks.

If a core banking vendor or card processor uses legacy public-key algorithms to manage HSM keys or sign payment messages, transactions moving across those channels remain exposed to long-term harvesting.

Cloud, Software-as-a-Service (SaaS), and API Partners

As banks move workloads to hybrid cloud platforms and SaaS solutions, external interfaces expand rapidly. Key areas of hidden exposure include:

• TLS Termination Points: Edge load balancers and cloud gateways where encrypted user sessions are decrypted before traffic reaches internal microservices.

• Mutual Transport Layer Security (mTLS): Authentication setups where client and server verify each other’s digital certificates before opening communication tunnels between services.

• Token Signing: Cryptographic keys used to issue and validate access tokens (such as JSON Web Tokens) for API authorization.

Weak key lengths, legacy algorithms or unmonitored digital certificates at these termination points allow attackers to eavesdrop on private sessions or forge administrative tokens.

Fintech, Banking-as-a-Service (BaaS), and Open Banking Connections

Open banking models rely heavily on lightweight REST APIs to link financial institutions with fintech tools, credit scoring engines and account aggregators. Because these agile fintech partners move quickly, they often prioritize rapid product iteration over deep cryptographic governance. This makes open banking connections one of the fastest-growing yet least cryptographically mature segments of the banking supply chain.

Fourth-Party and Embedded Dependencies

Your direct vendors rely on their own technical suppliers, introducing hidden fourth-party cryptographic risk. These indirect dependencies include:

• Open-Source Cryptographic Libraries: Core software tools (such as OpenSSL) embedded directly into vendor products to execute encryption functions.

• Public Key Infrastructure (PKI) Providers: External Certificate Authorities (CAs) that issue, validate and revoke digital certificates across vendor server networks.

• HSM Manufacturers: Hardware vendors that provide physical security modules to cloud providers and card processors.

A single vulnerability or legacy algorithm in a fourth-party open-source library can compromise an entire suite of third-party vendors, leaving your bank exposed to risk from suppliers you have no direct contract with.

‍

What Do Regulators Expect From Banks on Vendor Cryptography?

Supervisors expect financial institutions to manage operational risk across their entire third-party ecosystem, including the encryption protocols in use and the vendor dependencies behind them. None of the frameworks below names a specific post-quantum algorithm, but each gives banks a reason to know and govern the cryptography their vendors use.

U.S. Interagency Guidance on Third-Party Relationships

In June 2023, the Board of Governors of the Federal Reserve System, the Federal Deposit Insurance Corporation (FDIC) and the Office of the Comptroller of the Currency (OCC) released joint Interagency Guidance on Third-Party Relationships. It does not mention quantum, but it makes clear that outsourcing does not outsource responsibility, including for the cryptography vendors use.

If a third-party processor uses weak key management or legacy algorithms that put customer records at risk, the bank remains responsible for having identified and managed that risk across the relationship life cycle.

PCI DSS v4.0.1 and Cryptographic Inventory

PCI DSS v4.0.1 Requirement 12.3.3 (mandatory since 31 March 2025) asks for a documented inventory of cipher suites and protocols in use, reviewed at least every 12 months. A cryptographic bill of materials (CBOM) is a practical way to meet it.

Because card processing relies heavily on third-party gateways and cloud services, that inventory must accurately reflect the cipher suites and protocols running across all third-party integrations in scope.

DORA and Information and Communication Technology (ICT) Third-Party Risk

For institutions operating in or connecting to European markets, the Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, requires oversight of ICT third parties and cryptographic controls that are updated as cryptanalysis advances. A post-quantum vendor assessment is a practical way to show this. DORA also requires banks to maintain a register of information covering all ICT third-party arrangements and to review those risks regularly.

Separately, the European Union’s Coordinated Implementation Roadmap for the post-quantum transition recommends starting by the end of 2026 and protecting high-risk use cases by 2030.

NIST Post-Quantum Standards and Deprecation Timelines

In August 2024, the National Institute of Standards and Technology (NIST) published its finalized post-quantum standards:

• FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) for general encryption and key exchange.

• FIPS 204: Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for primary digital signatures.

• FIPS 205: Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) for specialized digital signatures.

Additionally, final NIST IR 8547 sets out NIST’s transition plan for quantum-vulnerable public-key algorithms, including staged timelines through 2035. Because major software and hardware procurement agreements in banking span multi-year cycles, vendor contracts signed today will remain active during these transition milestones.

‍

The Conversation Banks Should Carry On After Money20/20

Money20/20 USA brought together banking leadership, card networks, fintech innovators and cloud infrastructure providers. The conversations started there are the natural place to put post-quantum readiness on the vendor agenda, and the follow-ups and contract renewals that come next are where it gets settled.

Turning Event Conversations into Vendor Commitments

The show gathered decision makers from core banking platforms, payment processors, open banking aggregators and security operations providers. Sessions explored real-time payments, embedded finance, digital assets and AI-driven commerce, and every one of these innovations expands your bank’s external cryptographic connections.

Rather than treating quantum security as an isolated topic, build it into every partnership follow-up, vendor review and renewal that comes out of the event. For more event takeaways, see enQase’s Crypto-Agility at Money20/20 USA 2026: What Banks and Payment Providers Should Know Before Las Vegas.

Seven Questions to Ask Every Payments and Fintech Vendor

When following up with critical service providers, or when their contracts come up for renewal, use this checklist to evaluate third-party cryptographic risk:

1. Algorithms in Use: Which specific public-key algorithms, key lengths and cipher suites protect our shared data in transit and at rest today?

2. Post-Quantum Roadmap: Do you have a documented post-quantum migration roadmap with target dates aligned with NIST milestones?

3. NIST Standards Support: Do you currently support, or plan to support, hybrid ML-KEM key exchange across your API endpoints?

4. Cryptographic Bill of Materials: Can you provide a machine-readable cryptographic bill of materials for the services and software we license?

5. Entropy and Key Generation: How are your keys generated, and is your entropy source NIST ESV-validated (SP 800-90B)?

6. Fourth-Party Dependencies: Which fourth-party dependencies (such as open-source libraries, Certificate Authorities or HSM manufacturers) does your cryptographic stack rely on?

7. Agility and Swap Speed: How quickly can your infrastructure replace an algorithm or update cipher suites without causing downtime or service disruptions?

‍

How Can Banks Assess and Reduce Third-Party Cryptographic Risk?

Managing vendor risk requires a structured framework that connects executive governance with technical architecture. Banks can align their third-party risk strategies directly with enQase’s four-stage framework: Identify, Protect, Govern and Adapt.

Step 1: Identify — Build a Cryptographic Inventory Beyond Your Perimeter

You cannot secure what you cannot see. The first step in managing third-party cryptographic risk is to identify every cryptographic asset operating across your enterprise boundaries.

Instead of relying on basic network scans that only look inward, use automated discovery to map external API endpoints, TLS termination points, mutual authentication setups and partner data exchanges. Tools like enQase’s cryptographic discovery platform scan network pathways to help you build an inventory of active algorithms, certificates and key exchange mechanisms across vendor connections.

Step 2: Govern — Require a Cryptographic Bill of Materials

To establish clear executive governance, banks should require verifiable technical disclosures from vendors. Ask vendors to supply a cryptographic bill of materials: a machine-readable record detailing all algorithms, key sizes, certificate chains and underlying software libraries within their products.

Just as a Software Bill of Materials tracks open-source code components, a cryptographic bill of materials gives your risk team direct visibility into vendor encryption methods during procurement, onboarding and annual contract renewals.

Step 3: Govern — Tier Vendors by Data Sensitivity and Data Lifespan

Not all external service providers present the same level of risk. Security teams should categorize vendors on two main criteria:

• Data Sensitivity: Does the vendor process high-value financial data, core account credentials or personally identifiable information?

• Data Lifespan: Must the shared data remain confidential for five, ten or twenty years?

Vendors handling highly sensitive data with long retention requirements, such as core loan processing systems, custody engines and regulatory archives, carry the greatest harvest now, decrypt later exposure and should be prioritized for remediation.

Step 4: Protect — Update Contracts with Post-Quantum Clauses

To protect your institution from future liabilities, translate your technical requirements into binding commitments during contract renewals. Update standard procurement templates to include explicit post-quantum clauses:

• Alignment with NIST post-quantum standards (FIPS 203, 204 and 205) and migration timelines.

• Annual delivery of an updated cryptographic bill of materials.

• Advance notification before changes to key management practices or cryptographic libraries.

• Right-to-test provisions and defined remediation SLAs for identified algorithmic vulnerabilities.

Step 5: Adapt — Monitor Continuously and Build Crypto-Agility

Because vendor environments change constantly through software updates and cloud reconfigurations, an annual survey is not enough. Institutions should adapt by building continuous monitoring and crypto-agility: the structural capability to swap algorithms, update key lengths and revoke certificates without altering underlying business applications.

With a crypto-agility abstraction layer, your bank can implement post-quantum standards like ML-KEM internally while supporting hybrid connections with external vendors as they complete their own upgrades.

‍

How Does enQase Help Banks Manage Third-Party Cryptographic Risk?

enQase provides an enterprise quantum security platform that helps financial institutions manage third-party cryptographic risk through four stages: Identify, Protect, Govern and Adapt.

Discovery That Maps Cryptography Across Partner Connections

The enQase platform automates the Identify stage by discovering and mapping cryptographic assets across internal systems, API gateways and partner connections.

By scanning network connections and integration points, enQase helps identify vulnerable algorithms, aging digital certificates and legacy key exchanges across partner boundaries. This gives enterprise risk teams the data they need for a post-quantum vendor assessment and supports the evidence for PCI DSS v4.0.1 Requirement 12.3.3 inventory audits and regulatory reporting.

Crypto-Agile Post-Quantum Migration with Minimal Changes to Core Systems

To help banks protect their assets and adapt to changing requirements, enQase provides a modular architecture for crypto-agility.

The platform allows institutions to deploy NIST-standardized algorithms like ML-KEM alongside existing classical encryption. This hybrid approach lets your bank protect critical data channels now while continuing to communicate with third-party vendors as they progress along their own migration paths, reducing the risk of service disruption and costly system rewrites.

‍

Take Control of Your Cryptographic Supply Chain

Is your bank prepared to carry out a post-quantum vendor assessment and manage third-party cryptographic risk across your partner ecosystem? Connect with our team to schedule a third-party cryptographic risk assessment or request a demonstration of our quantum security platform.

Schedule Your Cryptographic Risk Assessment with enQase

Frequently Asked Questions (FAQ)

1. What is third-party cryptographic risk?

Third-party cryptographic risk is the exposure a bank inherits from the encryption algorithms, keys and digital certificates used by its vendors, processors and cloud partners. If external providers rely on quantum-vulnerable algorithms to handle shared data or API connections, your bank’s data is at risk regardless of your internal controls.

2. Why does quantum computing make vendor risk worse?

A cryptographically relevant quantum computer running Shor’s algorithm would break standard public-key encryption like RSA and ECC. No one knows when one will exist, but estimates of the resources needed keep falling. Through harvest now, decrypt later attacks, adversaries are capturing encrypted financial traffic today to decrypt it once quantum hardware matures, which makes vendor encryption choices a risk today.

3. Are banks responsible for their vendors’ cryptography?

Yes. The U.S. Interagency Guidance on Third-Party Relationships makes clear that outsourcing does not outsource responsibility. PCI DSS v4.0.1 Requirement 12.3.3 asks for an inventory of cipher suites and protocols in use, including across third-party integrations in scope, and DORA requires oversight of ICT third parties and cryptographic controls that keep pace with cryptanalysis.

4. What is a cryptographic bill of materials?

A cryptographic bill of materials is a machine-readable inventory of all encryption algorithms, keys, certificate chains and security libraries used within a product or cloud service. It lets banks carry out a post-quantum vendor assessment with precise data instead of relying on manual surveys.

5. What should banks ask vendors after Money20/20?

In post-show follow-ups and renewals, banks should ask vendors which algorithms protect their data, whether a documented post-quantum migration roadmap exists, whether hybrid ML-KEM key exchange is supported, how keys are generated and whether the entropy source is NIST ESV-validated, and how quickly algorithms can be swapped without disrupting service.

6. How does enQase help banks manage vendor risk?

enQase aligns with an Identify, Protect, Govern and Adapt framework. It helps discover cryptography across internal and partner systems and supports crypto-agility through hybrid key exchange.

7. What is the difference between an SBOM and a CBOM?

A Software Bill of Materials (SBOM) lists the open-source and proprietary code libraries within a software package. A cryptographic bill of materials (CBOM) specifically details the cryptographic components, including active algorithms, key sizes, cipher suites, digital certificates and root key sources.

8. How does crypto-agility protect banks from vendor delays?

Crypto-agility allows an institution to update algorithms, key lengths and certificates through a modular architecture without rewriting underlying applications. This lets a bank deploy post-quantum cryptography internally while supporting hybrid connections for slower-migrating vendors.

9. When do NIST post-quantum standards take effect?

NIST published its first post-quantum standards (FIPS 203, 204 and 205) in August 2024. Final NIST IR 8547 outlines transition timelines for quantum-vulnerable algorithms, with federal migration milestones extending through 2035.

10. What data is most vulnerable to Harvest Now, Decrypt Later attacks?

Data with high sensitivity and long retention requirements carries the greatest exposure to harvest now, decrypt later attacks. This includes customer identity profiles, KYC records, multi-year loan files, account transaction histories and international settlement logs that must remain private for decades.

‍