Zero Trust Under DORA: Rethinking Network Security for Financial Services

The Perimeter Is Gone

For decades, financial institutions built their cybersecurity around a simple model: a hardened perimeter enclosing a trusted internal network. Firewalls, DMZs, VPNs, and intrusion detection systems formed concentric rings of defense. Once inside the perimeter, users and systems were implicitly trusted. This model worked when the perimeter was a physical data center with a finite number of entry points.

That model is now obsolete. Cloud adoption, remote work, API-driven open banking, third-party integrations, and mobile channels have dissolved the perimeter. A typical European bank today has users connecting from home offices, branch networks, partner systems, cloud workloads, and customer-facing APIs — often simultaneously. The "inside" and "outside" distinction that perimeter security depends on no longer exists.

DORA does not mention Zero Trust by name. But its security requirements — particularly Art. 9 (protection and prevention) and Art. 10 (detection) — describe a security posture that is functionally identical to Zero Trust Architecture (ZTA). The regulation demands continuous verification, network segmentation, granular access control, and the assumption that any component can be compromised. The ECB's 2024 cyber resilience stress test across 109 banks confirmed that lateral movement — the ability of an attacker to move freely within a compromised network — remains one of the most critical recovery gaps in European banking.

Zero Trust is not a product. It is an architectural philosophy: never trust, always verify, assume breach. Under DORA, it is becoming a regulatory expectation.

DORA's Security Requirements Map to Zero Trust

Art. 9: Protection and Prevention

Art. 9 requires financial entities to implement ICT security policies and procedures to "ensure the resilience, continuity and availability of ICT systems." The specific requirements map directly to Zero Trust pillars:

Art. 9(2) is particularly significant: it requires that ICT security policies "define measures for the protection of ICT assets and information." The word "define" implies explicit, documented policies — not implicit trust inherited from network location. An ICT asset's access to another ICT asset must be justified by policy, not by the fact that they share a network segment.

Art. 10: Detection

Art. 10 requires mechanisms to "promptly detect anomalous activities" including "ICT-related incidents, ICT network performance issues and security-related events." This is the continuous monitoring pillar of Zero Trust. Detection cannot function in a flat network where all internal traffic is considered normal. It requires baseline behavior models, transaction-level visibility, and the ability to distinguish legitimate from anomalous access patterns.

In the traditional model, compromising any single server grants access to all others. In the Zero Trust model aligned with DORA Art. 9, every inter-service communication is verified against policy. Lateral movement requires compromising the policy engine itself — a dramatically harder attack path.

The Five Pillars of Zero Trust for DORA Compliance

1. Identity: Beyond Username and Password

DORA Art. 9(4)(a) requires "strong authentication mechanisms" and access control policies that grant "access rights to ICT assets on a need-to-know basis." In Zero Trust terms, identity is the new perimeter. Every access decision starts with verifying the identity of the requesting entity — whether human user, service account, API client, or automated process.

For financial institutions, this means:

• Multi-factor authentication for all human access to critical systems (not just VPN or external-facing applications)
• Service-to-service authentication using mutual TLS, service mesh identity, or workload identity federation
• Continuous authentication that reevaluates trust throughout a session based on behavior, device posture, and context
• Privileged access management with just-in-time elevation, session recording, and automatic revocation

2. Network: Microsegmentation as a DORA Requirement

Art. 9(4)(b) requires "network security management" including "segregation and segmentation of networks." This is microsegmentation — the Zero Trust principle that every workload, application, and data store operates in its own security zone with explicitly defined communication paths.

The ECB stress test found that many banks could contain an initial compromise but struggled to prevent lateral movement to critical systems. Microsegmentation directly addresses this: even if an attacker compromises a non-critical system, they cannot reach payment processing, core banking, or the ICT asset register without passing through additional policy enforcement points.

3. Device: Endpoint Trust Verification

Zero Trust extends identity verification to the device itself. A valid user credential presented from a compromised device is still a compromised session. DORA Art. 9(3) requires that ICT security measures "ensure the security and functioning of all ICT systems on a continuous basis" — this includes the endpoints from which those systems are accessed.

For financial institutions operating hybrid environments, device trust verification includes: endpoint detection and response (EDR) agents confirming device health, certificate-based device identity, patch compliance verification before granting access, and network access control (NAC) that evaluates device posture at connection time.

4. Application: Workload Security

Every application, microservice, container, and serverless function must authenticate, authorize, and encrypt its communications. DORA Art. 7 requires that financial entities "use and maintain updated ICT systems, protocols and tools that are reliable" — reliability in a Zero Trust context means that applications cannot trust the network they run on.

This translates to: application-level encryption (TLS everywhere, including east-west traffic), API authentication and authorization at every boundary, input validation and output encoding as defense-in-depth, and runtime application self-protection (RASP) for critical workloads.

5. Data: Classification-Driven Access

DORA Art. 9(4)(c) requires "the protection of data against risks arising from data management, including poor administration, processing related risks and human error." In Zero Trust, data is the ultimate asset to protect. Access to data is granted based on the classification of the data, the identity and context of the requester, and the minimum necessary scope.

Implementation Roadmap: From Perimeter to Zero Trust

The transition from perimeter-based security to Zero Trust cannot happen overnight. For financial institutions operating 24/7 critical systems with regulatory obligations, the migration must be phased, reversible, and non-disruptive.

Phase 1 (Months 1-4): Foundation. Consolidate identity providers, deploy MFA across all access paths, complete the ICT asset register with network topology and communication flows, and establish network visibility baselines.

Phase 2 (Months 5-8): Segmentation. Implement microsegmentation around critical systems (payment processing, core banking, customer data stores), deploy service mesh for internal service communication, and enforce mutual TLS for all east-west traffic.

Phase 3 (Months 9-12): Verification. Deploy continuous authentication that evaluates trust throughout sessions, integrate device trust signals into access decisions, and implement adaptive access policies that adjust based on risk context.

Phase 4 (Months 13-18): Optimization. Deploy user and entity behavior analytics (UEBA) for Art. 10 detection requirements, automate response playbooks for common anomaly patterns, and conduct a comprehensive Zero Trust posture review against DORA requirements.

Common Implementation Mistakes

1. Treating Zero Trust as a product purchase. No single vendor delivers Zero Trust. It is an architectural approach that spans identity, network, device, application, and data layers. Institutions that buy a "Zero Trust solution" without redesigning their architecture get an expensive tool with perimeter-model assumptions.

2. Ignoring legacy systems. European banks operate mainframes, COBOL-based core banking systems, and on-premises infrastructure that cannot natively participate in Zero Trust architectures. These systems require compensating controls: bastion hosts, protocol translation gateways, and enhanced monitoring. DORA's proportionality principle applies — but proportionality does not mean exemption.

3. Microsegmentation without visibility. You cannot segment what you cannot see. Before deploying microsegmentation policies, institutions must map all communication flows between systems. Blocking a critical but undocumented integration path can cause production outages.

4. Neglecting third-party access. Art. 28 requires that third-party ICT service providers comply with the institution's security requirements. This includes Zero Trust controls: third-party access must be authenticated, authorized, segmented, and monitored with the same rigor as internal access. The vendor risk scoring methodology must include third-party access architecture as a risk factor.

Supervisory Expectations

The EBA and ECB have not issued explicit guidance mandating Zero Trust. But the direction of travel is clear. The ECB's 2024 stress test focused on lateral movement — a gap that microsegmentation directly addresses. The EBA Guidelines on ICT and Security Risk Management emphasize network segmentation, access control, and continuous monitoring — all Zero Trust principles.

Supervisory questions to prepare for:

• "How do you prevent lateral movement after an initial compromise?"
• "How are service-to-service communications authenticated within your internal network?"
• "What is your network segmentation architecture for critical and important functions?"
• "How do you verify device posture before granting access to critical systems?"
• "How do you manage third-party access to your internal network?"

Institutions that can answer these questions with documented architecture, tested controls, and auditable evidence are demonstrating Zero Trust maturity — whether or not they use the term.

The Convergence Is Inevitable

Zero Trust and DORA compliance are converging because they respond to the same reality: the threat landscape has evolved beyond perimeter defense, and regulatory expectations have evolved with it. Financial institutions that treat Zero Trust as an isolated security initiative and DORA as an isolated compliance exercise are duplicating effort and missing synergies.

The efficient path is to recognize that DORA's testing requirements (Art. 24-27) provide the validation framework for Zero Trust controls, DORA's incident management requirements (Art. 17-23) provide the response framework when Zero Trust controls fail, and DORA's reporting requirements (Art. 14) provide the governance framework for communicating Zero Trust maturity to the management body.

Zero Trust is not a DORA checkbox. It is the security architecture that makes DORA compliance sustainable — and the architecture that supervisors will increasingly expect to see.

Key Takeaways

• DORA Art. 9 and 10 requirements map directly to Zero Trust pillars: identity verification, network segmentation, data protection, continuous monitoring, and access control.
• Lateral movement remains a top gap in European banking, as confirmed by the ECB's 2024 stress test. Microsegmentation is the primary architectural control.
• Zero Trust implementation requires 12-18 months for financial institutions with legacy infrastructure. Phase it around critical systems first.
• Legacy systems cannot be ignored. Compensating controls (bastion hosts, enhanced monitoring) are required for systems that cannot natively participate in Zero Trust.
• Third-party access must be subject to the same Zero Trust controls as internal access, per DORA Art. 28.

---

Resume en francais

L'architecture Zero Trust et les exigences de securite de DORA convergent naturellement. L'article 9 impose la segmentation reseau, l'authentification forte et le controle d'acces granulaire — les trois piliers fondamentaux du Zero Trust. L'article 10 exige une detection continue des anomalies, ce qui necessite une visibilite sur les flux reseau que seule la microsegmentation permet. Le test de cyber-resilience de la BCE en 2024 a confirme que le mouvement lateral reste une lacune critique dans le secteur bancaire europeen. Ce guide propose une feuille de route en quatre phases pour la migration vers le Zero Trust : fondation (identite et visibilite), segmentation (microsegmentation des systemes critiques), verification (authentification continue) et optimisation (detection comportementale). L'approche perimetrique traditionnelle est obsolete dans un contexte de cloud, d'open banking et de travail hybride. Les institutions financieres qui alignent leur strategie Zero Trust avec DORA realisent des synergies considerables — le cadre DORA fournit la validation (tests Art. 24-27), la reponse (gestion des incidents Art. 17-23) et la gouvernance (reporting Art. 14) necessaires a une architecture Zero Trust durable.