TL;DR: Cyberattacks and outages increasingly force organisations to recover not just data but applications, cloud infrastructure, and directory services, according to Commvault. That shifts resilience from backup coverage to restoration of identity-dependent systems, immutable copies, and repeatable recovery paths.
At a glance
What this is: This is a vendor article arguing that cyber resilience now depends on recovering applications, cloud infrastructure and identity services, not just backed-up data.
Why it matters: It matters because IAM, NHI and cloud recovery teams need recovery paths for directory services, dependencies and configurations, or a clean backup still leaves the estate unusable.
Context
Cyber resilience is not only a backup problem. When applications, cloud resources and directory services are part of the business dependency chain, the recovery target becomes the full operating environment rather than a file set or database snapshot.
This article frames that shift through identity-dependent recovery, especially for Active Directory and cloud application estates. The operational gap is simple: if identity services and cloud configurations cannot be restored cleanly, the business may recover data but still remain offline.
The article is a product-led explanation of resilience scope, but the governance question is broader. Identity recovery, dependency mapping and configuration protection now sit inside the same programme boundary for cloud, IAM and NHI teams.
Key questions
A: Security teams should assume the normal network will be unavailable and design recovery to work offline. That means documented approval paths, offline contact lists, vendor contacts, shift schedules, and clear step by step actions for restoring identity services. The procedure should be tested regularly so responders can move quickly under pressure instead of losing time to confusion or missing access.
Q: What breaks when directory services are not included in recovery planning?
A: Applications can return with their data intact but still fail because authentication, authorization and trust relationships are missing. That creates a recovery gap where the business has assets but no usable operating environment. Directory services must therefore be treated as a continuity dependency, not just an infrastructure component.
Q: Why do cloud recoveries fail even when backups exist?
A: They fail when teams restore data without restoring the resource relationships and configuration state that make workloads functional. Cloud estates change quickly, so a restore point can be technically complete and still operationally wrong. Dependency mapping is what closes that gap.
Q: Should organisations prioritise immutable copies or dependency mapping first?
A: Both matter, but dependency mapping often determines whether an immutable copy is actually usable. Clean recovery points reduce tampering risk, while accurate dependency data ensures the restored environment works. If the goal is business continuity, the sequence and trust model of the restore matter as much as the storage medium.
Technical breakdown
Why identity services change the recovery model
Identity systems are control-plane dependencies. Applications, cloud resources and user access often fail together because they rely on directory services, service accounts, tokens and policy state to function. Recovering the data without the identity layer leaves applications technically present but operationally unreachable. In practice, recovery has to restore the relationships between identities, permissions, applications and infrastructure, not just the underlying content. That is why forest-level Active Directory recovery is a distinct operational problem rather than a routine backup task. The hard part is reconstituting trust and dependency order after the outage or attack has already broken them.
Practical implication: Map which services cannot start, authenticate or authorize without directory services or machine identities, then test recovery of those dependencies explicitly.
Cloud resource discovery and dependency mapping
Cloud recovery fails when teams do not know what must be rebuilt, in what order, and with which configuration state. Automated discovery and dependency mapping turn a loose inventory into a recoverable model by tying resources to their relationships, permissions and runtime dependencies. That matters because cloud estates change faster than static documentation and because configuration drift can make a restored workload unusable even when the data is intact. The operational objective is not just finding assets, but capturing enough dependency and configuration context to reproduce the working environment at a previous point in time.
Practical implication: Inventory critical cloud resources by dependency, then validate that recovery tooling can restore both configuration state and resource relationships.
Immutable recovery copies are a resilience control, not a storage feature
Immutable and indelible copies limit an attacker’s ability to tamper with recovery points, while portable copies reduce the risk of being trapped in a single recovery environment. Air-gapped storage adds separation from the primary source, which is useful when malware or destructive actions affect the live estate. The resilience value comes from preserving a clean recovery path that remains available even when production is compromised. For identity-dependent systems, that clean path must include the configuration and identity state needed to make recovered applications usable again, not just the data payload.
Practical implication: Ensure recovery copies are immutable, isolated and testable across the platforms where identity-dependent workloads actually run.
NHI Mgmt Group analysis
Identity recovery is now a core resilience control, not an auxiliary backup function. The article correctly shifts the frame from data protection to restoration of the systems that make data usable. That is especially important where Active Directory, cloud permissions and workload dependencies define whether a recovered environment can authenticate, authorize and operate. The practitioner implication is that resilience programmes must treat identity-state recovery as part of service continuity planning.
Dependency mapping is the difference between a restorable estate and an incomplete restore. Cloud-scale systems fail in recovery when teams lack a dependable model of resource relationships, configuration state and sequencing. The named concept here is identity dependency recovery gap: the operational gap between having a backup and being able to reassemble the identity-bound service chain. Practitioners should measure recovery against service function, not backup completion.
Immutability only matters if the clean copy can be brought back into a trusted environment. Air-gapped and immutable storage reduce tampering risk, but they do not by themselves solve restoration of trust relationships, directory state or cloud configuration. That distinction matters because cyber resilience is increasingly about replaying a known-good identity and infrastructure state, not simply retrieving preserved data. Teams should evaluate recovery architecture on operability, not storage semantics alone.
Forest-level Active Directory recovery remains a special case because directory services sit at the centre of business recovery. When identity infrastructure is down, many other systems are effectively down with it. The article’s emphasis on minutes rather than days reflects a reality IAM teams already know: directory recovery is a business continuity issue, not a narrow platform task. Practitioners should isolate directory recovery as a separate recovery design workstream.
Cloud recovery at scale is becoming an orchestration problem. The article’s focus on billions of objects and thousands of cloud resources shows that recovery is no longer a simple restore job. At this scale, the field’s real requirement is repeatable orchestration across identity, configuration and data state. Practitioners should assume that recovery quality now depends on automation depth and dependency fidelity, not on storage capacity alone.
What this signals
Identity dependency recovery gap: Recovery programmes often assume that if data is preserved, services can be restored. In reality, the restore point must include directory state, permissions and cloud configuration or the business still cannot operate.
Recovery fidelity is now a governance issue: Cloud-scale recovery is only credible when identity services, workload dependencies and configuration state are all testable together. That shifts resilience design into the same governance conversation as IAM, workload identity and configuration management.
For practitioners
- Map identity dependencies into recovery scopes Identify which business services depend on directory services, service accounts, tokens and cloud permissions, then include those dependencies in recovery runbooks and testing.
- Test forest-level directory recovery separately Run dedicated recovery exercises for Active Directory or equivalent directory services so the team validates ordering, trust reconstruction and service reauthentication.
- Validate cloud dependency mapping before a restore event Confirm that cloud discovery and dependency mapping capture the configuration state needed to restore applications, not just the object or data layer.
- Keep recovery copies immutable and isolated Store clean recovery points in immutable, air-gapped locations and verify that the recovery environment can operate without relying on the compromised primary estate.
Key takeaways
- Cyber resilience now depends on restoring the identity layer alongside applications and cloud infrastructure, not on data recovery alone.
- The hardest failure mode is partial recovery, where backups exist but authentication, authorization and service dependencies are missing or out of order.
- Practitioners should test directory services, cloud dependency maps and immutable recovery points as one recovery chain, because any break leaves the business offline.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Recovery depends on identity state being cleanly reset after outage or compromise. |
| NHI-05 — Overprivileged NHI | Recovery scenarios must account for permissions that can widen blast radius during restoration. | |
| Recommendation — Apply NHI-01 thinking to restore only current, valid identities and remove stale recovery-era access. Review recovered service accounts and workload permissions against least-privilege before re-enabling services. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on restoring the authorization state needed for applications to run. |
| RC.RP-01 — Recovery Plan Execution | The piece is about executing recovery across identity and cloud dependencies. | |
| Recommendation — Verify that restored systems have the correct entitlements before declaring recovery complete. Test recovery plans against identity-dependent services, not only data restoration steps. | ||
| MITRE ATT&CK | TA0040 — Impact | The core threat outcome is service disruption that prevents business operations from resuming. |
| Recommendation — Map identity and cloud recovery gaps to impact scenarios that prolong outage and business interruption. | ||
Key terms
- Identity Dependency Mapping: Identity dependency mapping is the process of tracing which accounts, groups, sync flows, and applications rely on one another to function. It is essential in hybrid estates because a seemingly inactive identity may still support production access. Without it, lifecycle actions can break services or leave hidden privilege in place.
- Forest-level Active Directory Recovery: The process of restoring an entire Active Directory forest, including its trust relationships and directory state. It is a high-dependency recovery exercise because many business systems rely on directory services to function after a major outage or attack.
- Immutable Recovery Copy: A backup or recovery snapshot that cannot be changed or deleted during its retention period. For identity infrastructure, immutability matters because it prevents an attacker with production access from corrupting the evidence or the restore point.
- Dependency Mapping: Dependency mapping is the process of identifying which systems, services, and workflows rely on a given identity or secret. It is critical for NHI rotation because teams need to know what will fail before they change credentials. Without it, security teams often delay remediation to avoid outages.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 9, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org