Saas Supply Chain Quantum Risk

How supplier quantum exposure becomes your own

Data held by a supplier is protected by the supplier's cryptography, not yours. Their algorithms determine your confidentiality exposure, their signing keys are trusted by your systems, and their roadmap sets the earliest date you can migrate. Inherited exposure is frequently larger than the exposure an organisation controls directly.

How supplier exposure becomes your exposure

Inheritance occurs through three distinct routes, and they require different responses.

Data protected by someone else's algorithms

Every SaaS platform, managed service and outsourced function holds or transmits data on your behalf, protected by cryptography you did not select. If that data has a long confidentiality requirement and the supplier protects it in transit with elliptic curve key exchange, the harvest now, decrypt later exposure is yours, not theirs. The regulatory obligation for the data also remains yours.

This route matters most for outsourced payroll and HR, clinical and case management systems, legal and document management platforms, and any integration carrying personal or commercially sensitive data across public networks.

Trust relationships your systems rely on

Federation is the more immediate risk. Where an identity provider signs SAML assertions or OIDC tokens that your systems accept, a forged signature produces valid authentication into your environment. The same applies to mutual TLS certificates issued by a partner, API keys wrapped under a supplier's key hierarchy, and software your systems install because it carries a supplier's code signing signature.

These dependencies fail at the point a capability exists rather than retrospectively, and the consequence is direct access rather than historic disclosure.

Timeline dependency

An organisation cannot migrate a platform its supplier has not upgraded. Where core business systems are delivered as SaaS or vendor-supported appliances, the supplier's roadmap caps the migration timeline regardless of internal capability, and contractual refresh cycles can extend that cap further.

This is why supplier engagement belongs in the discovery phase. The NCSC expects requirements to be communicated to suppliers by 2028, not at the point migration begins.

Why contracts do not currently cover this

Most existing security schedules were drafted before post-quantum cryptography was a procurement consideration, and they typically require encryption in transit and at rest to an industry standard, without naming algorithms or committing to any transition.

That wording provides no obligation to migrate, no date, no visibility of which algorithms are in use, and no right to require change. It is also usually silent on subprocessors, so a supplier can be compliant while its own suppliers are not.

The practical effect is that inherited exposure sits outside both the customer's control and the contract's scope, which is the position most organisations are currently in.

How to assess supplier post-quantum solutions

General questions produce general answers. Asking whether a supplier is quantum safe reliably returns a yes that means nothing. Specific questions produce assessable answers.

Answers should be assessed against evidence rather than intent. A published roadmap with version numbers is evidence. A statement of commitment is not, and vendor claims about post-quantum support frequently describe availability rather than default behaviour, a distinction covered in our analysis of why PQC vendor claims need scrutiny.

Where post-quantum solutions can remove inherited risk

Some inherited exposure can be eliminated rather than managed, which is worth identifying before investing effort in supplier negotiation.

Client-side encryption removes confidentiality inheritance entirely. Where data is encrypted under your own AES-256 keys before it reaches the supplier, the supplier's transport and storage cryptography becomes irrelevant to its confidentiality, because symmetric encryption at that strength is not quantum-vulnerable. This is viable where the supplier does not need to process the content, and it is the strongest available control.

Customer-managed and externally held keys reduce inheritance partially. Where key material is held in your own hardware security module or external key management service, you control the key hierarchy and its migration, although the supplier's transport cryptography still applies.

Terminating protected sessions at your own boundary helps where integrations traverse public networks. Where you control one end, hybrid key exchange can be enabled on your side and the supplier's position becomes a matter of what they accept rather than what they impose.

Federation exposure is harder to remove, since it is inherent to the trust relationship. Shortening assertion and token lifetimes, monitoring for anomalous authentication, and requiring the identity provider to publish a post-quantum roadmap are the available mitigations.

Fourth-party and deeper dependency

Assessment usually stops at the direct supplier, and the exposure does not.

A SaaS platform running on a public cloud inherits that cloud provider's cryptographic position. A payment service depends on acquirers and networks. A clinical system may integrate with several third-party services that the customer never contracts with directly. Each layer adds cryptographic dependency that the customer cannot see and cannot influence.

The realistic approach is proportionate rather than exhaustive: identify which suppliers hold data with long confidentiality requirements or issue credentials your systems trust, and require subprocessor disclosure for those only. Attempting full nth-party cryptographic mapping across an entire supplier base is not achievable and will consume the effort that should go into the material dependencies.

Contract terms and timing

Leverage exists at defined moments, and outside them it largely does not. Renewal, tender and any material change to services are the points at which cryptographic obligations can realistically be introduced.

Terms worth introducing include named algorithm disclosure with a refresh obligation, a dated commitment to post-quantum key establishment and signatures, subprocessor disclosure covering cryptographic position, provision of a cryptographic bill of materials, notice periods for cryptographic change affecting integrations, and support for customer-managed keys where the data justifies it.

Regulatory pressure is moving in the same direction, which improves the negotiating position. The US Executive Order signed in June 2026 extended post-quantum requirements to federal contractors, DORA imposes ICT third-party risk obligations on financial entities including subcontracting oversight, and NIS2 addresses supply chain security for in-scope organisations. Suppliers serving those markets are increasingly obliged to answer these questions regardless.

How Unsung helps

Unsung is a UK-based, vendor-neutral consultancy specialising exclusively in public key infrastructure and cryptographic systems, working across central government, defence, healthcare, financial services, nuclear and transport.

We identify which supplier relationships carry material cryptographic exposure through our PKI health check and cryptographic bill of materials services, covering federation trust and integration dependencies as well as internal estate. We support procurement and vendor management teams in framing assessable questions and evaluating the answers, and design key custody arrangements, including hardware security module backed customer-managed keys, that remove inheritance where the data justifies it.

For the organisational factors behind exposure, see the seven drivers of post-quantum risk exposure.