What should teams do when directory trust has been broadly damaged?

What “full identity recovery” means when trust is broken

When directory trust has been broadly damaged, the goal is not to restore the old state as quickly as possible. The objective is to re-establish a directory and trust fabric that can be trusted again, which means treating the environment as compromised until proven otherwise. That usually requires rebuilding core directory services, re-establishing trust paths deliberately, and validating every dependency before production use.

That shift matters because directory trust is the basis for authentication, authorization, administrative control, and many downstream enterprise services. If attackers still control any durable foothold in the directory layer, a rollback can simply reintroduce the same conditions that enabled compromise.

Why rollback is the wrong mental model

Rollback assumes the original configuration is still trustworthy enough to restore. Once directory trust has been broadly damaged, that assumption is usually false. Reverting objects, policies, or replication state can bring back hidden persistence, poisoned credentials, stale trust relationships, and compromised administrative paths.

Identity recovery is closer to controlled reconstruction than repair. Teams need to restore the directory in a sequence that preserves integrity, not convenience. That often means prioritising clean infrastructure, rebuilding privileged dependencies from known-good sources, and revalidating trust boundaries before users and systems are allowed back in.

When the compromise touches domain controllers, replication, or trust between domains and forests, the order of restoration becomes as important as the restoration itself. If the most trusted components are rebuilt from contaminated material, the attacker can return with the environment.

Rebuilding trust without bringing the attacker back

The recovery process should be designed around one question: what must be clean before anything else can safely trust it again? In practice, that means restoring from known-good backups or rebuild images, standing up clean domain controllers, and only then re-establishing trusts and administrative access paths.

Trust restoration should be explicit and verified, not implied by a successful reboot or directory sync. Any relationship that grants cross-system authority, delegated administration, or authentication confidence needs to be checked against the new baseline. That includes service dependencies, legacy trusts, and any account or system that had standing privilege during the incident.

Recovery also needs a clear boundary between rebuilding and reusing. Some identity data can be recovered, but not every trust relationship should survive the event. The practical test is whether the restored object or path could still be influenced by the original compromise. If the answer is unclear, it should be treated as unsafe until proven otherwise.

Risk and Threat Considerations

Directory compromise is dangerous because it can survive ordinary remediation. Attackers often aim to preserve authentication paths, delegated control, or trust relationships so they can regain access after reset efforts. A partial rollback can therefore recreate the same privilege paths that were already abused.

Failure mechanism: Restoring domain controllers, trust links, or replication state from contaminated sources can reintroduce malicious persistence, stale credentials, or poisoned trust relationships into the rebuilt environment.

Impact: The attacker may return immediately after recovery, retain privileged access, or use the recovered directory as a launch point for lateral movement and re-compromise.

Practitioner Guidance

What to prioritise: Treat the directory as a recovery program, not a change-management exercise. The first objective is to establish a clean trust root, then rebuild outward from the smallest trusted core rather than trying to preserve as much of the old state as possible.

What to verify: Confirm the source of every restored identity component, the order of domain controller rebuilds, and the integrity of every trust relationship before allowing production authentication. If a component cannot be proven clean, assume it is still part of the compromise.

Decision rule: If the compromised directory could have influenced authentication, authorization, or administrative trust, prefer rebuild and revalidation over rollback and selective repair.

Practitioner takeaway: The safest recovery is the one that makes trust explicit again, because in a broadly compromised directory, the old state is often the thing you are trying to escape.

Related resources from NHI Mgmt Group

• How should security teams govern Active Directory service accounts?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?