Cloud & managed services
Encryption, KMS, HSM, TLS, identity and certificate capabilities may be controlled partly or entirely by a cloud or managed-service provider.
Risk perspective
Outsourcing technology does not outsource the risk.
Modern services depend on complex technology supply chains. Cryptographic functions may be embedded in SaaS platforms, cloud services, managed PKI, identity providers, network products, operating systems, libraries, hardware, payment services and other externally supplied technologies.
The organisation may not control the algorithm, certificate hierarchy, key-management mechanism, software component or migration schedule. That makes supplier capability and transparency part of the organisation's own cryptographic resilience.
Risk lens
A third-party dependency becomes a cryptographic resilience risk when the organisation depends on a supplier's cryptography but lacks sufficient visibility, influence, alternatives or transition capability if that cryptography must change.
Where dependency appears
Cryptographic control is distributed across the supply chain.
SaaS platforms
The customer may have limited visibility into cryptographic implementations, supported algorithms, key ownership or the provider's migration roadmap.
Libraries & components
Applications inherit cryptographic capabilities and vulnerabilities from frameworks, libraries, runtimes and other software dependencies.
Commercial technology
Network, security, endpoint, database and infrastructure products can constrain which protocols, algorithms and key types the organisation can use.
PKI & identity providers
External CAs, identity platforms and trust services introduce dependencies on external certificate, signing and key-management capabilities.
Supplier supply chains
A direct supplier may itself depend on cloud providers, software components, hardware manufacturers and other sub-tier suppliers that affect resilience.
Dependency mapping
Follow the dependency beyond the contract boundary.
Traditional third-party registers often identify the supplier and service but not the cryptographic mechanisms the business ultimately relies on. A risk-relevant view connects the external dependency to the business outcome it supports.
A practical third-party dependency view
Business service → external product/service → cryptographic function → supplier-controlled implementation → sub-tier dependency → data/transaction protected → contractual requirement → internal owner → transition alternative.
The goal is not to demand full technical disclosure from every supplier. The level of information and assurance should be proportionate to criticality, data sensitivity, concentration risk, replaceability and the potential impact if the supplier cannot adapt.
Governance across the lifecycle
Supplier cryptographic risk should be governed before, during and after acquisition.
01Identify criticalityDetermine which products and services create material cryptographic dependencies for critical services or sensitive information.
02Perform due diligenceAssess supplier capability, resilience, relevant security practices and important technology dependencies before commitment.
03Set requirementsDefine proportionate security, cryptographic, notification, evidence and transition expectations.
04Contract & clarify responsibilityTranslate material requirements into agreements, SLAs and shared-responsibility models where appropriate.
05Monitor changeTrack material vulnerabilities, deprecations, product changes, incidents and supplier migration plans throughout the relationship.
06Plan transition & exitUnderstand alternatives, data/key portability, migration constraints and residual dependencies if the service must change or be replaced.
What can go wrong?
Third-party cryptographic risk is often a loss-of-control problem.
Unknown implementation
The organisation cannot determine whether a critical supplier relies on deprecated or otherwise unacceptable cryptography.
Supplier migration delay
The organisation is ready to migrate, but a critical product, protocol or service does not yet support the required alternative.
Limited alternatives
Proprietary interfaces, key formats, trust models or data portability constraints make replacement slow or disruptive.
Common dependency
Multiple critical services depend on the same provider, library, CA, platform or cryptographic component, amplifying a single weakness.
Weak requirements
Agreements do not provide sufficient notification, assurance, migration support or clarity over cryptographic responsibilities.
Hidden supply-chain dependency
A supplier's own provider or component becomes the real constraint, but the organisation has little visibility into that relationship.
Risk management evidence
What should Information Security Risk Management expect to see?
Critical supplier segmentationA risk-based method for identifying which suppliers and products require deeper cryptographic and resilience oversight.
Defined supplier requirementsSecurity and cryptographic expectations proportionate to service criticality and potential business impact.
Due diligence evidenceAssessment of relevant supplier security practices, resilience, technology provenance and dependencies before or during the relationship.
Contractual coverageMaterial requirements reflected in contracts or agreements, including responsibilities, notification and evidence expectations where appropriate.
Dependency visibilityUnderstanding of critical external cryptographic dependencies, including major cloud, software, PKI, identity and platform reliance.
Ongoing monitoringA process to reassess suppliers when vulnerabilities, standards, products, ownership or cryptographic requirements materially change.
Migration readinessVisibility of supplier roadmaps and constraints where algorithm, protocol, certificate or key-management changes are expected.
Exit and contingency considerationsAwareness of portability, alternative suppliers, transition complexity and concentration risk for critical dependencies.
Questions to ask
Useful questions for supplier and risk conversations.
Which critical business services depend on cryptography controlled by external suppliers?
Which suppliers determine the algorithms, protocols, certificates or key-management capabilities we can use?
Do our contracts provide the information and support needed when cryptographic requirements change?
How quickly can a critical supplier support migration away from a deprecated or vulnerable cryptographic mechanism?
Are multiple critical services concentrated on the same provider, library, CA or technology platform?
What important sub-tier dependencies could constrain the supplier's ability to respond?
What happens to keys, certificates, encrypted data and trust relationships if we change or exit the supplier?
Which suppliers have credible post-quantum migration plans, and where are we still dependent on their timelines?
Quantum readiness
Your PQC timeline may depend on someone else's roadmap.
Post-quantum migration will require organisations to understand not only their own use of quantum-vulnerable cryptography but also dependencies on vendors, products, cloud services and externally managed technology.
Supplier readiness, product support, interoperability and migration sequencing can therefore become material constraints. Asking critical suppliers about quantum readiness early is part of managing the organisation's own transition risk.
Primary references
Standards and guidance behind this page.
NIST SP 800-161 Rev. 1Cybersecurity Supply Chain Risk Management Practices for Systems and OrganizationsNIST SP 1305CSF 2.0 Quick-Start Guide for Cybersecurity Supply Chain Risk ManagementNIST SP 1326Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start GuideNIST NCCoE Quantum-ReadinessMigration to Post-Quantum Cryptography — including supply-chain quantum readiness
This page applies public C-SCRM guidance specifically to cryptographic resilience. Supplier requirements should be tailored to criticality, contractual context, applicable regulation and the organisation's risk appetite.