They should switch from change rollback to full identity recovery. That means rebuilding domain controllers in the right order, restoring trust relationships deliberately and using clean infrastructure so the attacker does not return with the restored environment.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Organization Users) | Directory recovery depends on restoring trusted non-human and service authentication paths. |
| IA-5 — Authenticator Management | Recovery must replace potentially compromised credentials and trust material. | |
| AC-6 — Least Privilege | Trust restoration should avoid restoring excessive administrative reach. | |
| Recommendation — Rebuild and validate service authentication paths before restoring directory trust. Rotate and reissue authenticators before re-enabling recovered directory services. Re-establish administrative access with least privilege before broadening trust. | ||
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan Executed | The question is about executing a recovery plan after directory compromise. |
| Recommendation — Execute the recovery plan in a controlled rebuild sequence. | ||
| ISO/IEC 27001:2022 | A.5.30 — ICT readiness for business continuity | Directory recovery requires resilient restoration and continuity planning. |
| A.8.13 — Information backup | Recovery depends on trustworthy backups and clean rebuild sources. | |
| Recommendation — Restore critical identity services through tested continuity procedures. Use verified clean backups or rebuild images for identity recovery. | ||
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.