Who is accountable when identity services cannot be restored after a cyberattack?

Accountability should sit with the owners of identity operations, cyber recovery, and business continuity together, because AD outage affects all three. If restoration timelines are not defined and tested, no single team can credibly claim readiness when access services fail.

Why This Matters for Security Teams

When identity services fail after a cyberattack, the risk is not limited to sign-in downtime. It becomes a restoration problem, a control problem, and a business continuity problem at the same time. Identity services often sit underneath authentication, authorization, endpoint access, privileged admin workflows, and recovery tooling, so a prolonged outage can freeze both defenders and attackers in place. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal offboarding and revocation processes for API keys, which shows how often recovery depends on ad hoc human coordination rather than tested procedures.

This is why accountability cannot be left vague. Identity operations may own directory recovery, cyber recovery may own the secured rebuild path, and business continuity may own the service restoration objective, but each has a distinct duty that must be explicit before an incident. CISA’s cyber threat advisories repeatedly show that attackers target core trust services because they can create enterprise-wide disruption, not just local compromise. In practice, many security teams encounter recovery gaps only after directory services, trust stores, or privileged access paths have already been lost, rather than through intentional restoration testing.

How It Works in Practice

Accountability works best when it is assigned by recovery domain, not by org chart convenience. Identity operations should own the technical restoration of the identity plane, including directory services, federation, authentication policies, and trust anchors. Cyber recovery should own the clean-room rebuild, golden image integrity, backup validation, and evidence that restored identity systems are free of attacker persistence. Business continuity should own the service-level requirement for how long access can be unavailable before critical operations fail.

The operational answer usually includes three artefacts:

• A named restoration owner for identity infrastructure, with delegated authority to fail over or rebuild.
• A tested recovery time objective for identity services, aligned to business impact, not generic IT targets.
• A dependency map showing which applications, privileged workflows, and NHI systems fail if identity is down.

For non-human identities, this is especially important because service accounts, API keys, and workload identities may continue to exist even when the identity plane is impaired. NHIMG’s 52 NHI Breaches Analysis and OWASP NHI Top 10 both reinforce that identity failures and credential exposure often become intertwined during recovery, especially where secrets, tokens, and privileged automation are embedded in operational pipelines. NIST SP 800-53 Rev. 5 also treats contingency planning and access control as separate but connected control families, which supports clear ownership boundaries. These controls tend to break down when identity recovery depends on the same compromised administration path that was used before the attack because the rebuild is never truly isolated.

Common Variations and Edge Cases

Tighter restoration accountability often increases coordination overhead, requiring organisations to balance faster decision-making against more formal handoffs. That tradeoff matters because not every identity outage looks the same. A SaaS-based identity provider outage, an on-prem directory ransomware event, and a federation trust compromise all require different recovery owners, even if the business impact is similar. Best practice is evolving, but there is no universal standard for a single accountable role across all identity failure scenarios.

One common edge case is partial recovery. If user authentication is restored but privileged access management, machine-to-machine trust, or NHI token issuance is still broken, the business may appear “back up” while critical admin and automation paths remain unusable. Another edge case is split ownership across IT and security teams, where the directory team can restore service but only security can declare it trustworthy. That is where tabletop exercises matter most, because they reveal whether the organisation is restoring service or simply restarting compromised identity components.

For related governance context, NHIMG’s Why NHI Security Matters Now explains why identity dependencies are now enterprise-critical, and MITRE ATT&CK helps teams map how attackers abuse identity services before restoration is complete. The practical rule is simple: if no one is responsible for proving that identity is both restored and trusted, the organisation does not have recovery, only downtime with a login screen.

Related resources from NHI Mgmt Group

• Who is accountable if a recovery exercise shows that systems cannot be restored cleanly?
• Who should be accountable for service accounts and tokens after a compromise?
• Who is accountable for validating clean recovery points after an attack?
• Who should be accountable for resilience operating models in identity-heavy environments?