Compliance & Privacy · 2026-07-13

DORA Article 28 and Third-Party ICT Risk for Identity Providers: The Subcontracting Chain

By J. W. Bouckaert

The regulation financial firms cannot delegate

Regulation (EU) 2022/2554—the Digital Operational Resilience Act, or DORA—has applied to in-scope financial entities across the European Union since 17 January 2025. Its ambition is straightforward: harmonise how banks, insurers, investment firms, payment institutions, e-money institutions, and their supervisors reason about the ICT they depend on, including the ICT they do not own.

Article 28, titled "General principles" for ICT third-party risk, is where that ambition meets the identity vendor stack. It is short. It is also the article that quietly reshapes every carrier-signal contract, every KYC processor arrangement, and every credential-issuance agreement a European financial entity has ever signed. Because identity is almost never delivered by a single vendor, Article 28 is really a regulation about chains—the sub-processors your identity provider uses, the sub-sub-processors those providers use, and the exit path when any link in that chain becomes untenable.

This article maps DORA's third-party ICT-risk regime onto the identity providers financial entities actually deploy. It provides a register-of-information template aligned to Commission Implementing Regulation (EU) 2024/2956, and it walks through the exit-strategy model required by Article 28(8) for the case that keeps identity architects awake: a critical carrier-signal provider is decertified overnight.

Article 28 obligations

Article 28 imposes four durable obligations on the financial entity, regardless of how many vendors sit between it and the eventual signal:

1. Full-lifecycle responsibility. The financial entity remains fully responsible for compliance with all DORA obligations even when ICT services are provided by third parties (Article 28(1)(a)). Delegation of the task never delegates the duty.
2. A strategy proportionate to the entity. The management body adopts and reviews an ICT third-party risk strategy, including a policy on the use of ICT services supporting critical or important functions (Article 28(2)).
3. A register of information. The financial entity maintains and updates a register of information covering all contractual arrangements on the use of ICT services provided by third-party service providers, distinguishing those supporting critical or important functions from those that do not (Article 28(3)). The register is reportable to the competent authority.
4. Documented exit strategies. For ICT services supporting critical or important functions, the entity puts in place exit strategies that account for risks emerging at the third-party level, including insolvency, deterioration in service quality, and business disruption (Article 28(8)).

Article 29 adds a preliminary concentration-risk assessment before contracting, and Article 30 governs the contract itself. Article 31 empowers the European Supervisory Authorities (EBA, EIOPA, ESMA), acting through their Joint Committee, to designate Critical ICT Third-Party Service Providers (CTPPs) for direct oversight by a Lead Overseer.

The regime is deliberately vendor-agnostic. It does not care whether the ICT service is a database, a mainframe, or a carrier signal. It cares whether the service supports a critical or important function, and it cares who is providing it—all the way down the chain.

Identity vendors as a DORA edge case

Most DORA guidance treats "ICT services" as if the vendor list were short and legible: a cloud hyperscaler, a core banking platform, a payments switch. Identity does not decompose that cleanly.

A single production authentication event at a European bank routinely involves:

• an Identity Provider (IdP) the bank contracts with (Okta, Ping, Entra ID, ForgeRock, or an in-house build);
• a passkey/WebAuthn attestation validated against a hardware attestation service;
• one or more carrier-signal providers returning SIM-swap, silent authentication, or number-lookup evidence;
• a KYC/AML orchestration layer proxying to document-verification, biometric-match, and sanctions-screening subprocessors;
• a verifiable-credential issuer for reusable identity (SD-JWT-VC or ISO/IEC 18013-5 mDLs);
• an event-signalling fabric (OpenID SSE/CAEP) that other IdPs rely on for session revocation.

Each of those is an ICT third-party arrangement. Several are subcontractors of the entity's primary IdP contract. Some are subcontractors of subcontractors. And several sit inside services that would satisfy the "critical or important function" test on their own—login to a payment initiation service, for example, or step-up authentication for a wire above the SEPA Instant threshold.

DORA does not exempt these arrangements because they are indirect. Article 30(2)(a) explicitly requires contractual coverage of the ICT services that will be subcontracted, and the ESAs' final draft RTS on subcontracting issued under Article 30(5) makes the register-and-approval obligation flow down through the chain for services supporting critical or important functions.

The subcontracting chain, made concrete

The following table shows the shape most European banks discover the first time they try to complete their DORA register of information for their identity stack. None of it is hypothetical.

A single carrier-signal query for silent authentication traverses T1 → T2 → T3. Each hop is a separate contractual and jurisdictional surface. Each hop must be reasoned about individually in the register, and each hop must be covered by the exit strategy for the T1 relationship.

Firms expect the chain to exist. The failure mode that surprises them is that the T3 (and sometimes T4) layer is invisible to the T0 contract. A European bank contracting with an IdP for step-up authentication may never see the names of the mobile network operators whose telemetry it depends on. Article 28(3) requires the register to surface them anyway.

Register of Information: A working template

Commission Implementing Regulation (EU) 2024/2956 laying down the ITS on the register of information specifies the fields the register must contain, in machine-readable form, for supervisory reporting. Its Annex I names fifteen templates with B_ codes: B_01.01 to B_01.03 identify the entity, its group and branches; B_02.01 to B_02.03 hold the contractual arrangements; B_03.01 to B_03.03 the signing entities; B_04.01 the entities using each service; B_05.01 and B_05.02 the providers and the supply chain; B_06.01 the functions; B_07.01 the assessment of services supporting critical or important functions; B_99.01 the terminology. (The ESAs' January 2024 draft used RT. codes; the regulation the Commission adopted in November 2024 does not, and the ESAs' validation rules reject a file whose table codes are not in the taxonomy.) The following is an identity-specialised extract mapped to the register's actual sections. Field labels track the ITS templates; content is illustrative for a mid-sized EU credit institution.

B_02.01 and B_02.02: contractual arrangements (identity-stack subset)

B_05.01 and B_05.02: providers and the supply chain behind critical or important functions

The distinction between T2 and T3 substitutability is the field regulators most often press on. A T2 aggregator can typically be replaced within a quarter; a T3 mobile network operator cannot be replaced at all for subscribers on its network, because the network is the source of truth for the signal. Documenting that structural non-substitutability is what the register is for.

Annex III: the ICT service types an identity stack maps to

The ITS Annex III taxonomy runs from S01 to S19, and none of the nineteen is "identity" or "authentication": the words do not occur in the regulation. An identity provider is classified by what its service is, and it routinely maps to several types at once:

A single T1 arrangement often carries three or four of these codes simultaneously, each on its own B_02.02 row. The register must reflect all of them; a single type per contract is one of the most common findings in supervisory sample tests.

Exit strategy: When a critical carrier signal provider is decertified

Article 28(8) requires exit strategies for ICT services supporting critical or important functions. The boilerplate contemplates a tidy commercial termination. The archetypal identity scenario is this one: at 09:00 CET on a Tuesday, a major carrier-signal aggregator loses its regulatory certification in one or more member states—decertified after a supervisory finding, a data-protection incident, or, under Article 31, following a Lead Overseer's recommendation the aggregator declined to implement.

By 09:30, the T1 IdP has silently degraded silent-authentication verdicts to a null-return posture. Step-up authentication is now decision-blind for every high-value payment session in flight.

A working exit strategy has to survive that morning. The following model, expressed as a phased runbook, is what DORA-mature institutions actually deploy.

Phase 1—Detection and containment (T+0 to T+30 minutes)

Phase 2—Bridging (T+30 minutes to T+72 hours)

Bridging exists because carrier signals are not homogenous across T2 vendors. A silent-authentication verdict from Aggregator A is not a drop-in replacement for one from Aggregator B; the underlying MNO coverage, false-positive envelope, and latency distribution differ. The exit strategy has to specify which authentication decisions can degrade gracefully and which must be paused entirely. See SIM Swap Detection's Latency Blind Spot for why the naive drop-in fails in practice.

Phase 3—Full replacement (T+72 hours to T+90 days)

Ninety days is roughly the shortest realistic window to run a compliant vendor procurement (including Article 29 pre-contractual concentration assessment) and stand up integration testing against a T2 whose T3 MNO relationships differ from the decertified provider's. Institutions that assume same-week vendor migration have not actually rehearsed one.

Substitutability, quantified

The 90-day figure carries a corollary: the exit strategy is only credible if the alternative T2 is under contract before Phase 1 fires. DORA does not mandate multi-vendor by name, but Article 29's concentration-risk assessment quietly forces the question. A rough substitutability heat map, of the kind that belongs in the annual ICT third-party risk strategy review:

The right entry in the register is not aspirational. Marking a structurally non-substitutable T3 as "medium substitutability" because a hypothetical alternative exists on paper is exactly the kind of finding that has surfaced in ESAs peer reviews of outsourcing arrangements under the predecessor EBA guidelines. DORA supervisors inherit that scrutiny.

Concentration risk and CTPP designation

Article 29 requires financial entities to assess whether a proposed ICT contractual arrangement leads to a situation of ICT concentration risk. Article 31 then allows the ESAs, through the Joint Committee, to designate ICT third-party service providers as critical (CTPPs) based on systemic impact, substitutability, and interconnectedness.

The identity industry has three natural CTPP candidates already visible in most European register-of-information exports: the dominant hyperscaler hosting most IdP control planes, the small number of KYC orchestrators serving a majority of pan-European neobanks, and the carrier-signal aggregators that concentrate MNO connectivity for step-up authentication.

A CTPP designation is not, on its own, a finding of harm. It is a supervisory tool. But for the financial entity, a CTPP flag on a T2 or T3 in the register does two things:

1. It raises the evidentiary bar for the Article 29 concentration-risk assessment, because "acceptable concentration" arguments are subject to Lead Overseer scrutiny.
2. It tightens the exit-strategy timeline. A CTPP subject to a Lead Overseer recommendation—one the provider declines to implement—is precisely the scenario that triggers the Phase 1 runbook above.

PasskeyBridge in the chain

PasskeyBridge is designed to be a T1 or T2 in a DORA register, depending on how the financial entity contracts. Two properties are engineered specifically for that placement:

• Zero-PII binding on carrier signals. Verdicts are returned bound to a pseudonymised subscriber hash, so the register-of-information field on personal data processed can be truthfully filled as "no plaintext identifiers." See the Zero-PII architecture reference.
• Cryptographic transparency of the sub-processor chain. Every attestation carries a signed manifest of the underlying signal providers, canonicalised under JCS and signed under our hybrid signature scheme, so the register entry for a T2 dependency can be reproduced from wire evidence rather than from an internal spreadsheet.

Neither eliminates the financial entity's Article 28 obligations. Nothing can. What they do is reduce the epistemic burden of the register from "trust the vendor's disclosure" to "verify the wire." That is the durable form of the compliance argument.

Read the SOC 2 Type II controls for identity APIs → Read the EU Digital Identity Wallet and eIDAS carrier-signal note → Get started with PasskeyBridge →

Start free · Test the API