DORA Register 2026: What the 31 March Deadline Revealed

April 26, 2026 ·Mairi Kutberg ·

doraregister-of-informationict-third-partyctppfinancial-servicesidentity-chainbafinconcentration-risk

The DORA Register deadline closed three weeks ago. Only 6.5% of firms passed all 116 data quality checks in the 2024 dry-run. The gap is the identity chain.

DORA Register 2026: What the 31 March Deadline Revealed

The 31 March 2026 DORA Register of Information deadline revealed a structural data-quality gap: only 6.5% of firms passed all 116 EBA checks in the 2024 dry-run, and 2026 only marginally improved. The deeper finding is that the Register captures contractual ICT relationships, not the identity chain for privileged personnel — and that is what supervisors now ask about.

The first mandatory cycle of the DORA Register of Information closed three weeks ago. Every financial entity in scope of the Digital Operational Resilience Act had to file with its national competent authority, which in turn consolidated the submissions for the European Supervisory Authorities by 31 March 2026 (Thomas Murray — DORA Register of Information 2026 outlook). National deadlines clustered a few days earlier — the Netherlands DNB at 20 March, the Dutch AFM at 22 March, Luxembourg's CSSF opening its eDesk portal on 11 February (CSSF — DORA submission timeframe) — but the substantive exercise was unified. What that exercise surfaced, now that the dust has settled, is that the Register is not really a regulatory artefact about ICT contracts. It is a regulatory artefact about data quality and the identity chain behind it, and the large majority of in-scope entities had under-invested in both.

The 6.5% Number

The most widely cited benchmark from the 2024 dry-run, and the one supervisors used internally to calibrate expectations for 2026, is that only 6.5% of participating firms passed all 116 data quality checks the European Banking Authority applied to the register. The failure mode was not ignorance — the firms had ICT contracts, knew who their providers were, and in most cases had functioning third-party risk programmes. The failure mode was data fragmentation: no single authoritative source for ICT third-party relationships, with different fields held in different systems owned by different teams, and nothing resembling a machine-readable master record that could satisfy the register's taxonomy in one pass.

The 2024 rehearsal was voluntary and small. The 2026 submission was mandatory and large, and the data-quality profile did not transform in the intervening eighteen months — it improved, but from a floor so low that even substantial improvement did not translate into clean submissions. Regulators spent much of early April issuing rectification requests via national portals. The AFM's feedback cycle promises one business day in normal cases, two in exceptional ones (AFM — Register of Information); the ordinary cases, by the accounts emerging from compliance teams in mid-April, have been more exceptional than normal.

What Supervisors Are Actually Reading

Once the register is filed, what do supervisors do with it? The answer, a few weeks into the post-deadline phase, has become clearer. The ESAs combine national registers into a consolidated view that informs the designation of Critical ICT Third-Party Providers (CTPPs), the institutions whose systemic importance triggers direct EU-level oversight under DORA. The first official list of CTPPs, published by EIOPA, EBA, and ESMA after a structured process of data collection, criticality assessment, and notification, landed at the turn of 2026 (PwC Legal — ESAs publish first list of CTPPs). Cloud hyperscalers, major data vendors, and core ICT integrators feature prominently on that list — a signal that supervisors are focused on concentration risk and practical substitutability, not on mechanical completeness of register fields.

At national level, BaFin has been explicit about the lens it applies. Its review of 2026 submissions is, according to German supervisory updates, specifically focused on dependencies on US hyperscaler providers, treating cloud concentration with non-EU providers as a systemic exposure that the register's raw fields only partially capture. The register is, in that sense, an input — a structured dataset that enables supervisors to ask the questions they actually care about. The cleaner the input, the sharper the questions.

The Identity Chain Under the Register

The register's fields enumerate entities, services, and contractual relationships. What they do not capture is the layer beneath — the identities of the specific personnel at each ICT third party who hold privileged access to the financial entity's systems. An incident investigation walks from a compromised account through the authentication log to the credential holder and — if the credential is held by a third-party engineer under a change ticket — into the third party's own identity controls. The register does not make that chain auditable. It records that the financial entity buys service X from provider Y under contract Z. It does not record, for each critical service delivery, who was enrolled as a privileged operator, with what evidence, by which party, with what revocation log.

The DORA Register of Information captures contractual ICT relationships. The identity chain for privileged personnel at each provider sits beneath it — and that is where 2026 audits find the gap

That is the gap a practitioner notices when walking a supervisor through a DORA review. The contractual artefacts are there. The incident-reporting chain is there. The concentration picture is there. The identity-of-the-specific-human-at-the-specific-supplier — the question that actually determines whether an incident's root cause traces back to a lapse, a rogue credential, or a clean supply-chain compromise — is often opaque, because the register was never designed to hold it. The parallel gap under NIS2 Article 21(2)(d) — and the structure of the supplier register supervisors now examine — is the subject of our 18 April post.

Why It Matters Now, Not in 2027

DORA implements an annual register refresh. The 2027 cycle will be lighter: limited-scope, with entities whose submissions are unchanged able simply to confirm the state (FSMA — DORA Register limited update in 2026). In that sense, the 2026 submission was the load-bearing one — the baseline against which future changes are evaluated. It is also the first year in which the ESAs' consolidated dataset, combined with the CTPP list, gives supervisors the view they need to ask identity-chain questions across borders.

For a financial entity that is carrying privileged third-party access from providers outside its home jurisdiction — an EU bank using a US-based managed service provider for its data warehouse, a payment institution depending on a non-EU cloud region for its disaster-recovery target — the question "who are the named engineers with access to our systems, and what identity evidence do you hold for each of them?" is no longer a hypothetical. It is the question supervisors are asking CTPPs and, via CTPPs, the entities that depend on them. The ESAs' push to designate CTPPs is not a paperwork exercise; it is the mechanism by which that question becomes enforceable.

What the Gap Looks Like in Practice

Three scenarios are now common in post-deadline conversations with DORA compliance teams. A mid-sized asset manager that has consolidated its ICT third-party inventory but cannot say which individual engineers at its core data vendor hold database privileges, nor produce identity evidence for them. A European insurer whose cloud provider's support team spans three jurisdictions and whose privileged-access logs do not identify the specific analyst who resolved a production incident. A payment institution whose contractual security clauses reference "identity and access management" as a general obligation, without defining what evidence of enrolment is retained, where, and under whose control.

In each case, the Register of Information is clean. The CTPP designation is in order. The identity chain beneath the register is the unaudited layer.

What 2026 Remediation Looks Like

For firms exiting the 2026 submission cycle with findings to rectify, the remediation agenda has two parts. The first is the structural fix: consolidate the ICT third-party data model into a single authoritative source so that the 2027 register refresh is a one-pass export, not a twelve-team reconciliation. The second is deeper: extend the supplier record to include named privileged personnel, with identity evidence — ideally cryptographic — for each. For EU-national personnel, the EUDI Wallet, available across Member States by December 2026, will provide a compliant path. For the significant fraction of third-party personnel based outside the EU, an equivalent evidence class is available from the biometric passport: an ICAO 9303 chip read at enrolment, countersigned under eIDAS, producing a government-signed identity record that slots under the register entry for the CTPP.

The register is the contractual outline. The identity chain is the operational truth. 2026 exposed the gap between them. 2027 will be the year supervisors start examining it.

The same lesson applies to the CER Directive's 17 July 2026 critical-entity designation wave: the ten-month post-notification clock is a planning runway, not a reporting window. Firms that treat the CER designation decision as a binary event — in or out — miss the operational work that the DORA retrospective has just made legible.

Sources

DORA regulation and RTS

Register of Information — 2026 submission

Critical ICT Third-Party Providers

ePassport standard (cross-border identity evidence)

About the author

Mairi Kutberg is co-founder of IdentiGate, where she runs operations and content. She works at the intersection of EU regulation (eIDAS, NIS2, AMLR, eFTI), cross-border digital identity, and the practical compliance angles of advanced electronic signatures.

You detect deepfakes at the point where the driver's identity is bound to the freight platform for the first time — at chip-anchored NFC read of the passport plus biometric face-match against the chip's signed photograph, with presentation-attack detection at the device layer. The four deepfake attack vectors that apply to customer onboarding all apply to driver onboarding, but the freight-platform context adds two operational realities that make the stakes higher: driver identity survives across hundreds of shipments per year, and a fraudulent driver identity onboarded once produces cargo-loss exposure downstream. This post walks the specific deepfake-detection architecture for freight driver onboarding, where the traditional flow breaks, and what the fictitious-carrier fraud pattern looks like when it exploits weak driver identity.

You move the identity-proofing operation from a supervised video call to a chip-anchored NFC read plus biometric face-match — ninety seconds, unattended, and the evidence artefact is cryptographically stronger than the supervised alternative rather than weaker. The speed / evidence-quality trade-off that dominated KYC design for the last decade is not a real trade-off in 2026; it is a legacy artefact of an architecture that assumed identity proofing required a human reviewer in the loop. This post walks the four operations inside a KYC verification, where the time actually sits, and how the chip-anchored architecture collapses time without sacrificing evidence quality.

Vendors that combine chip-anchored passport-NFC verification with liveness-plus-injection-attack detection, wrapped in an AdES evidence record. Deepfake-resistance in customer onboarding is not a single feature — it is the intersection of four defence layers, each of which blocks a different attack vector (document forgery, real-time face-swap, presentation injection, synthetic identity). This post walks the four attack vectors, the four defence layers, and the rubric for evaluating any onboarding vendor's actual deepfake posture in 2026.