DORA Third-Party Risk by Onchain Provider Type: Register, Contract and Exit Compared
DORA third-party risk management is the set of EU duties, applying since 17 January 2025, under which a bank, crypto-asset service provider (CASP) or e-money institution registers and contracts with each ICT provider it uses, with tested exit plans for those behind critical or important functions. No supervisor has said whether four of the nine onchain provider types compared here (public chains, non-custodial validators, RPC and oracles) are ICT providers. The guide asks three questions of each type: is it an ICT service, does it support a critical or important function, and which Article 30 clauses must its contract hold?
Reviewed by Luis Medeiros, Field CTO at Protofire · Updated October 2026
Most onchain vendors a regulated firm pays for an ongoing service are ICT third-party service providers under DORA Articles 3(19) and 3(21). Each needs a register entry with an LEI or EUID and a written contract holding the nine Article 30(2) clauses, plus the six of Article 30(3) where it supports a critical or important function. Regulated custodians and e-money token (EMT) issuers usually fall outside as financial services; a public blockchain has no one to sign with. Custody technology, engineering firms and KYT or Travel Rule vendors take the most work; RPC has the easiest exit. No Q&A says how DORA treats crypto custodians, validators, RPC, oracles or public chains (Q&A 2067 covers custodial staking, under MiCA). Those answers and the ranking are our reading.
Three of the nine provider types on this page describe work Protofire sells: smart contract engineering, RPC and node provision, and validator operation. The service this page links to, the managed operation of live contracts, falls under the engineering-firm type. That gives us an interest in how these rules are read. Protofire holds no financial-services license, and nothing here is legal advice. Rules are quoted from EUR-Lex, the European Supervisory Authorities (ESAs), the Commission and national supervisors as read on 18 October 2026. A classification no supervisor has made is marked "our reading" once each in the scorecard, its type's section and its FAQ answer, not in the bullets or verdicts that repeat it. Critical-function ratings and exit rankings are our judgement too, since no official list of critical functions exists. The scorecard's "Official answer" row shows which types have a published answer. Multisig, MPC and qualified-custodian models are compared in our crypto custody guide, and the rest of the series is in our decision guides.
What does DORA ask of the nine provider types?
9 options side by side: scroll the table sideways to see all of them.
Where does each provider type land: ICT service, financial service or dependency?
Custody technology
- +The classification rests on rule text (Article 3(21) and Recital 63), so the register entry needs no scope argument of the firm's own
- +Bought as a license run on premises (S13), the key shares, HSMs and signing nodes can sit in the firm's own data centers, so the firm sets the locations Article 30(2)(b) asks the contract to name
- +Where the vendor lets key material be re-shared or exported to another vendor, exit becomes a key ceremony with no onchain move of client assets
- −For a critical service, as key custody likely is for a custodian, the contract has to give the supervisor on-site access to the vendor (Article 30(3)(e)), and over time the firm may not rely on certifications alone (RTS 2024/1773 Article 8(3))
- −Bought as SaaS or hardware as a service, key shares, HSMs and signing nodes sit in regions or countries that the contract must name, with advance notice of any move (Article 30(2)(b))
- −Without key export, the tested exit plan has to move every client asset onchain to addresses under a new key scheme
- −A CASP's supervisor may ask about the vendor: ESMA's custody review, run by national supervisors on a risk-based sample of authorized CASPs to the first half of 2027, covers key and storage management and dependencies on third-party providers
Custody technology is the multi-party computation (MPC), hardware security module (HSM) or wallet-infrastructure software on which a bank or custodian CASP holds its clients' keys, bought as SaaS, as a license run on premises or as hardware as a service. DORA's Article 3(21) defines ICT services as "digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis", hardware as a service included, and Recital 63 names software providers among the ICT third-party providers it covers. Its register types sit in the closed list of Annex III of Implementing Regulation (EU) 2024/2956.
Neither exception reaches custody technology. The vendor sells software and does not provide the custody service, so the Commission's two-step test in Q&A DORA030, which takes regulated financial services out of the ICT definition, does not apply to it. Nor does the one-off exception: the ESAs' staff register FAQ says a one-time purchase "without ongoing maintenance, support, or updates is not considered", and custody software is normally sold with all three.
For a custodian, key custody is the licensed activity itself. Under MiCA Article 75 the custodian is liable to clients for losses attributable to it. A failure of the key system would therefore impair both its service and its compliance, which would meet the Article 3(22) test for a critical or important function. ESMA's supervisory briefing on CASP authorization lists key management among the "highly important" functions whose outsourcing requires special scrutiny, and the common supervisory action ESMA launched on 8 July 2026 covers "key and storage management" and "dependencies on third-party providers" in CASP custody.
For custody technology the weight falls on four Article 30 clauses: 30(2)(b), where key shares, HSMs and signing nodes sit, with advance notice of any move; 30(2)(d), access to and return of data if the vendor fails; 30(3)(e), audit and on-site access for the firm and its supervisor; and 30(3)(f), a transition period on exit. Article 28(8) requires a tested exit plan that lets the firm "securely and integrally transfer" the service and its data to another provider or back in-house. For keys, that plan should say whether key material can be re-shared or exported to a new vendor. The register's B_07.01 template asks whether an exit plan exists and scores substitutability from "Easily substitutable" to "Not substitutable".
Regulated custodian or EMT issuer
- +The vendors under the custodian or issuer are its own DORA duty and normally stay out of the buyer's register (Q&A 2024_7089)
- +MiCA already sets the sub-custody terms: authorized sub-custodians only, clients told, and a written agreement the CASP can terminate
- −Each ICT product the custodian or issuer sells on its own, such as a standalone API or tokenization software, needs its own register row and Article 30 terms
- −Outsourced custody leaves the CASP fully responsible, with a contingency plan and exit strategy of its own (MiCA Article 73)
- −Issuer, redemption and liquidity risk on an EMT sit outside DORA's Chapter V and need controls of their own
- −A stablecoin that is not MiCA-compliant has to be dropped, in ESMA's view: its opinion of 8 October 2026 expects CASPs to cease services in such tokens
This option covers two regulated counterparties. A custodian here is a MiCA-authorized crypto custodian, or a bank, holding crypto-assets for another firm as sub-custodian. An EMT issuer is the credit institution or e-money institution behind an e-money token, since MiCA Article 48(1)(a) requires the issuer to be authorized as one or the other. Both deliver a regulated financial service that runs on ICT. For that case the Commission's answer to Q&A DORA030 sets two tests: whether the service is an ICT service, and whether the provider and its service are regulated under EU, national or third-country law. It then says: "In case both tests are positive, then the related ICT service should be considered to predominantly be a financial service and should not be treated as an ICT service within the meaning of DORA Article 3(21)." Q&A 2024_7290 draws a similar line for payment-infrastructure operators, whose services "without a prevailing ICT component, such as clearing and settlement" are not ICT services.
No Q&A applies DORA030 to crypto: the one DORA question in EIOPA's Q&A database that mentions crypto at all, on "crypto digital wallets", DORA214, was rejected "because it is already answered in Q&A DORA030". In our reading, custody by an authorized custodian and an issued EMT pass both tests, so neither normally needs an ICT row in the register. The same DORA030 answer treats a service "unrelated or is independent from such regulated financial services" as an ICT service, which covers a custodian's standalone API platform or tokenization software an issuer sells on its own.
MiCA governs the regulated relationship. MiCA Article 75(9) allows only sub-custodians "authorised in accordance with Article 59", and ESMA's April 2026 statement says MiCA "specifically prohibits CASPs from outsourcing or delegating" custody to entities not authorized as CASPs. MiCA Article 73 keeps an outsourcing CASP "fully responsible", with an outsourcing policy "including on contingency plans and exit strategies".
Neither counterparty can be designated a critical ICT third-party provider, because Article 31(8) excludes financial entities that provide ICT services to other financial entities. Each is a DORA financial entity itself under Article 2(1), with its own register and Article 30 contracts for the vendors under it. Q&A 2024_7089 says ICT subcontractors of a provider that supplies no ICT service remain "outside the scope of the register of information", unless the buyer's risk assessment treats them as equivalent to a direct ICT service for a critical function, so the custodian's or issuer's own vendors normally stay out of the buyer's register. For stablecoins, ESMA has added a hard stop under MiCA: announcing its opinion of 8 October 2026, it said CASPs "should cease providing services related to non-MiCA-compliant stablecoins".
Staking or validator operator
- +The buyer picks the regime: with the assets and withdrawal control in-house the operator is an ICT vendor, and with the assets or their keys at the operator Q&A 2067 makes staking ancillary to custody, which needs MiCA custody authorization
- +Uptime, missed duties and slashing give Article 30(3)(a) its quantitative service levels
- +Missed duties and slashing show up in chain data, so the firm can check service levels without relying on the operator's own reports
- −For a non-custodial operator the firm writes its own scope reasoning, since no supervisor answer covers one
- −Staking offered to clients likely makes the operator critical, because Q&A 2067 deems staking losses attributable to the CASP, so the operator has to accept audit and on-site access by the firm and its supervisor
- −The exit plan has to say who controls withdrawal credentials and how double signing is avoided while keys move, and any assets that are unstaked wait in unbonding or exit queues first
A staking or validator operator runs validator nodes and signing infrastructure for a bank or CASP that stakes its own or its clients' crypto-assets. MiCA has no staking provisions of its own. ESMA's Q&A 2067, answered by the Commission, says that where the provider holds the crypto-assets or the keys, "the provision of staking services is ancillary to custody services", which requires MiCA custody authorization, and that losses from staking "should be deemed as attributable to the CASP".
No ESAs Q&A mentions validators, so what follows is our reading. In the custodial model the operator provides a regulated service, and the DORA030 test points to a financial service. In the non-custodial model the operator runs validators and remote signers while the buyer keeps the assets and the withdrawal control. That service is digital, delivered through ICT systems on an ongoing basis, so it meets Article 3(21) and fits the register types S14, ICT operation management "Including Managed Service Providers (MSP)", or S07 hosting. It likely supports a critical function where the firm offers staking to clients, since client losses fall on the firm under Q&A 2067; for staking from the firm's own treasury, the answer depends on the amounts involved.
The Article 30 clauses that do most work here are 30(3)(a), with quantitative service levels on uptime, missed duties and slashing protection; 30(2)(f), assistance during incidents; and 30(3)(b), notice of developments such as client-software bugs or protocol upgrades. ESMA's response to the MiCA review of 30 September 2026 proposes staking disclosures on "lock-up and unbonding periods, slashing risk, validator selection" and "operational dependencies", and flags added risk "where key staking functions rely on third-country infrastructure or entities"; none of these proposals is law yet.
RPC or node provider
- +One design covers resilience and exit: a second provider as live failover, or the firm's own nodes, which the register counts as reintegration
- +Standard interfaces keep a switch to another provider short, which supports an easy substitutability score in the register's exit template
- −The firm's own documented assessment carries the classification, with no supervisor guidance on scope
- −Wiring deposit crediting, balances or withdrawals to the feed likely makes it critical, since 'supporting' means the service is 'necessary for the delivery' of the function
- −Wrong or stale data is the main failure, so the integrity and authenticity terms of Article 30(2)(c) carry the most weight
- −Often runs on hyperscale cloud, which the firm then records as a subcontractor when it underpins a critical service
An RPC or node provider gives a bank or CASP API access to blockchain data and broadcasts its transactions, from shared endpoints or dedicated nodes. No ESAs, EBA or EIOPA Q&A addresses node or RPC services. In our reading they are still "digital and data services provided through ICT systems ... on an ongoing basis" under Article 3(21). Recital 35 says that definition "should be understood in a broad manner", so this guide treats them as ICT services.
"Supporting" a critical or important function means the ICT service "is necessary for the delivery" of it, with no threshold on how much it is used, according to the Commission's answer to Q&A DORA006. A node feed that credits client deposits, shows balances or submits withdrawals meets that bar for a CASP or bank; one used only for analytics or testing does not.
For critical use, the contract adds 30(3)(a) targets on latency and availability to the full Article 30(2) set. The register's B_07.01 template calls a move to the firm's own nodes reintegration and scores it "Easy", "Difficult" or "Highly complex" (Implementing Regulation (EU) 2024/2956). A critical service still needs a documented exit plan that is tested and reviewed under Article 28(8).
Oracle network
- +A contracted feed gives the firm a counterparty to hold to integrity, update-frequency and deviation terms (Articles 30(2)(c) and 30(3)(a))
- +The firm can model that contract on its market-data contracts, since data provision is already register type S05
- +A decentralized feed adds no register row, contract or vendor audit; the work becomes the firm's own mapping under Article 8 and its own testing
- −With a decentralized feed, no counterparty owes the firm incident help, data return or audit access, so those controls stay with the firm
- −A feed that values collateral, triggers liquidations or sets NAV or redemption prices likely supports a critical function, so its failure needs a fallback source in the continuity plan
- −Switching feeds needs the admin or governance rights to repoint onchain contracts, then testing, so the exit plan should name who holds those rights
An oracle delivers offchain or cross-chain data, most often prices, to smart contracts and to the firm's own systems. No ESAs Q&A addresses oracles, so the split below between contracted and decentralized feeds is our reading. A data company or oracle operator that delivers feeds under contract supplies an ICT service, register type S05 "Provision of data". Market data is already treated that way, since Bloomberg and LSEG Data and Risk are among the ESAs' designated critical providers. A decentralized oracle network that the firm reads onchain, with no contract, offers no "undertaking providing ICT services" to sign with (Article 3(19)) and no "contractual arrangement" for the register under Article 28(3). It therefore cannot be recorded as an ICT third-party provider.
The decentralized feed is still an ICT dependency. Article 8 asks firms to document their ICT assets "and their roles and dependencies", map the "links and interdependencies" between them and identify "all processes that are dependent on ICT third-party service providers". Either way, an oracle that values collateral, triggers liquidations, or sets NAV or redemption prices likely supports a critical or important function.
For a contracted feed, the clauses that carry weight are 30(2)(c) on data integrity and 30(3)(a) service levels on update frequency and deviation. The node operators behind a feed raise an open question: the register expects subcontractors that "effectively underpin" a critical service to "use a valid and active LEI or provide their EUID" (Implementing Regulation 2024/2956 Article 3(6)), and no guidance says what a firm records where those operators are pseudonymous.
Analytics, KYT or Travel Rule vendor
- +Usually a standard SaaS contract, so the Article 30 clauses are a familiar negotiation
- +Exit involves no onchain step: it is a migration of data, cases and connections
- −For a CASP, an outage of screening or Travel Rule messaging would impair its AML and Travel Rule compliance, which likely makes the service critical
- −Travel Rule messages carry personal data, so the contract turns on data location, protection and return clauses
- −Exit means exporting screening history, cases and alerts, re-screening clients and rebuilding Travel Rule connections with counterparty CASPs
Blockchain analytics, KYT (know-your-transaction) and Travel Rule vendors screen addresses and transactions for sanctions and illicit-finance risk, and pass the originator and beneficiary information that the Transfer of Funds Regulation requires on crypto transfers. DORA's Recital 63 lists providers of "data analytics services" among the ICT providers it covers, and the register types are S19 SaaS, S06 data analysis or S05 provision of data. The Travel Rule networks and vendors themselves, and how they differ on reach, hosting and wallet checks, are set side by side in meeting the EU Travel Rule.
For a CASP, a failure of screening or Travel Rule messaging would "materially impair the continuing compliance" of the firm with its "other obligations under applicable financial services law". That is the second limb of the Article 3(22) test, so the service likely supports a critical or important function. ESMA's supervisory briefing lists compliance among the "highly important" functions whose outsourcing requires special scrutiny, and tells supervisors to "take careful note of outsourcing that may be precluded in light of AML rules".
Because Travel Rule messages hold personal data, three data clauses matter most: 30(2)(b) on where data is stored and processed, 30(2)(c) on protecting personal data and 30(2)(d) on returning it. The register records how sensitive the data is in its B_02.02 template, alongside the countries of storage and processing.
Smart contract engineering firm
- +The scope of the engagement sets the DORA load: a build with no support afterwards likely stays out of the register, while upgrades, monitoring or key operations bring it in
- +If the firm fails or the engagement ends, the deployed contracts keep running onchain; upgrades, monitoring and any keepers the firm runs are what stop
- −No supervisor has drawn the line between a one-off build and an ongoing service for smart contracts, so the firm records its reasoning for each engagement
- −Contracts that are the system of record for a deposit token, EMT or fund unit likely make the work critical, with the full Article 30(3) set
- −Admin rights, multisig seats and automation keys the firm still holds keep working onchain after the contract ends, so the contract has to require their handover
- −Work on live production systems may fall inside the client's threat-led penetration test, which the contract must oblige the firm to join (Article 30(3)(d))
A smart contract engineering firm designs, writes, tests and deploys the contracts behind a token, vault or payment flow, and may keep upgrading, monitoring or operating them after launch. Whether DORA applies turns on the words "on an ongoing basis" in Article 3(21). The ESAs' staff register FAQ of 28 March 2025 leaves out a one-time purchase "without ongoing maintenance, support, or updates", while noting that its answers do not represent legal interpretation. Upgrades, monitoring, admin-key operations, keepers or relayers and incident response are ongoing, and Annex III types S02 ICT development, S14 ICT operation management and S15 ICT consulting cover them. Where the line falls for a given engagement is our reading.
Where the contracts are the system of record for a deposit token, an EMT or a fund unit, holding the mint, burn, transfer and redemption rules, the work likely supports a critical or important function. For internal tooling it usually does not. Due diligence then follows Delegated Regulation (EU) 2024/1773 Article 6, which asks whether the provider has "the business reputation, sufficient abilities, expertise and adequate financial, human and technical resources" for the service and whether it uses subcontractors. Ways to check an engineering firm's public track record are set out in our web3 development partners guide.
The exit plan under Article 28(8) should transfer proxy admin rights, multisig signer seats and automation keys, along with source code, deployment scripts and runbooks, so the firm can move to another provider or "reincorporate them in-house". A firm working on live production systems may fall inside the client's threat-led penetration test (TLPT), which DORA requires at least every three years of the firms their supervisor identifies. Article 26(3) makes the client ensure in-scope providers take part, and Article 30(3)(d) puts that duty in the contract. Delegated Regulation (EU) 2025/1190 requires a pooled TLPT to include at least one scenario on the provider's underlying systems. Sub-agencies, external auditors, RPC, CI/CD services and cloud behind the firm are, in our reading, subcontractors to list where they underpin a critical service, with the notice and objection mechanics of Delegated Regulation (EU) 2025/532.
The public blockchain
- +Nothing to register, negotiate or audit at the chain itself, so the work goes into the contracted RPC, node, validator and custody vendors that give access to it
- +For a custodian, MiCA Article 75(8) sets liability to clients for losses from incidents attributable to it, and counts 'a problem inherent in the operation of the distributed ledger' that it does not control among those that are not
- −The firm writes down its own classification and reasoning, because no ESAs, EBA, EIOPA or ESMA answer exists
- −Halts, reorganizations, forks and congestion need scenarios in the firm's own continuity and exit plans, with no vendor to share the work
- −Supervisors are looking at it: ESMA's custody review assesses 'risks inherent to distributed ledger technology'
DORA itself, Regulation (EU) 2022/2554, never uses the words blockchain, distributed ledger or DLT; its crypto references are limited to scope, definitions and the list of competent authorities. None of the 118 DORA questions in EIOPA's Q&A export, read on 18 October 2026, mentions blockchains, nodes, RPC, validators or oracles; neither do the 44 DORA questions in ESMA's Q&A tool, and a keyword search of the EBA's Single Rulebook Q&A tool on 18 October 2026 returned none either. Whether a public permissionless chain is an ICT third-party service provider therefore has no official answer.
Our reading is that it is not one. DORA defines an ICT third-party service provider as "an undertaking providing ICT services" (Article 3(19)), the register covers "contractual arrangements" (Article 28(3)), and Article 30(1) requires rights and obligations to be "set out in writing". A permissionless network has no undertaking to sign with, so there is nothing to register or negotiate. MiCA Article 75(8) is consistent with that: it counts "a problem inherent in the operation of the distributed ledger that the crypto-asset service provider does not control" among incidents not attributable to a custodian. The chain is still an ICT dependency: Article 8 asks firms to document ICT assets "and their roles and dependencies", and MiCA Article 68(7) requires a CASP's continuity policy to include ICT continuity plans set up under DORA.
ESMA's custody review, running from the second half of 2026 to the first half of 2027, focuses on "risks inherent to distributed ledger technology (DLT)" and counts "dependencies on third-party providers" among them, without saying whether the ledger itself is a provider. On that reading the network gets no register row, while each contracted ICT vendor that gives access to it, such as an RPC, node, non-custodial validator or custody-technology provider, gets one. Chain-level scenarios (halt, reorganization, fork, congestion, migration to another chain) go into continuity and exit plans. A permissioned network run by a company is different, since its operator is an undertaking that can sign an Article 30 contract.
Hyperscale cloud beneath the vendors
- +Designated clouds come with direct ESA oversight through a Lead Overseer, on top of the firm's own monitoring
- +Reseller cases have a published answer: with no direct contract, Q&A DORA 215 says to record the reseller and add the effective provider as a subcontractor
- −Usually reached through a vendor, so the firm depends on that vendor to disclose it as a subcontractor (template B_05.02) and pass on its LEI or EUID
- −Contracted directly, the terms are the hyperscaler's own, and a critical service needs an exit plan that migrates workloads and data from a provider that may not be 'easily substitutable' (Article 29)
- −Several onchain vendors on one hyperscaler means one outage can reach custody, nodes and screening at once
Cloud is the layer beneath most of the other types, since custody vendors, RPC providers, analytics firms and engineering firms often run on a hyperscaler. Recital 63 names "providers of cloud computing services" first among the ICT providers DORA covers, and the register has S17 IaaS, S18 PaaS and S19 SaaS for it. Several clouds are designated critical providers: on 18 November 2025 the ESAs (the EBA, EIOPA and ESMA) published their first designation, which names Amazon Web Services EMEA, Google Cloud EMEA, Microsoft Ireland Operations, Oracle Nederland and IBM among 19 providers. Each designated provider has a Lead Overseer: the ESA responsible for the financial entities that together hold the largest share of total assets among its users. A joint examination team drawn from the ESAs and the authorities that supervise the provider's financial-entity clients supports it, as the ESAs' non-binding guide on oversight activities of 15 July 2025 sets out.
A firm that contracts with the cloud directly gives it a register row of its own. More often the cloud sits under an onchain vendor and enters the register as a subcontractor in template B_05.02, ranked by its position in the supply chain. That applies where it is one of the subcontractors that "effectively underpin" a critical service, and the firm must then make sure, through the direct vendor, that it carries an LEI or EUID (Implementing Regulation 2024/2956 Articles 2 and 3). Where a reseller sits in between with no direct contract, the joint Q&A DORA 215 says to record the reseller's contract and add the effective provider as a subcontractor. For a direct contract, Article 30(4) asks both parties to consider standard clauses developed by public authorities.
The firm using a designated cloud still "at all times" remains fully responsible for its own compliance (Article 28(1)(a)). A designated provider must tell its financial-entity clients (Article 31(5)), and a firm may use a designated provider established outside the EU only if that provider has set up an EU subsidiary within 12 months of designation (Article 31(12)). For onchain stacks, the main cloud question is concentration: if the custody vendor, the node provider and the screening vendor all run on one hyperscaler, a single outage reaches all three. Article 29 makes ICT concentration risk part of the assessment before a firm contracts for a service that supports a critical function.
What should an onchain provider have ready for a client's third-party risk management (TPRM) review?
Rule-level items only, as of 18 October 2026, from DORA Articles 28 to 31, Implementing Regulation (EU) 2024/2956 as corrected on 19 September 2025, Delegated Regulation (EU) 2024/1773 and the joint Q&As named in each row. In the rows, the register regulation appears as an ITS (implementing technical standard) and the delegated regulations as RTS (regulatory technical standards). A provider with these ready shortens the client's pre-contract assessment under Article 28(4). The timing of incident notice is our reading; the other rows restate the rule. The register is "an internal document" meant to be kept confidential and reported to supervisors and the ESAs, who are bound by confidentiality, according to Q&A DORA149, so subcontractor details shared for it are meant to stay with the firm and its supervisors.
Which provider choices make DORA work heavier or lighter, in our reading?
the firm runs custody itself on a vendor's MPC, HSM or wallet software. Expect every Article 30(3) clause, terms on where key shares sit and the hardest exit of the nine.
the firm builds or operates the contracts that hold a token's mint, burn and transfer rules. Proxy admin rights, multisig seats, source code and deployment scripts must be transferable, and the live contracts may fall in the client's TLPT.
screening and Travel Rule messaging carry client data and the CASP's AML duties, so data location, protection and return clauses do most of the work.
you keep the assets and the withdrawal control and contract an operator for validators and remote signers: an ICT service with service levels on uptime and missed duties and an exit plan that allows for unbonding queues. An operator that holds the keys offers staking ancillary to custody under Q&A 2067 and needs MiCA custody authorization.
the network, or a decentralized oracle, has no operator to contract with. Record the reasoning, map it under Article 8 and put halts, reorganizations and forks in the continuity plan; no supervisor has ruled on the question.
several onchain vendors run on the same designated hyperscaler, which makes the Article 29 concentration check the main task. A cloud contracted directly also takes its own register row and, for critical use, its own exit plan.
you hand custody to a MiCA-authorized custodian, so both tests in the Commission's DORA030 answer come out positive and the work sits in MiCA Articles 73 and 75(9) and, for banks, the EBA's outsourcing guidelines. An EMT issuer is the same case.
the provider serves standard interfaces, so a second provider can take over or the firm can run its own nodes. The contract still needs every Article 30(2) clause and terms on data integrity.
Which other rules and reviews sit next to DORA?
- MiCA's outsourcing rule, next to DORA: a CASP that outsources "shall remain fully responsible" and needs an outsourcing policy with exit strategies under MiCA Article 73, and MiCA Article 68(7) requires its continuity plans to follow DORA. A bank that offers crypto under an Article 60 notification must show, under Delegated Regulation (EU) 2025/303, how its ICT arrangements comply with Article 73 and DORA Chapter V; the routes such a bank can take are compared in crypto-as-a-service for banks. The other MiCA and Travel Rule duties a CASP's stack carries are summarized on our page for CASPs and crypto exchanges.
- Non-ICT third parties: the EBA's final guidelines on third-party risk for non-ICT services (EBA/GL/2026/09), published on 18 September 2026 with a two-year transitional period, cover services outside DORA's Chapter V for credit institutions, payment and e-money institutions, issuers of asset-referenced tokens and some investment firms and mortgage creditors, so EMT issuers are covered as credit or e-money institutions. They apply from a date still blank in the final report, and the EBA's 2019 outsourcing guidelines stay in force until then.
- Reviews under way: ESMA's custody resilience review runs from the second half of 2026 to the first half of 2027, with a final report to ESMA's Board of Supervisors in the second half of 2027. DORA's own review under Article 58 is due by 17 January 2028 and covers the criteria for designating critical providers and the EU-subsidiary rule for third-country ones. A separate review under Article 58(3), on bringing statutory auditors into scope, drew a joint ESAs report on 17 December 2025, listed on ESMA's DORA page. The Commission's list of DORA implementing and delegated acts shows Delegated Regulation (EU) 2025/532 as the latest.
- Why third parties draw attention: financial entities reported 3,383 major ICT-related incidents in 2025, and 29% were caused by a failure attributable to a third-party provider, according to the ESAs' 2025 report on major ICT-related incidents, published in June 2026. The report calls dependencies on providers, "even those non designated as critical", an area of supervisory attention, and counts CASPs and issuers of asset-referenced tokens as the crypto sector.
- Protofire's blueprint: the automated onchain threat response blueprint fits a CASP, bank or e-money institution that holds crypto-assets on public chains and wants a defined class of threat answered in seconds by responses its management body authorized in advance, with the monitoring provider's contract under DORA Articles 28 to 30.
FAQ
What is DORA third-party risk management?
Does DORA apply to crypto-asset service providers?
Is a public blockchain an ICT third-party service provider under DORA?
Is an RPC or node provider an ICT third-party service provider under DORA?
Does DORA apply to staking providers?
How do I classify an oracle under DORA?
Is a crypto custodian or stablecoin issuer an ICT third-party service provider under DORA?
Does a one-off smart contract build count as an ICT service under DORA?
What contract clauses does DORA Article 30 require?
DORA Article 30 requires nine clauses in every ICT contract and six more where the service supports a critical or important function, all in "one written document" with the service levels. The nine cover the service, locations, data protection and return, service levels, incident help, cooperation with authorities, termination and training. The six add quantitative service levels, notice duties, tested contingency plans, threat-led testing, audit rights and an exit strategy.
Article 30(2) covers (a) a full service description and whether subcontracting is allowed, (b) service and data locations with advance notice of changes, (c) availability, authenticity, integrity and confidentiality of data, (d) access to and return of data on insolvency, resolution or termination, (e) service level descriptions, (f) incident assistance at no extra cost or a cost fixed in advance, (g) full cooperation with competent and resolution authorities, (h) termination rights and minimum notice periods, and (i) participation in security awareness and resilience training. Article 30(3) adds full quantitative service levels, notice and reporting duties, tested contingency plans and security measures, participation in threat-led penetration testing, unrestricted access, inspection and audit rights, and an exit strategy with a mandatory transition period. Delegated Regulation (EU) 2024/1773 sets the contract policy for critical services.
What should be in a vendor's DORA due-diligence pack?
Is there an official list of critical or important functions under DORA?
Does an ICT provider need an LEI for the DORA register of information?
An ICT provider established outside the EU needs an LEI (Legal Entity Identifier) for the DORA register of information. An EU provider can be identified by an LEI or by its EUID (European Unique Identifier), and both are asked for where available. Implementing Regulation (EU) 2024/2956 Article 3(5) requires "a valid and active" LEI or the EUID, and the register instructions say "Only LEI shall be used for legal persons that are not established in the Union". For critical services, the firm also ensures through the direct provider that underpinning subcontractors use an LEI or give their EUID (Article 3(6)).
The EUID is the company identifier of Article 16 of the Company Law Directive (EU) 2017/1132, and allowing it was a change the Commission asked for when it announced it would reject the first draft on 25 July 2024. LEIs come from issuers, also called Local Operating Units, that the Global Legal Entity Identifier Foundation (GLEIF) accredits. They are renewed annually and can be checked in GLEIF's search; one issuer, KDPW in Poland, lists PLN 261 net for issuance with a year's validity. Since a correction published on 19 September 2025, the type of any other code (CRN, VAT, passport or national ID number) is entered without a country prefix, as Q&A 2024_7283 had already said.
When is the DORA register of information due?
What changed in the DORA subcontracting rules?
Is any crypto firm a critical ICT third-party provider under DORA?
What are the DORA major incident reporting deadlines?
Does the Digital Omnibus change DORA?
The Digital Omnibus would change only the channel for DORA incident reports, and it had not been adopted as of 18 October 2026. The Commission's proposal COM(2025) 837 of 19 November 2025 sends major-incident reports and voluntary cyber-threat notifications through a single entry point that the same proposal sets up under the NIS2 Directive. It leaves the four-hour, 24-hour, 72-hour and one-month deadlines, the register and Article 30 as they are.
The proposal amends DORA Article 19(1) and (2), and the single entry point would be used from 18 months after entry into force (24 if the Commission delays it). The European Parliament's Legislative Train, updated on 20 September 2026, records a draft report of 22 June 2026, more than 1,750 amendments tabled, and a COREPER vote on the Council's negotiating mandate, set for 26 June 2026, that "was ultimately cancelled", with work continuing under the Irish Presidency. On EUR-Lex, DORA itself shows no amending act.
Does DORA require ISO 27001 or a certified vendor?
Our managed operation watches a live onchain product around the clock: monitoring on top of your detection tools, incident triage and containment under an authority matrix you approve in advance, and rehearsed, documented key ceremonies and upgrades. Key custody stays with you.
Managed onchain monitoring and incident response →Get a proposal
Tell us what you are building. An engineer reads it, we have a short call, and the written proposal follows within one business day.
Budget
An NDA is available from the first message and can cover anything you share. How it works