Active Directory: the component your map should treat as critical infrastructure

An organisation has a documented disaster recovery plan. Critical applications are identified, servers are backed up and restoration procedures have been tested.

Then Active Directory is compromised.

The question becomes: can the information system actually be rebuilt in the order defined by the recovery plan?

Restoring a server does not necessarily mean it can be operated. A restored application may still depend on a service account, an Active Directory group, DNS, centralised authentication or an administration account.

Active Directory is therefore more than a directory. In many architectures it is a transverse dependency of the information system. ANSSI describes it as a critical component centralising permissions in Windows environments and notes that compromise can lead to complete control of the information system.4

For mapping, the consequence is clear: knowing where Active Directory sits is not enough. You need to know what depends on it.

Traditional maps hide identity dependencies

Infrastructure maps often represent:

site → network → server → application → database

But another architecture crosses these layers:

identity → authentication → authorisation → administration → service

An application can be correctly connected to its server, database, network and flows while also depending on an AD domain, security groups, service accounts, integrated DNS or administrator identities.

During normal operations these relationships can appear secondary. After compromise they become decisive.

Active Directory can sit at the heart of trust

In many Windows environments, the trust core is centred on Active Directory. If an attacker obtains sufficient privileges in the directory, they may be able to act on many components that trust it.

The problem is no longer simply “our Active Directory is compromised”, but “which components can we still consider trustworthy?”

Tier 0 changes how architecture is viewed

Tier 0 covers the components and identities with the highest privilege. It should not be reduced to domain controllers alone: the reasoning includes what can directly or indirectly control the trust core.

ANSSI has dedicated guidance to Tier 0 Active Directory remediation and rebuilding this trusted foundation.1

This creates a distinction between maps that describe what communicates with what and maps that also describe what can administer what.

A network flow and a trust relationship tell different stories

A security map should distinguish relationships such as:

A communicates with B

A authenticates to B

A administers B

A provides identity to B

A authorises access to B

A can change B's configuration

A flow shows a technical path. An administration relationship can show a path to control.

A recovery plan can contain an impossible recovery order

Imagine a plan that restores infrastructure, then databases, critical applications and finally user access.

Now suppose the hypervisor uses AD-linked authentication, administrators use domain accounts, applications rely on AD service accounts, DNS depends on Active Directory and backup consoles also use domain accounts.

The real order changes. Before restoring applications, the organisation needs a trusted foundation from which they can be administered without reintroducing compromise.2

Backing up Active Directory may not be enough

After a major compromise, the question is not only whether a backup exists. Teams need to determine when compromise occurred, which identities were used, which changes were made, what persistence may have been introduced and which components can still be trusted.

Restoring a state that was already compromised may restore the problem together with the service. ANSSI's work on incident investigation and qualification, published on 16 September 2026, underlines the importance of understanding the incident to guide response.5

Reconstruction is therefore not simply restoration. It is rebuilding trust.

Mapping can define the reconstruction order

A useful view can start from the trust core:

Tier 0 → identity → administration → infrastructure → application → business service

In an environment containing Active Directory, virtualisation, backup, SQL servers, an ERP and an HR application, a traditional map might show:

hypervisor → VM → SQL → ERP

A trust-dependency map may reveal:

Active Directory → administrator account → hypervisor

Active Directory → service account → SQL

Active Directory → authentication → ERP

Active Directory → DNS → applications

Active Directory → administrator account → backup

Recovery order can no longer be determined only from application dependencies.

Service accounts are often invisible dependencies

An application may look autonomous while using an Active Directory identity to access a database, run a Windows service, access a share, call an API or execute a scheduled task.

The useful relationship becomes:

application → service → technical identity → rights → resource

It answers two questions: what can this identity control if compromised? and what stops working if we reset it?

Administration dependencies go beyond Active Directory

Hybrid and cloud environments can also contain cloud identity providers, SaaS administration accounts, privileged cloud identities, automation secrets, bastions, PAM tools and central administration consoles.

The general question becomes: which components have the power to control other components in the information system?

Add a “trust and administration” view

IS maps traditionally include business, application, infrastructure and network views. Sensitive environments can benefit from another view: trust and administration dependencies.

It can represent directories, identity providers, privileged identities, critical service accounts, bastions, PAM, administration workstations, hypervisors, cloud consoles, backup tools, security tooling and administered systems.

The objective is not to inventory every user account. It is to identify relationships capable of materially changing the information system.

For organisations wishing to structure these dependencies in an IS mapping repository, Cartographit — published by Nixial, which also publishes Cybercoria — can connect IS objects, infrastructure and flows in a shared model. This link is provided as a complementary resource; it is neither an ANSSI recommendation nor evidence of compliance.

The compromise test

Select a trust-core component and ask: “If this component is fully compromised, what else should we consider potentially compromised with it?”

For Active Directory:

AD compromised → privileged accounts → administered systems → applications → business services

For a hypervisor:

hypervisor compromised → virtual machines → applications → data

For a cloud console:

privileged account compromised → cloud resources → data → services

For a backup platform:

administration compromised → backups → recovery capability

This creates a map of compromise blast radii that can support crisis preparation.

Seven questions to ask before an AD compromise

1. Do we know which applications depend on Active Directory to operate?
2. Do we know which service accounts are used by critical applications?
3. Do we know which components can administer Active Directory?
4. Do we know which components Active Directory can indirectly control?
5. Does our recovery plan distinguish restoration from rebuilding trust?
6. Do we know the reconstruction order after a Tier 0 compromise?
7. Can we visualise the blast radius of a privileged identity?

Map power, not only components

IS mapping traditionally asks: where is this application, which server runs it, and what does it communicate with?

Cyber resilience requires another question: who can control it?

Active Directory illustrates the difference. A directory may occupy only a few components on an infrastructure map while having an enormous dependency radius across the information system.

Incident remediation therefore requires more than backups. Organisations also need to know the order in which trust must be rebuilt — and that requires mapping dependencies before the incident.