When Bybit lost approximately $1.5 billion in February 2025, the initial breach did not originate inside Bybit's own infrastructure. The attack chain ran through Safe, the multisig wallet infrastructure that Bybit relied on for its cold storage operations. The attackers, attributed to Lazarus Group, compromised Safe's systems and used that access to manipulate the signing interface presented to Bybit's signers, resulting in the authorisation of malicious transactions that drained the exchange's ETH cold wallet.
This is the defining characteristic of modern crypto security failures: the most damaging attacks do not come through the front door. They come through the vendor relationships, the infrastructure dependencies, the bridge operators, the oracle providers, and the development tooling that Web3 protocols accept as trusted by default.
Vendor risk management is the discipline of not accepting that default trust. It is the systematic process of understanding who has access to your protocol or infrastructure, what that access entails, how secure their operations are, and how you would know if they were compromised. In Web3, where composability is a feature and interdependence is pervasive, vendor risk management is not an optional governance exercise. It is a core security function.
What is Vendor Risk Management
Vendor risk management, sometimes called third-party risk management or supply chain risk management, is the set of processes an organisation uses to identify, assess, and mitigate the risks introduced by its external suppliers and service providers.
In a conventional enterprise context, vendor risk management typically focuses on data processors, cloud infrastructure providers, and software vendors. The concern is primarily around data protection, business continuity, and regulatory compliance. In Web3, the same structural concerns apply, but the consequence profile is dramatically different. A compromised vendor does not just create a data breach liability. It can result in the direct, irreversible loss of user funds at a scale measured in hundreds of millions of dollars within minutes.
Effective vendor risk management operates across all three dimensions of the People, Process, Technology framework. It requires people with the skills to evaluate and monitor vendors, processes that define how vendors are onboarded, assessed, and exited, and technology that enables continuous monitoring rather than periodic point-in-time assessments.
Why Web3 is Uniquely Exposed
The architecture of Web3 creates vendor risk exposure that has no direct equivalent in traditional financial services or enterprise technology.
Composability and Protocol Interdependence
DeFi protocols are built to be composable: they are designed to interact with other protocols, share liquidity, and rely on shared infrastructure. A lending protocol may depend on an oracle from Chainlink or Pyth for price data, a price manipulation in that oracle feed can trigger catastrophic liquidations or enable flash loan attacks. A bridge protocol may route funds through a relay network operated by a third party, and a compromise of that relay network can drain the bridge entirely.
In traditional finance, the equivalent would be if a bank's entire balance sheet could be emptied because a data feed provider was compromised. The consequence of vendor failure is not a service disruption. It is a total loss event.
The Supply Chain Attack Model
The SolarWinds attack in 2020 demonstrated to the enterprise security world that sophisticated attackers will target software supply chains when direct attacks are too difficult. The principle translates directly to crypto. Lazarus Group, as documented extensively in our analysis of Lazarus Group's crypto operational security, actively targets third-party tooling and service providers as a pivot point to reach primary targets.
The attack vectors include: malicious packages inserted into open-source repositories used by crypto developers; compromised development tool suppliers delivering trojanised software to developer machines; social engineering targeting employees of infrastructure providers to gain credentials for systems used by multiple crypto firms; and front-end attacks where a web hosting provider or CDN is compromised to serve malicious code to protocol users.
In each case, the attacker's primary target never had a security failure directly. The failure was in the supply chain, and the consequence was borne by the primary target.
Implicit Trust in Shared Infrastructure
Many Web3 protocols and exchanges use shared infrastructure components without performing any security assessment of those components. Hardware wallet firmware, wallet connect libraries, open-source smart contract libraries, RPC node providers: all of these are trusted implicitly by protocols and their users. The compromise of any single component in this shared infrastructure can affect thousands of protocols simultaneously.
"In Web3, your security posture is only as strong as the weakest vendor with access to your infrastructure. Most protocols can name their auditors but cannot name their RPC provider's security contact."
Classifying and Tiering Crypto Vendors
The first step in vendor risk management is understanding what vendors you have and what access each of them holds. For many Web3 protocols, this inventory does not formally exist. Vendors are onboarded as and when needed, and the cumulative picture of third-party access is never assessed as a whole.
A tiering model categorises vendors by the level of risk they introduce, which then determines the depth of due diligence and the frequency of monitoring required.
Tier 1: Critical Vendors
Vendors with direct access to funds, private keys, signing infrastructure, or the ability to unilaterally affect protocol operations. Examples include:
- Custody and key management providers (hardware security module suppliers, multisig service providers)
- Bridge operators with relay or validator roles
- Oracle providers whose data feeds directly trigger protocol state changes
- Cloud infrastructure providers hosting administrative systems or hot wallet infrastructure
- Smart contract upgrade key holders
Tier 1 vendors require full security due diligence, including review of audit reports, key management documentation, and incident history, prior to onboarding. They should be subject to continuous monitoring and annual reassessment.
Tier 2: High-Risk Vendors
Vendors with significant but not direct access to funds or protocol operations. Examples include:
- Development tooling suppliers and CI/CD pipeline components
- RPC node providers and blockchain data indexers
- Front-end hosting providers and CDN operators
- Employee identity and access management providers
- Security monitoring and alerting tool providers
Tier 2 vendors require a structured security questionnaire and review of available documentation before onboarding. They should be reassessed every eighteen to twenty-four months and following any significant security incident in the industry.
Tier 3: Standard Vendors
Vendors with limited or no access to sensitive systems or funds. Examples include marketing platforms, analytics providers, and communication tools. Standard due diligence applies, focused primarily on data handling practices and regulatory compliance.
Due Diligence Framework
Vendor due diligence in a crypto context must go beyond the generic questionnaires used in traditional vendor risk programmes. The specific risks of the Web3 environment require crypto-native assessment criteria.
Security Questionnaire
A structured security questionnaire for Tier 1 and Tier 2 vendors should cover the following domains:
- Key management: How are cryptographic keys generated, stored, and rotated? Are hardware security modules used? What is the key ceremony process? Who has access, and under what conditions?
- Access controls: What multi-factor authentication standards are enforced? How is privileged access managed and reviewed? Are background checks performed on employees with access to sensitive systems?
- Smart contract security: For vendors operating smart contracts, what audit firms have reviewed the code? What is the remediation process for audit findings? Is there a bug bounty programme?
- Incident response: Does the vendor have a documented and tested incident response plan? What is their historical incident record and disclosure track record? What is their notification commitment in the event of a breach affecting your organisation?
- Sub-processor and supply chain inventory: What third parties does the vendor itself rely on? Are there concentration risks in the vendor's own supply chain?
- Regulatory compliance: What regulatory frameworks apply to the vendor? What certifications do they hold (SOC 2, ISO 27001)? Are they subject to the same regulatory obligations as your organisation in relevant jurisdictions?
Audit Report Review
For Tier 1 vendors, security audit reports should be requested and reviewed as part of the onboarding process. The review should assess not only the findings but the remediation process: a vendor that has had a critical finding unremediated for six months represents a materially different risk profile from one that resolved all critical findings within thirty days.
A blockchain security audit conducted to a recognised standard is a minimum expectation for any vendor operating smart contracts that interact with your protocol. The absence of a recent audit from a credible firm should be treated as a significant risk indicator.
On-Site or Technical Review
For the highest-risk Tier 1 relationships, particularly custody providers and key management infrastructure suppliers, a technical review beyond the questionnaire is warranted. This may include review of architecture documentation, key ceremony procedures, and security certifications. Where contractually possible, a right-to-audit clause allows your organisation to conduct or commission an independent assessment of the vendor's security controls.
Continuous Monitoring
Point-in-time due diligence answers the question: was this vendor adequately secure when we onboarded them? Continuous monitoring answers the more relevant question: are they adequately secure now?
Vendor security posture changes. Key personnel leave and take institutional knowledge with them. Funding constraints lead to deferred security investment. Rapid growth outpaces security team capacity. An acquisition changes the ownership, culture, and security practices of a vendor overnight. None of these changes will be reflected in a questionnaire completed at onboarding two years ago.
Continuous monitoring for vendor risk in Web3 includes:
- On-chain monitoring: Automated tracking of vendor-operated smart contracts and wallets for anomalous behaviour, unusual upgrade proposals, or signs of compromise
- Security news and disclosure monitoring: Systematic review of disclosed vulnerabilities, incidents, and audit findings related to vendors and their technology stack
- Dark web and threat intelligence monitoring: Credential exposure, data breach disclosures, and threat actor targeting intelligence relevant to your vendors
- Periodic re-assessment: Scheduled questionnaire updates and documentation reviews on a risk-tiered frequency
- Incident-triggered reviews: Immediate assessment following any significant security incident at a vendor, even if that incident does not appear to directly affect your organisation
A zero-trust approach to vendor access complements continuous monitoring. Rather than relying solely on periodic assessments to confirm vendor trustworthiness, a zero-trust security architecture applies continuous verification and least-privilege access principles to all vendor interactions, limiting the blast radius of any single vendor compromise.
Contractual Controls
Vendor risk management is not only a technical discipline. Contractual controls are a critical layer of the programme, providing legal enforceability around security expectations and creating obligations that due diligence alone cannot establish.
Security Requirements and SLAs
Vendor contracts for Tier 1 and Tier 2 suppliers should include explicit security requirements: minimum standards for key management, multi-factor authentication, audit frequency, and personnel screening. Service level agreements should address availability, incident response time commitments, and the consequences of failure to meet these standards.
Breach Notification Requirements
The contract must specify the vendor's obligation to notify your organisation in the event of a security incident that may affect your operations, the notification timeline (DORA requires that financial entities ensure their ICT third-party service providers notify them without undue delay), and the minimum content of that notification. Vendors that make this notification commitment explicitly in contract are significantly more likely to follow through under the pressure of an incident.
Right-to-Audit Clauses
A right-to-audit clause gives your organisation the contractual right to conduct, or commission, a security assessment of the vendor's systems and controls. In practice, large vendors rarely grant unrestricted audit rights: the more common implementation is a right to request a copy of recent third-party audit reports, or to participate in a joint assessment process. For critical vendors, some form of audit right should be a non-negotiable contract term.
Subcontracting and Supply Chain Controls
Contracts should require vendors to flow security requirements down to their own sub-processors and material subcontractors, and to notify you of material changes to their own supply chain. This mirrors the approach taken in DORA and in supply chain security frameworks more broadly.
Exit and Transition Provisions
Clear exit provisions ensure that when a vendor relationship ends, whether due to performance failure, security concerns, or commercial reasons, your data and access is returned or destroyed, credentials are revoked, and the transition does not create a security gap. For key management vendors, exit provisions must address the migration of cryptographic key material in a secure and auditable manner.
Regulatory Requirements
The regulatory landscape for third-party risk management in crypto is maturing rapidly, and compliance obligations are now a significant driver of vendor risk programme investment for regulated entities.
DORA: ICT Third-Party Risk Management
DORA Chapter V establishes a comprehensive framework for ICT third-party risk management applicable to all financial entities in the EU, including crypto-asset service providers subject to MiCA. Key requirements include:
- Maintenance of an up-to-date register of all ICT third-party service provider arrangements
- Pre-contract due diligence assessing the security, operational resilience, and compliance of potential providers
- Mandatory contractual provisions including security requirements, audit rights, business continuity obligations, and incident notification commitments
- Concentration risk assessment: identifying where dependence on a single provider or a small number of providers creates systemic risk
- Ongoing monitoring and periodic re-assessment of ICT third-party risk
- Exit strategies for all critical ICT third-party service provider relationships
Our detailed coverage of DORA compliance for crypto firms covers the full scope of these obligations. For entities subject to DORA, the vendor risk management programme is not optional infrastructure: it is a condition of authorisation.
MiCA: Third-Party Service Requirements
MiCA Article 30 requires that crypto-asset service providers ensure third parties used for the safeguarding of client assets meet appropriate standards of security, operational resilience, and regulatory compliance. CASPs cannot outsource their regulatory obligations: responsibility for the adequacy of vendor controls remains with the CASP regardless of what the vendor contract says.
MiCA's outsourcing rules also require that CASPs maintain the ability to provide services to clients even in the event of a critical vendor failure, which in practice requires documented contingency arrangements and regularly tested business continuity plans for all critical vendor dependencies.
VARA and Other Frameworks
VARA's technology and operational standards in Dubai, and equivalent frameworks in Singapore (MAS TRM Guidelines) and the UK (FCA operational resilience rules), impose analogous requirements around third-party risk. While the specific requirements vary by jurisdiction, the common thread is clear: regulators now expect crypto firms to treat vendor security as part of their own security posture, not as something that can be delegated to the vendor's own assurance processes.
For firms operating across multiple jurisdictions, the vendor risk management programme should be designed to satisfy the strictest applicable standard, then demonstrated to each regulator with jurisdiction-specific mapping of how the programme meets their requirements.
Building the Programme
Implementing a vendor risk management programme that meets both operational security and regulatory requirements requires the same People, Process, Technology structure as any other security function.
On the People dimension: a named owner for the vendor risk function, clear accountability for due diligence and monitoring tasks, and the analytical capability to assess vendor security documentation and make risk-based decisions.
On the Process dimension: defined onboarding procedures by vendor tier, a questionnaire library appropriate to the crypto context, periodic reassessment schedules, an escalation process for high-risk findings, and documented exit procedures.
On the Technology dimension: a vendor inventory register, ideally integrated with contract management, on-chain monitoring tools for vendors operating smart contracts, and threat intelligence feeds that surface vendor-relevant security disclosures.
Privileged access management is a foundational dependency: before you can assess what access your vendors have, you need visibility into all the access rights that exist. A well-implemented privileged access management programme provides that baseline inventory and ensures that vendor access is granted on a least-privilege basis and revocable at any time.
The scale of investment required is proportionate to the scale of the protocol and the complexity of its vendor relationships. A protocol managing $10 million in total value locked needs a materially lighter programme than one managing $1 billion. But the basic discipline of knowing who your vendors are, what access they have, and whether their security practices are adequate is not a scale-dependent requirement. It is the minimum standard for any protocol that holds user funds.
Frequently Asked Questions
What is vendor risk management in the context of Web3?
Vendor risk management in Web3 is the systematic process of identifying, assessing, and continuously monitoring the security posture of all third parties that have access to your protocol, infrastructure, or key management processes. This includes oracle providers, bridge operators, infrastructure providers, custody partners, development tool suppliers, node operators, and audit firms. Because Web3 protocols are composable and interdependent by design, a vulnerability in any of these third parties can be leveraged to attack the primary protocol.
How does Lazarus Group use third-party vendors to attack crypto firms?
Lazarus Group has consistently used third-party compromise as a pivot point to reach primary targets. In the Bybit hack, the attack chain involved compromising Safe infrastructure used by Bybit to manage its multisig wallets. In other campaigns, the group has targeted developer tooling suppliers, inserting malicious code into legitimate software packages that are then downloaded and executed by developers at the target firm. This supply chain attack model means that even a protocol with robust internal security can be compromised through its vendors.
What should a vendor security questionnaire for a crypto firm cover?
A vendor security questionnaire for a crypto context should cover: key management practices and HSM usage; multi-factor authentication and privileged access controls; smart contract audit history and remediation records; incident response capability and historical incident disclosure; employee background screening and insider threat controls; third-party and sub-processor inventory; data handling and encryption standards; regulatory certifications and compliance status; and business continuity and disaster recovery procedures. For Tier 1 vendors with direct access to funds or infrastructure, the questionnaire should be supplemented by a technical review of available documentation and, where contractually possible, a right-to-audit clause.
What do MiCA and DORA require for third-party vendor management?
MiCA Article 30 requires crypto-asset service providers to ensure that third-party service providers used for safeguarding client assets meet appropriate standards. DORA Chapter V establishes a comprehensive ICT third-party risk management framework including mandatory contractual provisions, concentration risk assessment, and regulatory oversight of critical third-party providers. Both frameworks require ongoing monitoring, not just initial due diligence, and place responsibility on the regulated firm rather than the vendor for ensuring third-party controls are adequate.
How often should vendor risk assessments be repeated?
Tier 1 vendors with direct access to funds, infrastructure, or key management should be assessed annually at minimum, with continuous monitoring in between using automated tooling where available. Tier 2 vendors should be assessed every eighteen to twenty-four months and whenever there is a material change to the scope of their engagement. All vendors should be re-assessed following any significant security incident in the wider industry, particularly if the incident involved a vendor of a similar type to those in your own supply chain. Point-in-time assessments alone are insufficient: the threat landscape and vendor security posture can change rapidly.