DORA and Active Directory: Security Obligations for Financial Entities

Your national competent authority is not going to ask whether you have a security policy.

They are going to ask when you last technically verified that it works.

DORA came into force in January 2025. I have spent months talking with security teams at financial entities that have their controls perfectly documented and an Active Directory that has not been technically audited in years. That is not negligence — it is that nobody had required it in a binding way until now. That changed.

DORA (EU 2022/2554) creates concrete, enforceable obligations on ICT risk management — not improvement targets. Active Directory is the ICT asset that the entire operation of a financial entity depends on. If an attacker compromises it, the ability to authenticate users, access critical applications, and operate normally falls with it. This article explains exactly what DORA requires regarding AD and how to prepare the evidence before the supervisor asks for it.

What DORA Requires About Active Directory

Quick reference — DORA articles that directly govern Active Directory security:

DORA does not mention Active Directory by name. It does not need to: the articles of the regulation directly cover the domains that make AD the most relevant asset for ICT compliance in any financial entity.

Art. 6 — ICT Risk Management Framework

Article 6 requires identifying all critical ICT assets, documenting dependencies between them, and maintaining an up-to-date inventory. Active Directory clearly meets this definition: it is the single authentication point on which banking systems, trading platforms, customer database access, and back-office systems depend. If it is not in the critical asset inventory with documented controls, the ICT risk management framework is incomplete.

Art. 9 — Protection and Prevention

This article requires access controls, privileged identity management, and segmentation of critical systems. Translated to the AD environment: an inventory of accounts with elevated privileges (Domain Admins, Enterprise Admins, backup operators), periodic review of those privileges, and separation of domain administration accounts from daily-use accounts. It also covers protection against escalation techniques that allow an attacker to move from an unprivileged user to domain administrator.

Art. 10 — Detection

DORA requires continuous monitoring capabilities and anomaly detection. In the context of Active Directory, this means that unusual logons, permission changes on critical objects, domain replication requests, and Kerberos configuration modifications must be detected in real time. Having a SIEM configured is not sufficient: you must be able to demonstrate that relevant AD events are being consumed and correlated.

Art. 11 — Response and Recovery

The incident response plan must address Active Directory compromise scenarios. A full domain compromise — obtaining the krbtgt hash, creating hidden administrator accounts, mass credential extraction — is the highest-impact scenario for a financial entity. If the response plan does not cover that scenario with concrete containment and recovery steps, it does not meet the requirements of Article 11.

Art. 13 — ICT Resilience Testing (TLPT)

This is the article that concerns security managers most. For entities considered significant, DORA requires threat intelligence-based penetration testing (Threat-Led Penetration Testing, TLPT). These tests must be carried out by independent external teams, with scope covering the entity's critical systems — including Active Directory. This is not a generic black-box test: it is a technical exercise guided by real threat intelligence, where AD is a priority target.

The AD Attack Vectors Most Relevant to DORA

The same vectors that national CERTs detect in financial sector organizations are the ones that TLPT teams will look for when conducting the tests required by Art. 13. Knowing them in advance is not optional: it is the difference between controlling the outcome and discovering the problems at the worst possible moment.

Kerberoasting

Any domain user can request a Kerberos service ticket for an account that has a registered SPN. If that account has a weak password — common in legacy service accounts — the ticket can be cracked offline without any further interaction with the DC. In financial entities with AD environments that have been in production for years, it is common to find service accounts with registered SPNs, passwords that never expire, and access to critical business systems.

DORA articles involved: Art. 9 (privileged identities) and Art. 10 (detection of anomalous ticket requests). Required evidence: inventory of accounts with SPNs, password policy for service accounts, and technical verification that no service account with access to critical systems has a crackable password.

ADCS — Certificate-Based Escalation

Misconfigurations in Active Directory Certificate Services templates allow an attacker to request certificates on behalf of other identities, including domain administrators. Vulnerability ESC1 allows impersonating any domain user. ESC8 allows relaying NTLM authentication to the certificate service to obtain a valid domain certificate.

DORA articles involved: Art. 9 (access controls and identity management) and Art. 11 (response plan — a fraudulent certificate can remain valid for years after a compromise). Required evidence: review of all certificate templates, verification of ESC1 through ESC16 configurations.

DCSync

If an account has replication permissions on the domain partition, it can simulate being a domain controller and request a full replication — including all NTLM hashes in the directory. The attacker obtains the credentials of every user, including the krbtgt hash, which allows generating Golden Tickets with indefinite validity.

DORA articles involved: Art. 9 (access to critical assets), Art. 11 (maximum-impact scenario; recovery requires krbtgt rotation and full review). Required evidence: ACL audit on the domain root, inventory of accounts with replication permissions.

Unconstrained Kerberos Delegation

A machine with unconstrained delegation (TrustedForDelegation) stores in memory the TGTs of every user who authenticates against it. An attacker with local access to that machine can reuse those tickets to impersonate any domain user.

DORA articles involved: Art. 9 (segmentation and control of privileged access), Art. 10 (monitoring of risky configurations). Required evidence: inventory of machines and accounts with delegation configured, business justification and compensating controls for each case.

The Difference Between Documentary Compliance and Real Resilience

Most financial entities have security policies for Active Directory. A password policy, a privileged access review procedure, a disaster recovery plan. The problem is that these policies are drafted, approved in committee, and rarely verified technically in any systematic way.

DORA, and Art. 13 in particular, makes that distinction relevant before the supervisor. An entity can present a correctly drafted privileged identity management policy and still have service accounts with ten-year-old passwords, ADCS templates with ESC1 active, and objects with unjustified DCSync permissions.

The concrete distinction the regulator is starting to draw is this: "we have a password policy for service accounts" versus "we have technically verified that no account with an SPN and a crackable password exists in our environment." The first is documentation. The second is evidence.

TLPT teams will execute exactly those verifications against your real environment. The outcome of that exercise will document what the regulator sees. Preparing in advance — with the same technical tools an offensive team would use — is the only way to control that outcome.

How to Prepare the Evidence for the Supervisor

National competent authorities (NCAs) — in Spain: Banco de España, CNMV, and DGSFP; in other EU member states: your national banking or securities supervisor — will not ask for generic documents. They will ask for concrete technical evidence demonstrating that ICT risk management is real and continuous, not a policy-drafting exercise.

The documentation you need to have ready includes:

• Privileged account inventory — up to date, with the date of last review and business justification for each account with elevated access
• AD change log — who modified what, when, and with what authorization — consumed and stored in a way that cannot be altered
• Results of periodic technical tests on the state of the directory: vectors detected, severity, date of detection, and remediation status
• Remediation plan with committed dates for each open technical finding

ADscan generates all of this automatically in a single analysis session. The report includes explicit mapping of each finding to the corresponding DORA articles, detected attack paths with CVSS scores, and a remediation roadmap prioritized by real impact.

For financial entities under DORA that need to prepare this documentation before a supervisory inspection or a TLPT exercise, request a free AD assessment at adscanpro.com/pov. The DORA report is delivered the same day.

Conclusion

DORA does not invent the need to audit Active Directory. What it does is make it a regulatory obligation with enforceable consequences. The question is no longer whether you should audit your AD: it is when you are going to do it and what evidence you will present to the supervisor.

For most financial entities, the real state of Active Directory does not match what their security policies say. The gap between the two is exactly what a TLPT team will document — and what the regulator will see.

Knowing that real state before the regulator does is not a competitive advantage. It is the minimum that DORA requires.