How should organisations build DORA-aligned ICT risk management around Active Directory and other identity services?

Why This Matters for Security Teams

DORA-aligned ICT risk management treats Active Directory, Entra ID, LDAP, and related identity services as operational dependencies, not background plumbing. If directory services fail, recover slowly, or drift out of control, authentication, privilege assignment, and service-to-service access can fail across the enterprise at once. That is why DORA expects risk to be documented, tested, and continuously improved, with identity services included in the same governance cycle as other critical ICT assets.

For identity teams, the practical challenge is not just uptime. It is knowing which business services depend on which directory configurations, trusts, service accounts, federation settings, and replication paths. The EU Digital Operational Resilience Act (DORA) pushes organisations toward evidence-based resilience, while NHI risk data from NHI Mgmt Group shows why identity control failures matter operationally: Ultimate Guide to NHIs reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

In practice, many security teams discover directory fragility only after an outage, a failed recovery test, or a privilege-related incident has already exposed the gaps.

How It Works in Practice

Build the DORA control model around identity dependency mapping first. That means cataloguing which applications, endpoints, and operational workflows rely on Active Directory, domain controllers, identity federation, conditional access, group policy, certificate services, privileged groups, and service accounts. Then identify the configuration items that matter to resilience: replication topology, admin tiering, trust relationships, recovery credentials, break-glass paths, and the mechanisms that protect changes to those objects.

Next, define controls that detect and limit drift. Use change monitoring for privileged directory objects, alert on new trusts and role assignments, and establish baselines for high-value identity settings. Align the control set to resilience and identity guidance in NIST Cybersecurity Framework 2.0 and the control discipline in NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially for access control, configuration management, logging, incident response, and contingency planning.

• Map critical identity services to each essential business process.
• Classify directory objects by recovery priority and blast radius.
• Monitor privileged changes, replication health, and authentication failures.
• Test restoration of identity services, not just backup completion.
• Review and reapprove the framework after major incidents and exercises.

Operationally, the objective is to prove that identity services can be detected, contained, recovered, and revalidated under pressure. That includes evidence for restoration objectives, escalation paths, and post-test remediation. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because it frames identity governance as a lifecycle and audit issue, not just access administration. These controls tend to break down when legacy domains, unmanaged service accounts, and ad hoc federation links create dependencies that no one has formally documented.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, requiring organisations to balance resilience against change friction. That tradeoff becomes sharper in hybrid estates, multi-forest AD environments, mergers, and environments with many application-owned identities. In those settings, rigid approval gates can slow recovery unless break-glass paths and restoration roles are pre-authorised and regularly tested.

There is also no universal standard for how granular identity dependency mapping should be yet. Current guidance suggests treating domain controllers, identity providers, certificate authorities, and privileged management planes as separately recoverable assets, but the exact boundary depends on your architecture. If the organisation uses cloud identity heavily, recovery planning must include tenant configuration, sync services, and conditional access dependencies, not only on-premises AD.

For organisations with a large service-account footprint, the control emphasis should shift from static inventory to continuous visibility and lifecycle management. That is where NHIMG’s OWASP NHI Top 10 and the 52 NHI Breaches Analysis help ground the discussion in real failure patterns: compromised identities, excessive privilege, and weak offboarding. DORA does not require one perfect operating model, but it does require evidence that the identity risk framework is living, tested, and improved after every significant event.

Related resources from NHI Mgmt Group

• Why does Active Directory Certificate Services increase identity risk?
• Why does Active Directory sprawl create more risk as organisations grow and acquire other businesses?
• What breaks when organisations leave default readable access on sensitive Active Directory groups?
• When does secret exposure become a broader identity risk?