NYDFS Third-Party Service Provider Rules for Crypto Vendors
Quick answer. Section 500.11 requires written, risk-based vendor policies covering risk assessment, minimum security practices, due diligence and periodic review, plus guidelines on MFA, encryption, incident notice and warranties. DFS's October 21, 2025 guidance adds best practices, not new obligations.
Video transcript
NYDFS says you cannot delegate responsibility to a vendor. For crypto firms, that matters most for vendors that hold keys or reach signing systems.
Section 500.11 requires written, risk-based vendor policies: risk-assessing vendors, minimum security practices, due diligence, and periodic review. Contracts should address MFA, encryption, incident notice and warranties.
DFS's October 2025 guidance adds best practices, not new obligations. It never mentions crypto, so the crypto steps here are Guardian's additions.
If a vendor is breached, you notify DFS within 72 hours, even if the vendor notifies DFS too.
DFS says to tier vendors by access and criticality. For crypto, Guardian ranks custodians, wallet platforms, SOC providers and managed IT highest.
For crypto, contracts should also require MFA on every path to signing, encrypted key shares, key compromise notice within hours, and exit to addresses you control.
At exit, move assets to addresses you control and confirm onchain. Remove its key shares and signers, rotate withdrawal API keys, and get written certification that key material is destroyed.
Vendors selling to DFS-regulated firms should have a scoped SOC 2 or ISO 27001 report, a recent pentest summary, incident notice terms in hours, and for custodians, key ceremony records.
Read the full article, and confirm with counsel. Then talk to Guardian about a technical review of the vendors you depend on most.
On October 21, 2025, DFS issued an industry letter to every entity it regulates: "Guidance on Managing Risks Related to Third-Party Service Providers".
The letter "does not impose new requirements or obligations". It explains section 500.11 of Part 500 and the practices DFS wants to see, from selection to exit.
DFS says its examinations show a need for "more robust due diligence, contractual provisions, monitoring and oversight", and it weighs weak vendor oversight in examinations and enforcement.
The letter never mentions crypto. The crypto steps below, for vendors that hold keys or reach signing systems, are Guardian's additions.
This article explains the technical and security side of 23 NYCRR 500.11 and DFS's October 2025 third-party guidance. It is not legal advice; confirm how it applies to you with counsel.
What 500.11 Requires
A third-party service provider (TPSP) is a non-affiliate, non-government person that serves the covered entity and maintains, processes or can access its nonpublic information (500.1(s)).
Section 500.11(a) says each covered entity "shall implement written policies and procedures" to secure systems and data that TPSPs can reach. They rest on the risk assessment and cover four areas, where applicable.
- Identifying and risk-assessing TPSPs.
- Minimum cybersecurity practices a TPSP must meet to do business with you.
- Due diligence on the adequacy of those practices.
- Periodic assessment, based on risk and continued adequacy.
Section 500.11(b) adds guidelines for due diligence or contract terms, where applicable, on four topics.
- Access controls, including multi-factor authentication under 500.12.
- Encryption in transit and at rest under 500.15.
- Notice of a cybersecurity event that directly affects your systems, or your data the TPSP holds.
- Representations and warranties on the TPSP's security policies.
Other provisions that reach vendors
- Small firms. The 500.19(a) limited exemption does not list 500.11.
- Incidents. You notify DFS within 72 hours of an incident at a TPSP (500.17(a)).
- Outsourced CISO. If a TPSP employs your CISO, you keep responsibility and name a senior overseer (500.4(a)).
- Cloud. Third-party systems that store, process or transmit your nonpublic information remain your information systems, DFS's FAQ says.
DFS's FAQ cites failing to implement these procedures as an example of material noncompliance, which calls for an acknowledgment, not a certification.
The October 2025 Guidance
Covered entities "may not delegate responsibility" for compliance to a TPSP, the letter repeats.
DFS also flags a trend: firms outsourcing "critical cybersecurity compliance obligations" without senior oversight and verification.
Our advice for a crypto firm: check the outsourced CISO, SOC and pentest providers first.
Tier by access
DFS says to classify TPSPs by "system access, data sensitivity, location, and how critical the service" is.
DFS's high-access examples include IT managed services and outsourced help desks. Guardian's list for a crypto firm:
| Vendor | Why it ranks high |
|---|---|
| Custodian or sub-custodian | Controls the keys to client assets |
| MPC or wallet platform | Signs transactions, or holds key shares |
| MDR or SOC provider | Privileged access to logs and endpoints |
| Managed IT and help desk | Can reset credentials and MFA |
| Pentest firm | Temporary access; holds your open findings |
| KYC and analytics providers | Hold customer identity data |
Whether each is a TPSP turns on access to nonpublic information. Score the rest, such as RPC providers, in your risk assessment.
Due Diligence and Contracts
DFS's list of due diligence considerations is "non-exhaustive". Covered entities should assess:
- Access to your systems and data, and how the vendor controls, segments and encrypts it.
- Reputation, cybersecurity history and financial stability.
- A security program meeting your requirements and Part 500.
- Criticality, and whether alternatives exist.
- Unique, traceable accounts, and audit trails meeting 500.6.
- High-risk jurisdictions, and its own vendors ("fourth parties").
- Tested incident response and continuity plans, and external audits such as ISO/IEC 27000 series.
A questionnaire helps, DFS says, but "qualified personnel" must interpret the answers. For custodians, add key management: our vendor due diligence questionnaire has the questions.
Where vendor options are limited, DFS says to document the risk, add compensating controls and regularly look for viable alternatives.
Contract terms
| Term | DFS basis | Guardian's crypto addition |
|---|---|---|
| Access controls | 500.11(b)(1); 500.7 and 500.12 | MFA on every path to signing and withdrawals |
| Encryption | 500.11(b)(2); 500.15 | Key shares and backups encrypted at rest |
| Event notice | 500.11(b)(3) | Key compromise or unauthorized transfer, in hours |
| Representations | 500.11(b)(4) | Cover signing infrastructure and key ceremonies |
| Data location | Recommended, not required | Where key shares and HSMs sit |
| Subcontractors | Recommended, not required | Right to reject a new sub-custodian |
| Exit | Data use and exit obligations | Assets sent to addresses you control |
DFS also suggests an AI clause on whether your data can train models. It says agreements should include remedies, such as remediation or early termination, for material security breaches.
Short on leverage? DFS says to still seek breach notice and access assurances, and SOC 2 or ISO 27001 reports.
Sub-custody at licensed custodians
For BitLicensees and limited purpose trust companies, a new sub-custody arrangement is a material change needing DFS's prior approval, under its September 30, 2025 custody guidance.
The agreement should commit the sub-custodian to DFS standards, "F/B/O" account titling and segregation, and bar using customer assets as collateral. See our BitLicense requirements guide.
Ongoing Oversight
Section 500.11(a)(4) requires periodic assessment based on each vendor's risk. DFS says these assessments may consider:
- Security attestations, such as SOC 2 or ISO 27001.
- Penetration testing summaries.
- Policy updates, training evidence and compliance audits.
Firms should also ask for vulnerability management updates and confirm old findings were fixed. Unresolved risk goes into the risk assessment.
DFS says firms should assess how they would rapidly switch providers in a disruption, and consider testing response plans with vendors.
Our addition: between reviews, watch the chain for a vendor's signer changes, outflows from its known addresses and incidents at shared dependencies. Our third-party risk playbook covers them.
Termination
When a relationship ends, firms must disable the vendor's access (500.7(a)(4)). For cloud vendors, DFS says to revoke SSO, OAuth tokens, API integrations and external storage access.
For a crypto vendor, Guardian adds four steps.
- Move assets to addresses you control, and confirm balances onchain.
- Remove the vendor's key shares, signers and policy approvers.
- Rotate API keys that can start withdrawals, and prune address allowlists.
- Get written certification that your data and key material are destroyed.
Evidence Vendors Should Provide
Selling custody, wallet or security services to a DFS-regulated firm? Guardian's list of what to have ready:
- A SOC 2 report or ISO 27001 certificate whose scope covers the service you sell.
- A recent pentest summary, with retest results.
- MFA and encryption policies, mapped to 500.12 and 500.15.
- Incident notice terms in hours, and your subcontractors and data locations.
- Incident response and continuity test records.
- For custodians: key ceremony records, a dated recovery test and segregation evidence.
A vendor that is also a covered entity must meet Part 500 as a covered entity, DFS's FAQ says.
How Guardian Helps
Guardian's institutional advisory reviews the custodians, bridges, oracles and protocols you would depend on, as concentrations of risk rather than logos on a slide.
Its regulatory compliance work covers your third-party register, the contract terms regulators require, concentration risk and an exit plan tested against the vendor you depend on most.
Frequently Asked Questions
Does NYDFS 500.11 apply to small covered entities?
The 500.19(a) limited exemption for smaller covered entities does not list section 500.11. DFS says its October 2025 guidance is meant for covered entities of all sizes.
Is a crypto custodian a third-party service provider under Part 500?
Part 500 defines a TPSP as a non-affiliate, non-government person that provides services and maintains, processes or can access the covered entity's nonpublic information. Apply that test to each custodian, and confirm the result with counsel.
Does DFS's October 2025 guidance create new obligations?
No. DFS says it "does not impose new requirements or obligations". It clarifies 500.11 and recommends practices, some of which, such as subcontractor terms, DFS says Part 500 does not require.
Who notifies DFS when a vendor is breached?
The covered entity, within 72 hours of determining that a cybersecurity incident occurred, including one at a TPSP (500.17(a)). DFS's FAQ says this applies even if the vendor also notifies DFS.
Sources
- NYDFS: Industry Letter, Guidance on Managing Risks Related to Third-Party Service Providers (October 21, 2025)
- Cornell LII: 23 NYCRR 500.11, Third-party service provider security policy (amended effective November 1, 2023)
- Cornell LII: 23 NYCRR 500.1, Definitions (amended effective November 1, 2023)
- Cornell LII: 23 NYCRR 500.4, Cybersecurity governance
- Cornell LII: 23 NYCRR 500.17, Notices to superintendent
- Cornell LII: 23 NYCRR 500.19, Exemptions
- NYDFS: Cybersecurity Regulation FAQs (read November 6, 2026)
- NYDFS: Industry Letter, Updated Guidance on Custodial Structures for Customer Protection in the Event of Insolvency (September 30, 2025)
- Guardian: Digital Asset Vendor Due Diligence Questionnaire (Template)
- Guardian: Third-Party Risk Management for Crypto: A Bank Playbook
- Guardian: NYDFS BitLicense Requirements: Cybersecurity and Custody
- Guardian: Institutional
- Guardian: Regulatory and Compliance Assessments
Put your crypto vendors through a technical review
Guardian reviews the custodians, wallet platforms and protocols you rely on, and turns the findings into evidence your 500.11 program can use.