How should security teams split responsibilities between AD recovery, ITDR, and access governance platforms?

Teams should assign each control to a different failure mode. Recovery restores the directory, ITDR detects abuse, and access governance removes stale or excessive entitlement risk. If one platform claims to cover all three, validate where it actually stops, then document who owns the missing handoff so incidents do not fall between teams.

Why This Matters for Security Teams

Splitting responsibility across AD recovery, ITDR, and access governance is not an organisational nicety. It is how teams prevent three very different failures from being handled as one problem. Recovery is about restoring directory integrity after outage or corruption. ITDR is about spotting abuse in motion. Access governance is about reducing standing entitlement risk before it becomes a blast radius.

When those boundaries blur, incident response becomes slower and post-incident reviews become more political than technical. A directory restoration runbook does not remove an over-privileged service account, and an access review platform does not detect an attacker moving through Kerberos tickets or federated trust paths. Current guidance from the NIST Cybersecurity Framework 2.0 is clear that resilient identity security depends on distinct control objectives, not one tool doing everything. The same separation principle appears across the Top 10 NHI Issues, where over-privilege, rotation gaps, and weak monitoring show up as separate risk drivers.

In practice, many security teams discover the split only after an account compromise or directory incident has already exposed missing handoffs between IAM, AD, and SOC operations.

How It Works in Practice

The cleanest operating model is to map each platform to a different failure mode and assign an owner for the handoff. AD recovery should sit with the directory or infrastructure team because it is about restoring controllers, trust relationships, replication health, and backup integrity. ITDR belongs with detection engineering or the SOC because it is about identifying suspicious authentication patterns, privilege escalation, delegation abuse, and anomalies in near real time. Access governance belongs with identity governance or IAM because it is about certification, role mining, entitlement cleanup, and policy enforcement.

That division works best when teams document what each tool can and cannot do. For example, access governance may find that a privileged group still exists, but it will not tell you whether a DC has been poisoned. ITDR may flag unusual ticket usage, but it will not restore authoritative directory state. Recovery tooling may bring AD back online, but it does not prove that post-restore accounts are still appropriate. The operational question is not which platform has the broadest dashboard, but where evidence is generated, where action is taken, and who closes the loop.

Useful practice includes:

• Defining recovery as a resilience function with tested restore points and named runbook owners.
• Defining ITDR as a detection and triage function with alert thresholds, telemetry sources, and escalation paths.
• Defining access governance as a preventive control with review cadence, exception handling, and entitlement approval workflows.
• Writing a RACI for break-glass, post-incident cleanup, and stale account removal so platform gaps are explicit.

The NHI lifecycle perspective in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because it frames identity controls as lifecycle tasks, not one-time configuration. That matters in environments where OWASP Non-Human Identity Top 10 issues such as stale credentials and excess privilege are treated as separate remediation streams. These controls tend to break down when a single platform is expected to detect compromise, rebuild trust, and approve access changes in the same maintenance window.

Common Variations and Edge Cases

Tighter separation of duties often increases coordination overhead, so organisations have to balance clear ownership against operational speed. That tradeoff becomes visible in smaller teams, mergers, or heavily outsourced environments where one vendor or one identity team is asked to cover all three functions.

There is no universal standard for this yet, but current guidance suggests that overlap is acceptable only when the handoff is still explicit. For example, a managed service can run ITDR detections and also support recovery, but it should still log which alerts trigger restoration, which require credential resets, and which require governance review. Similarly, some access governance platforms now surface risk signals, but that does not make them an ITDR substitute.

A practical edge case is hybrid identity, where AD, Entra ID, and federated SaaS access all interact. In those environments, recovery may start in AD but the real containment step may be disabling federation or revoking tokens elsewhere. Another edge case is emergency response, where security may need temporary privilege elevation to restore services. That should be handled as a documented exception, not as a reason to abandon least privilege. The 2024 ESG Report: Managing Non-Human Identities highlights how often organisations already suspect NHI compromise, which reinforces the need to keep detection, remediation, and entitlement control separate even when the same team coordinates them.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams use IAST and RASP in NHI governance?