DORA Identity Security Requirements: 2026 Guide

DORA (Regulation (EU) 2022/2554) requires financial entities to run a four-part ICT risk management framework that touches identity directly: close external exposure, remove reusable credentials, contain lateral movement, and keep data recoverable after an attack. Secfolio maps these obligations to four controls — external exposure management, passwordless authentication, identity microsegmentation, and Cyber Storage — so a bank, insurer, or payment processor can show examiners a working control, not a policy binder. DORA has applied since January 17, 2025, and heading into 2026, national competent authorities are checking whether each control is documented, tested, and enforced, not just written down.

Why this matters

DORA applies to more than 22,000 financial entities across the EU, plus the critical ICT third-party providers those entities depend on. It doesn't invent new identity standards — it forces institutions to prove the controls they already claim to have. Examiners ask for evidence of authentication strength, access segmentation, incident detection, and recovery testing, not a slide deck.

Most financial institutions already own a password policy, a firewall, and a backup schedule. None of that satisfies DORA's identity requirements if the credentials are reusable, the network is flat, and the backup sits next to the data it's supposed to protect. A zero-trust security platform for financial services closes that gap by treating identity, exposure, and recovery as one connected system rather than three separate checkboxes.

How to meet DORA identity security requirements for financial institutions

DORA's ICT risk management framework breaks into four operational steps for identity security:

1. Discover and close external exposure before it becomes an entry point — DORA's identification requirement (Article 8) expects a continuous, current asset and risk map, not an annual spreadsheet.
2. Eliminate reusable credentials with passwordless authentication — DORA's protection-and-prevention requirement (Article 9) calls for strong authentication on privileged and remote access.
3. Contain lateral movement with identity microsegmentation — the same Article 9 requirement expects segmentation that limits how far one compromised identity can travel.
4. Preserve data resilience with an architecture that survives ransomware and exfiltration — DORA's response-and-recovery requirement (Articles 11-12) expects tested backup and restoration capability, not an untested tape rotation.

Each row is evidence an auditor can check independently. That's the point — DORA doesn't grade intentions, it grades whether the control fires when tested.

Layer 1: Close external exposure before DORA's risk assessment does

DORA's identification requirement expects financial entities to know every ICT asset, every dependency, and every point of exposure before an incident, not after. Attackers rarely start with a zero-day — they start with an exposed admin panel, a forgotten subdomain, or a credential leaked outside the perimeter. An institution that can't produce a current exposure map in 2026 is already behind on the requirement, regardless of how strong its internal controls are.

Closing exposure before it's exploited also shrinks the incident-reporting burden DORA places on financial entities — fewer initial-access opportunities means fewer major ICT-related incidents to report in the first place.

Layer 2: Eliminate reusable credentials with passwordless authentication

A reusable password or a shared service account is the single most common entry point in financial services breaches, and DORA's strong-authentication expectation exists specifically to close it. Passwordless authentication removes the credential an attacker would otherwise phish, replay, or brute-force, because there's no static secret to steal in the first place.

Passwordless authentication for financial services institutions replaces password-based logins across privileged and remote access paths — the exact access categories DORA's protection-and-prevention requirement calls out. This is the layer examiners check first, because credential theft is the fastest documented path into a regulated environment.

Layer 3: Contain lateral movement with identity microsegmentation

Once an attacker is inside, they don't move network to network — they move identity to identity. DORA's protection-and-prevention requirement expects segmentation that limits blast radius, and most financial institutions built their internal network for connectivity, not containment.

Identity microsegmentation for financial services firms removes the unnecessary identity-to-identity paths that let one compromised account reach the core banking platform, the payment gateway, and the domain controller in a single session. A financial institution that can't show how it limits lateral movement after a credential compromise doesn't have a defensible answer for a DORA examiner.

Layer 4: Preserve data resilience with Cyber Storage

DORA's response-and-recovery requirement expects tested backup and restoration capability — but a traditional backup concentrates a full, reconstructable copy of the exact data an attacker just breached. Encrypt the primary environment and the backup often encrypts with it. Exfiltrate the data and the backup gets exfiltrated too, because it's sitting in the same reachable location.

Cyber Storage works differently: it encrypts data before it leaves the customer environment, shards the encrypted data into immutable, unusable fragments, and distributes those fragments across independent locations. No single location holds a reconstructable file — a logical air gap that doesn't depend on network isolation. An attacker who reaches a Cyber Storage location finds unusable fragments, not a file to encrypt or a database to exfiltrate, while authorized users still recover quickly.

How to prevent data exfiltration in financial services networks covers the exfiltration side of this same requirement in more depth. Cyber Storage doesn't replace the first three layers — a financial institution still needs exposure management, passwordless authentication, and microsegmentation. It's the layer that determines what an attacker finds if the first three are ever bypassed.

Why DORA identity requirements vary by institution

DORA applies a proportionality principle, so the depth of identity controls examiners expect isn't identical across every regulated entity:

• Entity classification — DORA allows a simplified ICT risk management framework for smaller institutions, while larger and more interconnected entities face the full requirement set.
• Sector — banks, insurers, investment firms, payment institutions, and crypto-asset service providers all fall under DORA, but the EBA, EIOPA, and ESMA each issue sector-specific guidance on top of it.
• Critical ICT third-party status — entities designated as critical ICT third-party providers face direct oversight, separate from the requirements placed on the financial entities that use them.
• Cloud and vendor dependency — heavier reliance on external ICT providers increases scrutiny of the register-of-information requirement and third-party access controls.
• Prior incident history — entities that have reported major ICT-related incidents typically face closer supervisory follow-up on their identity and access controls.
• Cross-border operations — institutions supervised by multiple national competent authorities need identity evidence that satisfies more than one regulator's interpretation.

Related questions about DORA identity security

Does DORA apply to fintechs and neobanks?

DORA applies to fintechs and neobanks that hold an EU financial services authorization, alongside traditional banks, insurers, and payment institutions. Scope is based on regulatory status, not company age or size, so a licensed neobank faces the same ICT risk management framework as an established bank, adjusted only by the proportionality principle.

Is DORA the same as NIS2?

DORA is not the same as NIS2 — DORA is sector-specific to financial entities, while NIS2 covers a broader set of critical infrastructure sectors, and DORA takes precedence for financial services where the two overlap. Both regulations expect strong authentication, segmentation, and incident reporting, which is why institutions covered by both frequently build one identity control set to satisfy both.

What happens if a financial institution fails a DORA compliance check?

A financial institution that fails a DORA compliance check faces remedial action from its national competent authority, ranging from required corrective plans to closer ongoing supervision. Repeated failures on core requirements like authentication strength or third-party oversight escalate faster, since DORA was built specifically to give supervisors enforcement teeth that earlier ICT guidance lacked.

FAQ

One last thing

Most financial institutions can describe their password policy in a sentence. Almost none can produce a current, complete register of every ICT third-party arrangement four subcontractor layers deep — which is exactly what DORA's register-of-information requirement expects, updated at least annually. The identity controls get the attention in 2026 planning cycles; the third-party register is the requirement that trips up institutions during an actual review. Map the subcontractor chain for your identity and access systems specifically — that's usually the thinnest part of the register.

Related guides

• Identity security platform for fintech and neobanks