Vendor Cryptography Risk
Supply Chain Crypto Risk: Why Your Vendors' Cryptography Is Your Problem
Your vendors' cryptographic posture becomes your risk. Learn how to assess supply chain crypto risk, require CBOMs from vendors, and build PQC requirements into procurement.
Supply Chain Crypto Risk: Why Your Vendors' Cryptography Is Your Problem Your organization may have the most rigorous cryptographic controls in the industry. But if your SaaS payroll provider terminates TLS with an RSA 1024 certificate, or your cloud payment processor has no PQC roadmap, you inherit that risk. Supply chain cryptographic risk is the blind spot most organizations discover too late. This article explains how vendor managed cryptography creates exposure, how to assess it, and how to build cryptographic requirements into your procurement and vendor management processes. For related context, see SBOM and Cryptography. Where Vendor Crypto Risk Hides Every third party service that handles your data introduces cryptographic dependencies: SaaS platforms: CRM, HR, payroll, collaboration tools — all terminate TLS on their infrastructure using their certificates and algorithms. Cloud providers: AWS ALB, CloudFront, Azure Front Door, Cloudflare — you configure the service, they manage the certificate and TLS termination. Payment processors: Stripe, Adyen, PayPal — they encrypt transaction data. Their cryptographic posture is your PCI DSS compliance dependency. API and integration partners: Every REST API you call over HTTPS relies on the provider's TLS configuration. Managed security services: SOC, SIEM, EDR platforms that ingest your data over encrypted channels. In each case, you do not control the algorithm, the key size, the certificate lifecycle, or the PQC migration timeline — but you do own the risk if customer data is exposed through a vendor's cryptographic failure. How to Assess Vendor Crypto Risk Step 1: Inventory Your Vendor Cryptographic Dependencies List every vendor that transmits, processes, or stores your data. For each, document: Which data they handle (PII, PHI, PCI, internal) Whether they terminate TLS on your behalf Whether you know their cryptographic configuration Step 2: External Assessment (Where Authorized) For vendors where you have contractual authorization, or for publicly visible endpoints (e.g., yourcompany.vendor.com ), run an external cryptographic posture assessment. Record the TLS certificate algorithm, key size, and TLS version. CipherReady can assess any domain you are authorized to evaluate. Step 3: Send a Structured PQC Questionnaire For vendors you cannot scan directly, send a structured questionnaire covering: PQC roadmap and timeline NIST algorithm support plans CBOM availability Hybrid certificate and hybrid key exchange plans Cryptographic incident response process CipherReady's Vendor PQC Questionnaire template covers all of these areas. Step 4: Classify Vendor Risk Assign each vendor a cryptographic risk tier: Critical: Handles regulated data; TLS terminates on their infrastructure; no published PQC roadmap. Requires immediate engagement. High: Handles sensitive data; PQC roadmap published but no timeline. Quarterly review. Medium: No regulated data; PQC roadmap with specific timeline. Annual review. Low: Public data only; PQC migration in progress. Monitor. Building PQC into Procurement The most effective time to manage vendor crypto risk is before you sign the contract. Add PQC readiness criteria to your RFPs and vendor security assessments: For related context, see TLS and Certificate Risk. "Vendor must provide a Cryptographic Bill of Materials (CBOM) for the proposed system." "Vendor must describe their PQC migration roadmap and timeline for NIST algorithm support." "Vendor must suppo