DORA Article 8 requires ICT risk management controls. Your Linux estate is the exposure point.
Years of vendor access, service accounts and sudo rules have built paths to root across the Linux systems behind your financial services, and nothing in the standard stack maps them. Automation and AI agents now find and use those paths faster than any review. DORA has been mandatory since January 2025; our pilot maps every path and delivers the ICT risk management evidence Articles 8, 9, 10 and 28 ask for.
Why DORA Changes the Bar for Linux Identity
- Service account proliferation in financial infrastructure creates a chronic blind spot: accounts created for one-time integrations, vendor access, or legacy systems accumulate privileges without governance, violating DORA access control principles.
- Automation and AI agents authenticate as those service accounts and inherit whatever reach the accounts have built up on core financial hosts, so an unmapped path to root is used faster than any review cycle. Demonstrating control under Article 9 means knowing what each account can do on each host, continuously.
- DORA Article 8 mandates identification and documentation of the ICT assets, roles and dependencies behind your business functions, and Article 9 mandates demonstrable control over access to them — Linux servers hosting core financial infrastructure are the primary control gap.
- Article 10 requires financial entities to have detection mechanisms for anomalous activity. Without continuous privilege monitoring on Linux systems, detecting unauthorised access escalation is impossible.
- DORA requires entities to produce audit evidence for supervisory authorities — the EBA, ESMA, and national competent authorities — demonstrating that ICT risk management controls are continuously effective, not just documented.
- DORA has been mandatory since January 17, 2025 with no transition period. Supervisory assessments are underway across EU financial entities; absence of Linux identity governance evidence is a material finding.
How the Founding Pilot Addresses DORA Requirements
Every pilot finding is mapped to specific DORA controls, so the evidence feeds your DORA ICT risk management reporting.
| Article / Requirement | What It Mandates | How the Founding Pilot Covers It |
|---|---|---|
| Article 8 | Identification of ICT assets, roles and sources of ICT risk | Complete Linux identity and privilege inventory with risk classification mapped to ICT risk management requirements |
| Article 9 | Protection and prevention measures | Assessment of access control configurations, privilege separation, and least-privilege implementation across Linux estate |
| Article 10 | Detection of anomalous activities | Identification of privilege drift patterns and undocumented access changes that would evade standard detection mechanisms |
| Article 28 (Chapter V) | ICT third-party risk management | Assessment of vendor and service account privileges identifying third-party access that exceeds authorised scope |
The documents that define DORA access evidence in practice
Articles 8, 9 and 10 say what must be managed. Three further documents say what the evidence looks like, and none of them is about servers.
Commission Delegated Regulation (EU) 2024/1774
The regulatory technical standards on the ICT risk management framework, of 13 March 2024. Article 20 requires identity management that uniquely identifies the persons and systems accessing the entity’s information; Article 21 sets the access-control requirements built on it — need-to-know and least privilege, account lifecycle and authentication.
Read the sourceCommission Implementing Regulation (EU) 2024/2690
The NIS2 implementing regulation, in force since 7 November 2024, binding the cloud, data-centre, managed service and managed security service providers that financial entities rely on as ICT third parties. Annex section 11 is access control, with 11.3 on privileged accounts and system administration accounts; section 12 is asset management.
Read the sourceENISA Technical Implementation Guidance, version 1.0
Published 26 June 2025, it follows that Annex requirement by requirement with guidance and examples of evidence. Non-binding, and the most detailed EU-level description of what evidence of access control looks like — the same artefacts a DORA ICT risk review asks to see on Linux.
Read the sourceDORA compliance is a property of the financial entity, not of a server. No Linux host is “DORA compliant”; the entity demonstrates its ICT risk management across the systems behind its services. Linux hardening and Linux identity evidence are the layer beneath that demonstration: the access rights, privileged accounts and logs the standards ask about are produced on the hosts, and that is where the pilot’s evidence sits.
Where the pilot’s evidence lands in the standards
| Section | Requirement | What the pilot hands over |
|---|---|---|
| RTS Art. 20 | Identity management — unique identification of persons and systems | Shared accounts and keys reused across hosts flagged; logins, sudo commands and configuration changes attributed to the identity behind them. |
| RTS Art. 21 | Access control — need-to-know, least privilege, account lifecycle | Every account, group, sudo rule and SSH key per host; which identities can reach root on which host, ranked by risk; dormant and orphaned accounts surfaced. |
| DORA Art. 8 | Identification of ICT assets, roles and sources of ICT risk | The identity inventory per host, continuously updated, with the risk score of every remaining account explained inline. |
| DORA Art. 10 | Detection of anomalous activities | Sudo, SSH and PAM configuration tracked against an approved baseline; changes detected in near-real-time and attributed, recorded in a chain-hashed audit log. |
| DORA Art. 28 | ICT third-party risk | Every vendor and service account listed with what it can do; access that exceeds its authorised scope flagged. |
Where LinuxGuard sits among the Linux compliance tools you already run
Most estates in scope already run one or more of these for hardening and logging. Each closes part of the picture; none of them answers who can reach root on which host, or keeps that answer current. Read them as complements, which is how we deploy alongside them.
Open-source options
Lynis
A host-based security audit for Linux and Unix systems. It runs on the host itself, tests hundreds of hardening controls drawn from CIS, NIST and NSA guidance, and reports a hardening index with warnings and suggestions.
- Closes
- A point-in-time hardening audit of an individual host.
- Leaves open
- It does not inventory accounts, sudo rules or SSH keys across an estate, does not attribute a change to an identity, and does not watch between runs.
OpenSCAP with Ansible
SCAP content from the SCAP Security Guide, with CIS, DISA STIG and PCI DSS profiles. It evaluates a host’s configuration against a profile, produces HTML and ARF reports, and ships remediation content, including Ansible, to bring the host back to the baseline.
- Closes
- Configuration-baseline conformance and remediation at scale.
- Leaves open
- Who holds privilege on the host is not a benchmark rule: sudoers topology, SSH key ownership and service accounts sit outside the profile, and each scan describes one moment.
auditd
The userspace component of the Linux Auditing System. It writes audit records to disk according to the rules loaded from audit.rules, which is the event record that monitoring and logging requirements draw on.
- Closes
- A record of what happened on the host — logins, privileged commands, file access — as configured.
- Leaves open
- It records events; it does not assess configuration, inventory accounts or rank privilege. Rulesets drift between hosts, and the logs still need central collection and interpretation.
Ubuntu Pro (Ubuntu Security Guide)
Canonical’s subscription tooling for Ubuntu LTS. The Ubuntu Security Guide hardens a host to CIS or DISA-STIG profiles and generates audit reports; CIS profiles cover 20.04, 22.04 and 24.04 LTS, DISA-STIG 20.04 and 22.04.
- Closes
- Benchmark hardening and audit reporting on Ubuntu hosts.
- Leaves open
- Ubuntu only, by design. It reports benchmark conformance, not who can reach root or which keys and service accounts hold privilege, and it does not attribute change to an identity.
Commercial platforms
LinuxGuard
A Linux-native identity control plane. A continuous inventory of every account, group, sudo rule, SSH key and service account across the distributions you run, risk-scored, with sudo, SSH and PAM changes detected in near-real-time and attributed to the identity behind them, response actions behind an approval gate, and evidence exported per framework.
- Closes
- The access-rights, privileged-account and inventory evidence that the access-control and asset-management requirements ask for — continuously, rather than per scan.
- Leaves open
- It does not harden the operating system to a benchmark and does not replace auditd’s event record. It runs alongside both.
Ubuntu Pro is listed with the open-source tools because the Ubuntu Security Guide is the hardening route most Ubuntu estates already have; it is a Canonical subscription. LinuxGuard is Validated with Ubuntu under Canonical’s Software Partner Programme and is certified with Red Hat and SUSE.
Deliverables for DORA Programs
- Identity & Privilege Inventory — Every user, group, sudo rule, SSH key, and service account across your Linux estate, showing who can do what
- Risk-Scored Findings Report — Prioritised findings based on real exploit patterns, highlighting the privilege paths attackers would use first
- Compliance Evidence Package — Identity governance gaps mapped to DORA Articles 8, 9 and 10 and to the Chapter V third-party risk provisions, with remediation guidance
- Prioritised Remediation Plan — Phased plan to reduce privilege drift and move toward least-privilege, with a zero trust alignment overlay where applicable
- Board-Ready Executive Summary — Executive summary for boards and a technical deep-dive for your security team
How the Founding Pilot Works
The Founding Pilot runs in four phases over 60 days — discovery and scoping, identity and privilege mapping with lightweight read-only collectors, a security and compliance assessment that maps findings to DORA Articles 8, 9, 10 and 28, and reporting with a prioritised least-privilege remediation roadmap. See the Founding Pilot for the full four-phase process, timeline, and deliverables.
Frequently Asked Questions
Does DORA apply to our Linux infrastructure?
What does Article 8 require for ICT risk management on Linux systems?
How does the pilot fit into ICT third-party risk assessment under Chapter V?
What evidence does the pilot produce for supervisory authorities?
Can the pilot be scoped to DORA-critical systems only?
Related solutions
EU-wide cybersecurity directive requiring identity and access management controls for your Linux estate.
Learn about the NIS2 Pilot
Zero-trust access controls and compliance posture for Linux infrastructure.
View Security & Compliance
Further reading: Linux access control evidence under DORA, PCI DSS Requirements 7 and 10 on Linux, and Linux access control evidence for SOX ITGC.