The Digital Operational Resilience Act became enforceable across the EU on January 17, 2025. Financial entities, payment institutions, crypto-asset service providers, and their critical ICT third-party providers now operate under a unified framework that replaces fragmented national requirements.
DORA isn't another compliance checkbox. It's a structural shift in how European financial regulators think about technology risk. The regulation assumes your systems will be compromised. It requires you to detect, respond, and recover under that assumption.
This matters because financial services run on complex infrastructure stacks that application-layer security tools can't fully observe. Container orchestration, service meshes, shared kernel resources. The attack surface extends below where most security products operate.
What DORA Regulation Financial Firms Must Implement
The regulation organizes around five pillars. Three have direct technical implications for how you instrument your infrastructure.
ICT risk management requires governance frameworks, but also continuous identification and assessment of ICT risks. This means knowing what's running, where it's running, and how it behaves under normal conditions. Article 6 specifies "mechanisms and procedures to promptly detect anomalous activities."
Incident management, classification, and reporting creates a taxonomy for ICT-related incidents with mandatory reporting timelines to supervisory authorities. Significant incidents require initial notification within 4 hours of classification. You can't classify what you don't detect.
Digital operational resilience testing mandates both basic testing and, for significant entities, threat-led penetration testing every three years. Article 26 requires testing that simulates real attack scenarios including lateral movement and privilege escalation.
The gap most firms face isn't policy documentation. It's runtime visibility into what's actually happening at the system level.
The Detection Problem at the Kernel Boundary
Traditional security tools operate at the application layer or network perimeter. EDR products watch process execution and file access through userspace APIs. Network tools see encrypted traffic metadata. SIEM aggregates logs that applications choose to emit.
None of these see what happens at the syscall boundary before application-layer encryption. When a containerized trading application makes a network connection, spawns a child process, or opens a file, that action crosses into kernel space. The kernel mediates every resource access. That's where enforcement happens.
This boundary matters for DORA compliance because sophisticated attacks operate precisely where application-layer tools have limited visibility. A compromised container runtime, a privilege escalation via kernel exploit, lateral movement through service accounts using legitimate authentication tokens.
The DORA regulation financial firms must satisfy requires detecting "anomalous activities" that indicate ICT security incidents. Anomalous relative to what baseline? If you only instrument the application layer, your baseline is incomplete.
Runtime Behavioral Baselines Across Three Dimensions
Meeting DORA's detection requirements means establishing behavioral norms for your infrastructure and identifying deviations that matter. Not every anomaly is an incident. Context determines severity.
Effective behavioral detection operates across three dimensions simultaneously:
User behavior establishes what individual identities normally do. Service accounts that suddenly access different databases. Developers who've never deployed to production doing so at 3 AM. These patterns show up in process execution, network connections, and file access at the syscall level.
Role behavior aggregates patterns across groups. All developers, all DBAs, all automated deployment pipelines. This catches insider threats and compromised credentials that stay within plausible individual bounds but violate role norms.
Infrastructure behavior profiles clusters, namespaces, and workload types. A payment processing cluster that starts making outbound connections to previously unseen ASNs. A batch job workload that suddenly runs interactive shells. These indicate either misconfiguration or compromise.
The correlation across all three dimensions is what produces low false positive rates. A single anomalous action might be noise. The same action anomalous across user, role, and infrastructure simultaneously is a signal worth investigating.
Behavioral Detection Through eBPF at the Kernel Layer
Modern kernel instrumentation using eBPF provides the observation point DORA's requirements imply. eBPF programs run in kernel space with verified safety, capturing every process execution, file operation, and network event before any userspace manipulation.
This isn't theoretical. Kernel-level agents using CO-RE and BTF deploy without kernel modules, running as DaemonSets on Kubernetes or systemd units on VMs. They observe the syscall boundary where all workload activity ultimately crosses.
The performance characteristics make this practical for production financial systems. CPU overhead averages 0.1% at 1 million queries per second. Detection latency averages 98 milliseconds with a worst case under 2.5 seconds. Memory footprint averages 31MB per host.
More importantly, false positive rates decline with longer baseline periods. At seven days: 0.69%. At 30 days: 0.42%. At 180 days: 0.18%. This matters for DORA incident classification, where false positives create reporting burden and alert fatigue.
The behavioral model learns what normal looks like across users, roles, and infrastructure clusters. Then it correlates deviations. A payment processor spawning an interactive bash shell: unusual at the process level, never seen for that service account, unprecedented for that cluster. That's a correlating anomaly worth immediate investigation and potentially a reportable incident.
How Kernel-Level Detection Fits DORA's Testing Requirements
DORA's threat-led penetration testing requirements create an interesting challenge. Article 26 specifies scenarios including lateral movement, privilege escalation, and data exfiltration. Your testing validates both prevention and detection.
Kernel-level behavioral detection sees the artifacts of these attacks even when they use legitimate tools and credentials. Lateral movement appears as unusual network connections from processes that historically haven't made them. Privilege escalation shows up as unexpected capability grants or syscalls from unprivileged contexts. Data exfiltration manifests as abnormal file access patterns combined with network egress.
During TLPT exercises, detection at the kernel boundary provides ground truth for what actually happened on the system, independent of application logs. This validates your incident detection and classification procedures against realistic attack scenarios.
You're not replacing your existing security stack. EDR, SIEM, and network security tools remain essential. Kernel-level detection provides the 5% of visibility they don't have, particularly for containerized workloads where traditional agents struggle with ephemeral lifetimes and shared kernel resources.
Financial institutions already run defense-in-depth strategies. DORA makes the detection and resilience components mandatory with specific timelines and reporting requirements. The regulation assumes breach. Your compliance depends on detecting it fast enough to classify and report within the required windows.
Kernel-level behavioral detection isn't a DORA silver bullet. But it addresses the specific gap in runtime anomaly detection that the regulation's language implies. You need to know what's normal at the system level, detect deviations across multiple dimensions, and classify incidents accurately. That requires visibility at the boundary where all system activity ultimately occurs.