Third-party cryptographic risk is the exposure created by cryptography that protects your data but runs on systems you do not own: a payment gateway, a document-signing platform, a SaaS vendor’s API. DORA, NIS2 and PCI DSS all require you to know which third parties you depend on. None of them asks directly what cryptography those third parties run. A Cryptography Bill of Materials (CBOM) that records what crosses the boundary between your systems and theirs is how you close that gap.
Most cryptographic inventory work starts, reasonably, inside the perimeter you control: your servers, your applications, your certificates, your keys. This post covers what the main regulations already ask about third parties, where their requirements stop, and how to extend a cryptographic inventory to the edge of your estate without depending on vendors to report on themselves.
What regulators already ask for
The clearest example is the EU’s Digital Operational Resilience Act (DORA), which has applied to financial entities since 17 January 2025. Article 28(3) requires firms to keep a register of information covering all contractual arrangements for ICT services provided by ICT third-party service providers, distinguishing the arrangements that support critical or important functions from those that do not. Firms must also report at least yearly to their competent authorities on new arrangements, the categories of provider, the types of contract and the ICT services and functions provided.
That register data has already been used. National competent authorities passed the first registers to the European Supervisory Authorities (ESAs) by 30 April 2025, and on 18 November 2025 the ESAs, drawing on those registers, designated 19 providers as critical ICT third-party service providers under DORA’s Article 31 criteria.
PCI DSS v4 asks something structurally similar in Requirement 12.8:
- 12.8.1: a list of all third-party service providers (TPSPs) with which account data is shared or that could affect its security, with a description of each service.
- 12.8.2: written agreements in which TPSPs acknowledge responsibility for the security of the account data they handle, or for their impact on the cardholder data environment.
- 12.8.3: an established process for engaging TPSPs, including due diligence before engagement.
- 12.8.4: a programme to monitor each TPSP’s PCI DSS compliance status at least once every 12 months.
- 12.8.5: information about which PCI DSS requirements each TPSP manages, which the entity manages, and which are shared.
NIS2 adds a third angle. Article 21(2) lists the baseline cybersecurity risk-management measures for essential and important entities, including supply chain security in point (d) and policies on the use of cryptography in point (h). Article 21(3) requires entities, when deciding on supply chain measures, to take into account the vulnerabilities specific to each direct supplier and service provider and the quality of their products and cybersecurity practices.
Three frameworks, three regulators, and the same underlying ask: know who you depend on, and take responsibility for what that dependency means.
The gap: a supplier register is not a cryptographic inventory
None of those requirements asks directly which algorithms, protocols or key lengths your vendors use to protect the data you hand them. A DORA register records that a critical function runs through a named provider. It does not record whether that provider’s API still negotiates an outdated TLS version on a legacy endpoint, or whether the document-signing service you use for contracts still signs with RSA. PCI DSS Requirement 12.8.5 tells you which party owns which requirement, not what the cryptography behind that requirement looks like today. NIS2 asks you to weigh a supplier’s security practices and separately to have cryptography policies, but it does not join the two into a named inventory of supplier cryptography.
NIST’s guidance on cyber supply chain risk, SP 800-161 Revision 1 (published May 2022, updated November 2024), describes the root of the problem: an enterprise’s decreased visibility into how the technology it acquires is developed, integrated and deployed. Its answer is a multilevel approach across the enterprise, mission and business process, and operational levels, including risk assessments for individual products and services. The framework tells you to build that picture. It does not hand you one.
Where third-party cryptography shows up
In practice, third-party cryptographic exposure surfaces in a small number of predictable places:
- API integrations, where a vendor terminates TLS and you have no record of which version, cipher suite or key exchange its endpoint negotiates.
- E-signature and document platforms, whose signing keys and algorithms you never see, only trust.
- Software dependencies pulled into your own applications, each carrying its own cryptographic choices.
- Managed infrastructure such as cloud services, HSM-as-a-service and managed PKI, where the configuration protecting your workload sits inside a shared-responsibility model rather than a document anyone hands you by default.
None of these appear in a register built around contracts and criticality. Most of them can be observed from your side of the connection.
Extend discovery to the boundary, rather than relying on self-reporting
Asking every vendor to complete a cryptography questionnaire has an obvious weakness: the answers are only as complete and current as the vendor makes them. The more reliable starting point is the boundary you do control. The TLS handshake your systems make to a vendor’s API, the certificate chain that endpoint presents, and the signature algorithm on a document the vendor signs for you are all observable without the vendor’s cooperation. Software dependencies are the exception: they need software composition analysis or the supplier’s own bill of materials, because they sit inside code you did not write.
A CBOM is the right structure to hold the result. CycloneDX added cryptographic assets in version 1.6, and its component model carries a supplier field alongside cryptoProperties, so a third party’s cryptographic footprint can sit in the same inventory as everything you run internally rather than in a spreadsheet attached to the vendor register.
Where to start
Not every vendor relationship needs the same scrutiny on day one. DORA’s own split between arrangements that support critical or important functions and those that do not is a reasonable model to borrow, even outside financial services. Start with the integrations that carry the most sensitive data or the longest confidentiality requirements, record what cryptography crosses that boundary today, and work outward. A register that names your suppliers is a start. An inventory that also records what those integrations are protected with is what turns knowing who you depend on into knowing what you are exposed to.
Where Quantum Sentinel fits
Quantum Sentinel’s scanning workers sit inside your network, probe the endpoints in scope and record what they negotiate: protocol versions, cipher suites, key exchange and certificates. Read-only integrations with network appliances such as F5 BIG-IP, FortiGate, PAN-OS and Cisco ASA, which are frequently the real internet-facing TLS endpoint, add the TLS profiles and certificates configured there. Discovery is agentless apart from a read-only Kubernetes sidecar, and collects metadata only: private keys and file contents are never retrieved. Findings are assembled into a CBOM exported as CycloneDX 1.7 JSON. Quantum Sentinel does not inspect operating system packages, language dependencies or SBOMs, so third-party libraries need a separate source. The cryptographic coverage page sets out what is covered and how.
Frequently asked questions
Does DORA require a cryptographic inventory of ICT third-party providers?
No. Article 28(3) of DORA requires financial entities to keep a register of information on all contractual arrangements for ICT services provided by ICT third-party service providers, distinguishing those that support critical or important functions. It does not ask which algorithms, protocols or key lengths a provider uses.
What does PCI DSS Requirement 12.8 require for third-party service providers?
A list of all third-party service providers with which account data is shared or that could affect its security (12.8.1), written agreements (12.8.2), due diligence before engagement (12.8.3), monitoring of each provider’s PCI DSS compliance status at least once every 12 months (12.8.4), and information on which requirements each party manages (12.8.5).
Does NIS2 cover the cryptography of suppliers?
Indirectly. Article 21(2) of NIS2 lists supply chain security and policies on the use of cryptography among the baseline measures, and Article 21(3) requires entities to take into account the vulnerabilities and cybersecurity practices of their direct suppliers and service providers. It does not name a cryptographic inventory of suppliers.
How can you see a vendor’s cryptography without asking the vendor?
By recording what crosses your own side of the boundary: the TLS versions, cipher suites and key exchange a vendor’s endpoint negotiates with your systems, the certificate chain it presents, and the signature algorithm on documents it signs for you. Those observations can sit in a CBOM alongside your internal findings.
Sources: Regulation (EU) 2022/2554 (DORA), Articles 28, 31 and 64; ESAs, timeline to collect registers of information (15 November 2024); EBA, ESAs designate critical ICT third-party providers (18 November 2025) and the list of designated providers; Directive (EU) 2022/2555 (NIS2), Article 21; PCI Security Standards Council, PCI DSS v4.0 SAQ D for Merchants, Requirement 12.8; NIST, SP 800-161 Rev. 1; OWASP, CycloneDX v1.6 released; CycloneDX, 1.7 JSON schema.
Further reading: what a cryptography bill of materials is, CBOM and CycloneDX, PCI DSS Requirement 12.3.3 and the cryptographic inventory and compliance-ready discovery.