Identity Resilience vs ITDR: Detecting Identity Attacks vs Recovering the Identity Plane

Identity threat detection and response (ITDR) tells you an attacker is abusing your directory or identity provider, but it cannot give you a trustworthy directory back once the attacker has owned it. Identity resilience is the separate capability to keep authentication working through outages and to rebuild Active Directory, the cloud identity provider (IdP) and the credentials of every human and non-human identity to a known good state. Organisations that buy ITDR often assume recovery is covered, and those with good backups often assume they would notice an attack in time. This guide compares the two: the threat model each addresses, how each is built, how each fails, how AD forest and IdP restore, break-glass access and machine credential re-establishment fit in, and a worked scenario. It is for identity architects, Active Directory and IdP owners, SOC leads and resilience managers.

Key takeaways

• ITDR is detect and contain; identity resilience is withstand and recover. In NIST CSF 2.0 terms, ITDR lives in Detect and Respond (DE.CM-03, DE.AE-02, RS.MI-01), identity resilience in Protect and Recover (PR.IR-03, PR.DS-11, RC.RP-01 to RC.RP-06).
• Containment has a ceiling. Disabling accounts and revoking sessions works while the directory is trustworthy. Once an attacker holds domain or tenant administrator rights, has run DCSync or forged tokens, the remedy is recovery, not more alerts.
• The restore point matters more than the restore speed. Microsoft's forest recovery guidance trades lost changes against reintroducing dangerous data and suggests a backup from a few days before the failure.
• Break-glass access is where the two meet. It must work when the IdP or directory is down, and ITDR must alert on every use.
• Machine identities are the long tail. A rebuilt directory with the same service account passwords, API keys and signing certificates leaves the attacker's stolen credentials valid.

The short answer

Invest in ITDR when the main question is "would we notice password spraying, Kerberoasting, MFA fatigue, token theft or a rogue federation trust, and could we contain it quickly?". Invest in identity resilience when the question is "if AD were encrypted, the IdP tenant misconfigured or every privileged credential exposed, how long until people and workloads could authenticate safely again?". Most organisations need both, because they fail in different ways: ITDR without resilience leads to an alert with no way back, and resilience without ITDR leads to restoring a backup that already contains the attacker.

The ITDR Guide and the Identity Recovery Guide cover each discipline on its own. This page covers the boundary: who owns what, where detection hands over to recovery, and what each needs from the other.

Side-by-side comparison

ITDR: threat model, architecture and failure modes

Threat model: an adversary holding or seeking valid credentials (ATT&CK T1078 Valid Accounts), escalating through the directory, and persisting through account changes (T1098 Account Manipulation), forged Kerberos tickets (T1558.001 Golden Ticket), service ticket cracking (T1558.003 Kerberoasting), replication abuse (T1003.006 DCSync) or forged SAML tokens (T1606.002). The joint ASD ACSC, CISA, NSA, NCSC-UK and partner guidance on detecting and mitigating Active Directory compromises addresses the 17 most common techniques used to compromise AD, and is the best public baseline for ITDR coverage.

Architecture in words: collectors on domain controllers and federation servers, plus API feeds from the IdP and cloud audit logs, stream identity events to an analytics layer that knows which accounts are privileged and which identities are machines. Detections fire on known techniques and on behaviour that departs from baseline. Response actions call the IdP and directory: disable, revoke sessions, force reset, remove a role. NCSC guidance asks organisations to log authentication and authorisation events and watch for failed MFA second steps, unexpected locations, password spraying and unexpected lockouts, which is the minimum signal set.

Failure modes:

• Containment through a compromised control plane: an attacker with domain admin or Global Administrator rights can re-enable accounts, add new ones and create alternative persistence faster than the SOC can remove it.
• Tokens and tickets outlive resets: forged golden tickets and stolen refresh tokens survive a password reset unless the krbtgt key is reset and sessions are revoked.
• Blind to machine identities: detections tuned on human sign-ins miss service principals, API keys and workload tokens behaving abnormally.
• Collectors die with the directory: if domain controllers are encrypted, sensors on them stop, and the evidence trail ends.
• No recovery path behind the alert: the SOC declares a tier 0 compromise and discovers there is no tested way to rebuild.

How ITDR differs from posture tooling and adjacent detection stacks is covered in ISPM vs ITDR and ITDR vs SIEM.

Identity resilience: threat model, architecture and failure modes

Threat model: the identity plane becomes unavailable or untrustworthy. Causes include a provider outage, a destructive attack on domain controllers, a mass deletion, a damaging Conditional Access or federation change, and a full compromise where every privileged secret must be assumed known. Microsoft separates resilience, the ability to endure disruption with low business impact, from recoverability, the preparations to return to a prior working state after an unintended change.

Architecture in words: for on-premises AD, regular system state backups of at least two writable domain controllers per domain, held offline or immutable and outside the domain's own admin control, plus a dedicated restore DC per domain where possible. For the cloud IdP, versioned exports of configuration to an external repository, because, taking Microsoft Entra ID as the worked example, Microsoft states that soft-deleted users, Microsoft 365 groups, cloud security groups and applications stay in the recycle bin for 30 days while other object types are hard deleted immediately, and misconfigurations change objects in place. A clean recovery environment, cloud-only emergency accounts that do not depend on federation or sync, an offline inventory of every non-human credential and where it is used, and written runbooks complete the picture.

Failure modes:

• Backups inside the blast radius: backup servers joined to the domain they protect, managed by the same admin group.
• Restoring the compromise: choosing the newest backup, which already contains the attacker's accounts, delegations, AdminSDHolder changes or rogue certificate templates.
• Configuration drift with no known good state: tenant policies changed by hand over years, so there is nothing to reapply after a misconfiguration.
• Break-glass that depends on what broke: emergency accounts synchronised from AD or subject to MFA methods tied to the IdP that is down.
• Forgotten machine credentials: gMSAs, service accounts, application secrets, federation signing certificates and CI/CD tokens left valid after a rebuild.

Where detection hands over to recovery

The most important design decision is the line at which ITDR containment stops being enough and the incident becomes an identity recovery. Write it down in advance, with the people who can declare it.

The incident handling steps around this table are in the Identity Incident Response Playbook; ticket forgery and DCSync detail is in the Golden Ticket, Silver Ticket and DCSync Guide.

AD forest and IdP restore: what resilience must have ready

Microsoft's AD forest recovery guidance (applicable to Windows Server 2016 to 2025) sets out the pieces resilience teams must prepare before an incident, not during one.

• Trusted backup selection: backups of at least two writable DCs per domain; mount and compare backups with Dsamain.exe and an LDAP browser to find the last safe state; backup lifetime is bounded by the tombstone or deleted object lifetime, whichever is less. Archive the Administrator and DSRM password history for that period.
• Isolation: shut down writable DCs, or keep the restored DC on an isolated network, so dangerous data does not replicate back.
• Initial recovery order: restore AD DS non-authoritatively and SYSVOL authoritatively on the first forest root DC, verify, reset administrative passwords if compromise is suspected, seize operations master roles, clean up metadata of other DCs, configure DNS, raise the RID pool (Microsoft cites 100,000), reset the DC computer account password twice and the krbtgt password twice, because the krbtgt password history holds two passwords.
• Compromise extras: reset trust passwords when recovery follows a breach, and if a DC database was compromised create a new KDS root key and re-create gMSAs.

The step-by-step runbook is in the Active Directory Forest Recovery Runbook Template, and the krbtgt procedure in the krbtgt account guide.

For the cloud IdP, resilience means a documented known good state in an external, versioned repository, rehearsed restores in a test tenant, and preventive controls on destructive actions. Taking Entra ID as the worked example, Microsoft lists least-privilege object-specific roles, just-in-time elevation and protected actions for sensitive operations such as hard deletion and Conditional Access changes. Export and restore options for the main IdPs are compared in IdP configuration backup and restore for Entra ID and Okta.

Break-glass access: shared ground

Break-glass accounts are a resilience control that ITDR must watch. Microsoft's emergency access guidance gives a concrete baseline that applies in principle to any IdP:

• Two or more accounts, cloud-only, not federated or synchronised, with on-premises and cloud emergency access kept independent.
• Phishing-resistant authentication (passkey or FIDO2 key, or certificate-based authentication) different from normal admin methods, not tied to one person's phone.
• Excluded from blocking Conditional Access policies through a dedicated group, so they work in the emergency they exist for.
• Critical-severity alert on any sign-in, with logs preserved and a post-use review to decide whether it was a drill, a real emergency or misuse.
• Tested at least every 90 days and after staff or subscription changes.

Resilience owns the accounts and their tests; ITDR owns the alert and the investigation of each use. See the Break-Glass Account Guide.

Re-establishing non-human identity credentials

After a confirmed identity plane compromise, every machine credential the attacker could have read is suspect: service account passwords, gMSA keys, application client secrets and certificates, federation and token signing keys, API keys, SSH keys and pipeline tokens. ITDR might detect use of one; only a planned re-establishment removes them all.

1. Inventory before the incident: keep an offline list of each non-human identity, its owner, the systems that consume it and how to rotate it.
2. Order by privilege: tier 0 first (krbtgt, DC computer accounts, federation signing, identity sync accounts, backup service accounts), then credentials with write access to production, then the rest.
3. Rotate, do not just reset: issue new secrets and update consumers, then revoke the old ones; where possible replace static secrets with workload identity. See Secret Rotation vs Revocation.
4. Verify: watch for authentication failures that show missed consumers and for any use of revoked credentials, which indicates attacker activity.

The Cloudflare Thanksgiving Breach 2023 illustrates the lesson: one service token and three service account credentials not rotated after an earlier third-party breach gave an attacker access weeks later, and the eventual response rotated more than 5,000 production credentials. The organisation-wide procedure is in the Enterprise Credential Reset Runbook Template.

Worked scenario: hybrid identity compromise

A hypothetical manufacturer runs a single-domain AD forest synchronised to a cloud IdP. ITDR flags replication requests from a workstation, consistent with DCSync, followed by a new account added to a privileged group.

1. Containment (ITDR): the SOC disables the new account, isolates the workstation and revokes sessions for privileged users. Within an hour the account reappears under another name: the attacker still holds domain admin rights.
2. Declaration: under the pre-agreed threshold (DCSync observed), the incident lead declares an identity recovery. Containment continues, but the goal changes.
3. Cloud first: the identity team signs in with cloud-only break-glass accounts, pauses directory sync, checks tenant federation and app credentials against the last versioned export and revokes all refresh tokens.
4. Directory decision: ITDR telemetry and investigation date the first malicious replication to nine days earlier. The team rejects in-place clean-up and restores the forest in isolation from a backup taken eleven days before, performing the krbtgt, computer account and trust resets in the documented order.
5. Machine credentials: from the offline inventory, tier 0 and production service credentials are rotated before the restored DCs reconnect to workloads.
6. Return to monitoring: ITDR sensors are redeployed on the restored DCs with heightened detections for the attacker's known techniques, and break-glass sign-ins during the incident are reviewed.

Without ITDR the team would not know the restore point; without resilience preparation it would have had nowhere to go after containment failed.

Decision guidance

Implementation: a phased approach

1. Agree ownership and the declaration threshold between SOC, identity and continuity teams, using the hand-over table.
2. Secure the copies: isolate AD backups from the domain, export IdP configuration to a versioned external repository, and keep offline runbooks and credential inventories.
3. Stand up break-glass accounts with alerts, then test them.
4. Deploy ITDR coverage for priority techniques on DCs, federation servers and IdP logs, including non-human identities.
5. Rehearse: restore a domain into an isolated lab, restore objects in a test tenant, run a credential rotation drill for one application. Measure each.
6. Test the hand-over: run a purple-team exercise that ends with a recovery declaration, and fix what breaks. Roll back exercise changes from the lab only; never point a test restore at production networks.

Detection and measurement

• ITDR signals that also protect recovery: backup deletion or retention changes for DC backups, changes to emergency accounts or their exclusion group, directory sync configuration changes, new federation trusts and protected action changes.
• Metrics:
  • Mean time to detect and to contain priority identity techniques.
  • Measured time to restore one domain in isolation, from the last rehearsal.
  • Age of the last versioned IdP configuration export (target under a day).
  • Days since each break-glass account was last tested (target under 90).
  • Percentage of tier 0 non-human credentials with a documented rotation procedure and owner.

Common failure patterns

• Treating containment as recovery: repeated account disables while the attacker keeps domain admin rights.
• One krbtgt reset: leaving the previous key in history, so forged tickets remain valid.
• Restoring the newest backup without using detection data to date the compromise.
• Break-glass accounts synced from AD or bound to the IdP MFA that failed.
• Rebuilding people, not machines: users reset, service accounts and signing keys left untouched.
• Separate playbooks that never meet: SOC and identity teams with no shared threshold or runbook.

Framework mapping

Practitioner checklist

• Define the evidence that turns an ITDR incident into an identity recovery, and who declares it.
• Back up at least two writable DCs per domain to storage the domain's admins cannot alter.
• Export IdP configuration to a versioned external repository and rehearse restores in a test tenant.
• Keep two or more cloud-only, phishing-resistant break-glass accounts, alerted on every use and tested every 90 days.
• Use ITDR and investigation data to choose the restore point.
• Reset krbtgt twice and reset trust passwords after any compromise recovery.
• Maintain an offline inventory of non-human credentials with owners and rotation steps.
• Monitor backups, sync configuration and emergency accounts as tier 0 assets.
• Run a joint SOC and identity exercise that ends in a recovery.

Standards and references

• Microsoft: Active Directory Forest Recovery Guide
• Microsoft: AD Forest Recovery, Perform initial recovery
• Microsoft: Recoverability best practices in Microsoft Entra ID
• Microsoft: Manage emergency access admin accounts in Microsoft Entra ID
• CISA and partners: Detecting and Mitigating Active Directory Compromises
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations
• NIST: Cybersecurity Framework 2.0
• NCSC: 10 Steps, Identity and access management

Related NHI Mgmt Group resources: ITDR Guide, Identity Recovery Guide, Identity Incident Response Playbook, Disaster Recovery vs High Availability and Mass Password Reset Playbook.