The Attacker Is Not After Your Data. They Are After Your Recovery Path.
Ransomware resilience architecture begins where backup ends. Most organizations have built the protection layer — snapshots running, backup jobs completing, retention policies configured. What they have not built is the layer that survives after an attacker has spent four days inside the environment mapping exactly which systems to destroy before detonating.
In 2025, Mandiant documented a systemic shift in ransomware operator behavior: attackers are no longer primarily focused on encrypting data. They are focused on denying recovery. Backup infrastructure, identity services, and virtualization management planes are now primary targets — deliberately compromised or destroyed before encryption runs. The goal is not to take your data. The goal is to make restoration impossible.
This changes the architecture required to survive. An organization with excellent backups and no isolated recovery plane is not protected — it is a target with a false sense of security. Ransomware resilience architecture is the design discipline that closes the gap between “backups exist” and “recovery is guaranteed under adversarial conditions.”
The Mental Model Reset
The architecture that fails under ransomware is not poorly built. It is built for the wrong threat model. Every assumption below is standard practice. Every reality below is how organizations end up unable to recover.
| Assumption | Reality |
|---|---|
| Ransomware targets data | Ransomware targets your recovery path — data encryption is the final step, not the objective |
| Backups equal protection | Backups are the primary attack surface — 96% of ransomware attacks target them specifically |
| Immutability means safe | Immutability at the storage layer is bypassed by operating at the identity and management plane layers above it |
| DR ensures recovery | DR replicates state — including compromised state. DR solves availability. Ransomware is an integrity problem. |
| Paying the ransom restores data | 4% of organizations that pay recover all data. Architecture is the only reliable recovery path. |
| Green dashboard means protected | Backup job success does not validate recovery path integrity. A catalog can be deleted after a successful backup job. |
The Ransomware Survival Model: Three Planes
Ransomware resilience architecture is organized around three planes. Every design decision — identity isolation, immutability implementation, recovery sequencing — maps to one of these three planes. The gap in most architectures is not the Protection Plane. It is the Recovery Plane.
The Compromise Plane is where the attacker operates. Initial access, privilege escalation, lateral movement, backup targeting, catalog deletion — this is the adversarial environment. It includes your production workloads, your identity systems, and — critically — your backup management consoles and orchestration platforms if they share credentials with production.
The Protection Plane is where your backup copies live. Snapshots, backup jobs, replication, object storage. Most organizations have this plane. Most consider it sufficient. The problem: if the Compromise Plane reaches the Protection Plane — through shared credentials, reachable API endpoints, or connected management networks — the Protection Plane is not a survival layer. It is an extension of the attack surface.
The Recovery Plane is the isolated, tested, trusted path back to production. Independent identity. Network isolation. Clean room compute. Application-layer validation before reconnection. This is the plane most architectures have never built. It is also the only plane that guarantees recovery after full control plane compromise.
The architecture question is not “do we have backups?” It is “does our Recovery Plane exist independently of anything the attacker can reach?” The full three-plane model — Data Plane, Protection Plane, and Recovery Plane — is the foundation of the Data Protection Architecture pillar. This page covers the adversarial layer on top of it.
What Ransomware Actually Targets
The attack does not start with encryption. It starts with reconnaissance.
Modern ransomware operators conduct structured pre-detonation reconnaissance that targets one thing above all others: the recovery path. Before a single file is encrypted, sophisticated ransomware groups map your backup infrastructure, identify your management plane credentials, locate your retention policies, and catalog your recovery dependencies. They are not looking for your data. They are looking for the systems you would use to recover from losing it.
The attack sequence is consistent across documented incidents:
Credential Compromise — initial access via phishing, exploited vulnerability, or stolen credentials. The attacker is inside but not yet visible. Median time to first lateral movement after initial access: under 70 minutes (Mandiant M-Trends 2026).
Privilege Escalation — lateral movement toward domain admin or equivalent. Backup admin accounts are a primary target because they combine high privilege with lower monitoring density than production admin accounts.
Backup Targeting — the attacker identifies backup orchestration systems, management consoles, and storage endpoints. This is reconnaissance, not yet destruction. The attacker is mapping the recovery path before severing it.
Catalog Deletion and Retention Manipulation — backup catalogs are deleted, retention windows are shortened, snapshot schedules are disabled. Recovery points are destroyed or made unrestorable while production appears normal. This step happens silently, days before encryption.
Recovery Path Destruction — any remaining recovery dependencies are severed. Identity systems that control recovery access are compromised or locked. Management plane access is revoked or corrupted.
Encryption Event — production data is encrypted. By this point, the organization has no recovery path. The ransom demand is not “pay us or lose your data.” It is “pay us or rebuild from nothing.”
The architectural implication is precise: the window to build ransomware resilience architecture is before any of these stages begin. Once the attacker is inside with backup admin credentials, the architecture is already failing.
The Six Attack Patterns That Defeat Standard Backup
Standard backup architecture is designed for accidental failure. These six patterns are how ransomware operators defeat it. Each targets a different layer of the protection stack. An architecture resilient against one is not resilient against all six.
The Control Plane Is the Target
The single most important reframe in ransomware resilience architecture: the attacker is not attacking storage. They are attacking the control systems that manage storage.
Object Lock prevents a storage object from being deleted. It does not prevent the backup software from being configured to stop writing new objects. It does not prevent the catalog from being deleted. It does not prevent the management console from being used to disable the backup schedule. The storage layer is protected. The three control layers above it are not.
Backup catalog deletion is the most common control plane attack because it is the most efficient. The backup data physically exists. The recovery path to it is destroyed. Without the catalog, the backup software cannot locate, verify, or restore from the backup storage. From a recovery standpoint, the result is identical to having no backups at all.
Retention manipulation is more patient. The attacker does not need to delete anything — they modify the retention policy configuration to a short window, then wait. The backup system’s own automated cleanup process destroys the recovery points. No manual deletion. No forensic signature of an attacker touching backup data. The organization’s own infrastructure executes the attack.
API abuse completes the picture. Modern backup platforms expose API endpoints for management operations. If the service account token that authenticates to those APIs is stored in the same credential vault as production secrets — which it usually is — credential compromise is management plane compromise.
The control plane attack surface for any backup architecture is: the catalog, the retention policy configuration, the schedule configuration, the API authentication layer, and the management console access model. Protecting the storage layer without protecting these five control points is architectural theater.
Identity Is the Blast Radius Boundary
Ransomware does not break storage. It logs in.
The blast radius of any ransomware incident is defined by the identity architecture, not the network architecture. An attacker with domain admin credentials can reach everything that domain admin can reach — including backup orchestration systems, management consoles, cloud storage APIs, and DR management planes — regardless of network segmentation. Identity is the perimeter. When identity collapses, everything that shares that identity collapses with it.
Ransomware resilience architecture requires three separate identity planes that do not share credentials, trust relationships, or authentication infrastructure.
Production Identity is the AD forest, IAM structure, or IdP that governs production workloads and the humans and services that operate them. When ransomware compromises the environment, this plane is fully compromised. It should be treated as untrusted from the moment a ransomware incident is declared.
Backup Identity governs backup admin accounts, service accounts that authenticate backup jobs, and the API tokens that backup software uses to access storage endpoints. This plane must not share credentials, groups, or trust relationships with Production Identity. If a domain admin account can authenticate to the backup platform, the Backup Identity plane does not exist — there is only one plane, and it is compromised.
Recovery Identity is the minimal, independent identity source that governs the recovery environment. A separate AD forest with no trust to the production forest. A standalone IdP. Or in an air-gapped recovery scenario, local accounts with no network-reachable authentication path. This plane must not be reachable by any credential that existed in the compromised production environment.
The three controls that define whether identity isolation is real:
Separate identity planes — backup admin credentials must not exist in the same identity provider as production admin credentials. If your AD is compromised, your backup console must require a credential that was never in that AD.
MFA on all deletion and modification operations — not just login. Every snapshot deletion, retention policy change, and catalog modification requires a second factor that is not stored in the compromised environment. Login MFA without operation-level MFA is insufficient against an attacker who owns an authenticated session.
Role separation at the API layer — the service account that runs backup jobs must not have the rights to modify retention policies or delete catalog entries. Write access and delete access are different permissions that backup platforms separate by design. Most deployment teams never configure the separation.
The identity plane architecture that makes immutability real — credential separation, API-level deletion controls, and separate identity for the recovery environment — is the difference between a backup architecture that looks ransomware-resilient and one that actually is.
Immutability Architecture: Where It Breaks
Object Lock is not immutability architecture. It is the storage layer of immutability architecture — one of five layers, and the one furthest from where attackers operate.
The immutability illusion: storage is protected, the system is not. An attacker does not need to delete a protected storage object. They need to operate at the management plane or identity layer — two or three levels above the storage — to make the protected storage unreachable, uncatalogued, or unrestorable without touching the storage itself.
The five layers of immutability, and where each breaks:
Layer 1 — Storage (Object Lock / WORM): Prevents deletion or modification of stored data objects during the retention window. This layer works. Attackers rarely attack it directly. It is bypassed by operating at higher layers.
Layer 2 — Retention Policy Configuration: Governs the rules that determine when Object Lock windows are set and what retention periods are applied. If this layer is reachable by compromised admin credentials, retention windows can be shortened to zero — causing the storage layer protection to expire and be deleted by automated cleanup.
Layer 3 — Backup Software and Catalog: The index and orchestration layer. If the catalog is deleted, the storage is unreachable for restore operations regardless of Object Lock status. The software layer sits above the storage layer and can make protected storage operationally inaccessible.
Layer 4 — Management Plane: The hypervisor or HCI management system. A compromised management plane can disable backup schedules, delete snapshot configurations, and remove the jobs that write to the protected storage — all without touching the storage directly.
Layer 5 — Identity: Admin credentials. If the attacker has them, all four layers above the storage layer are accessible. Object Lock is the only thing standing between the attacker and complete recovery path destruction — and it only holds if the retention window was set correctly before the compromise began.
Real immutability architecture enforces protection at every layer: storage-layer Object Lock, API authentication for retention policy changes, catalog backup independent of the primary backup system, management plane isolation, and identity separation. Enforcing only the storage layer while leaving the four control layers above it unprotected is not immutability. It is the appearance of immutability.
The five-layer immutability model covers the specific implementation controls at each layer and the audit tests that validate whether each layer is actually enforced or merely configured.
The Recovery Path Is the Architecture
Recovery is a system, not an event. Most disaster recovery plans describe what to recover. Almost none describe the environment recovery happens into — and that environment is where ransomware incidents produce recoveries that fail.
A restore that completes successfully but reconnects the recovered workload to a still-compromised network is not a recovery. It is a re-infection that consumes the clean backup copy and destroys the last viable recovery point.
The recovery path that survives adversarial conditions requires four components built before the incident occurs.
Clean room environment — isolated compute and network with no path to the production environment or its identity systems. This is where recovery happens. No workload is reconnected to production until it has been validated in the clean room. The clean room cannot be provisioned during the incident — under incident pressure, with production down and executives watching, there is no time to design network isolation from scratch.
Independent identity bootstrap — a minimal identity source that exists independently of the production identity plane. Local accounts or a standalone IdP that was never joined to the production AD forest. Certificate authorities and secret stores that were provisioned separately and never synchronized with production secrets. If your recovery environment needs to authenticate against the compromised identity system to boot the restored workloads, the recovery path fails before the first VM starts.
Staged restore sequence — not all workloads come back simultaneously. Database tier before application tier. Application tier health-checked before web tier. DNS updated only after the application stack passes a defined health check. The sequence is the DR plan. An undocumented sequence means the sequencing happens ad hoc under incident pressure, by engineers who haven’t slept in two days.
Application-layer validation before reconnect — every restored workload is validated at the application level, not the VM level, before network paths to production are re-established. A VM that boots is not a recovered application. An application that passes a defined health check — query response, API round-trip, transaction throughput — is.
What most teams miss:
The identity bootstrap is the most commonly absent component. Teams provision the clean room compute and network isolation correctly, then discover that every restored VM requires an AD domain join to function — and the only AD forest is the compromised one. The recovery environment must include a minimal directory service that restored workloads can authenticate against independently.
Dependency mapping is the second gap. Restored workloads have dependencies on other services — DNS, NTP, certificate authorities, secrets management, database connections. In production, these are resolved automatically. In a clean room, they must be resolved manually in the correct order. Without a dependency map, recovery stalls when an application tier cannot resolve a dependency that wasn’t provisioned yet.
The RTO Reality post covers why recovery drills are the only way to validate this architecture before the incident. The RTO, RPO, and RTA framework covers how to use recovery metrics as architectural inputs — not post-incident measurements.
Why DR Fails Under Ransomware
DR solves an availability problem. Ransomware is an integrity problem. This distinction is architectural, not semantic — and it determines whether your DR investment helps or hurts you in a ransomware incident.
DR replication produces a consistent copy of your production environment. That is its value and its failure mode under ransomware. A DR replica is consistent with the production state at the time of replication. If that production state includes four days of attacker dwell time, retention policy manipulation, backup catalog deletion, and pre-encryption staging activity — the DR replica faithfully replicates all of it.
When encryption runs and you failover to DR, you are not recovering to a clean state. You are recovering to the compromised state the attacker prepared before detonation.
| Recovery Scenario | DR Replication | Isolated Backup Tier |
|---|---|---|
| Hardware failure | ✓ Effective — clean failover | ✓ Effective |
| Accidental deletion | ✓ Effective with point-in-time | ✓ Effective |
| Regional outage | ✓ Effective | ✓ Effective |
| Ransomware — encryption only | ✗ May replicate pre-encryption state | ✓ Effective if retention window predates compromise |
| Ransomware — catalog + retention manipulation | ✗ Replicates compromised state | ✓ Effective only if backup tier is identity-isolated |
| Full control plane compromise | ✗ DR management plane may also be compromised | ✓ Effective only with air-gapped tier |
DR is not a substitute for ransomware resilience architecture. It is a component of an availability strategy that operates alongside a separate integrity strategy. The architecture that survives ransomware has both — and treats them as solving different problems.
The Disaster Recovery & Failover sub-page covers the full DR architecture — failover logic, RTO sequencing, and the network architecture for multi-site environments. This page covers what DR cannot do.
Platform Architecture: What Actually Matters
Platform selection is a blast radius decision as much as a feature decision. The question is not which backup platform has the best deduplication ratio or the fastest restore SLA under normal conditions. The question is which architecture survives when the attacker already has admin credentials.
The two capabilities that differentiate platforms under adversarial conditions are control plane isolation and immutability enforcement model. Everything else — performance, cloud integration, licensing model — is secondary to whether the platform can survive a compromised production environment.
Control plane isolation determines whether the backup platform’s management layer is reachable from a compromised production environment. Platforms that run management infrastructure inside the production environment — as VMs on the same hypervisor, authenticated through the same AD, reachable on the same management network — are part of the Compromise Plane by default. Platforms with external, hardened security cloud management planes or physically separate management infrastructure create a boundary the attacker must cross separately.
Immutability enforcement model determines where immutability is enforced and whether it can be bypassed through the platform’s own management layer. The distinction that matters: immutability enforced at the storage layer only (Object Lock via the platform’s API) versus immutability enforced at the platform layer with independent key management and deletion controls that require out-of-band authentication.
Against Rubrik and Cohesity — the two dominant enterprise platforms in this space — the architectural differences map directly to these two criteria.
Rubrik’s Security Cloud model moves management infrastructure outside the customer environment. Deletion of backup data requires multi-party authorization through the Security Cloud management plane, which is not reachable from a compromised on-premises environment. This is control plane isolation implemented at the product architecture level.
Cohesity’s DataProtect with DataHawk adds threat intelligence and anomaly detection at the data layer, identifying behavioral signals of ransomware staging activity before detonation. The immutability model uses SpanFS with configurable retention locks, but the management plane runs inside the customer environment in most deployments — which means management plane isolation requires additional architecture work.
Neither platform eliminates the need for identity isolation, air-gapped recovery tiers, or tested recovery sequences. Platform selection determines how much of the architecture the platform contributes versus how much you must build around it.
The Rubrik vs Cohesity architecture comparison covers the control plane scaling, failure modes, and recovery workflow differences in full. The immutability architecture post covers the platform-agnostic layer model that applies regardless of which platform you select.
The Cost of Ransomware Failure
Ransomware resilience architecture has a cost. The cost of not building it is larger, and it arrives under the worst possible conditions.
The cost model for ransomware incidents inverts under failure in the same way backup cost physics invert during recovery. The investments that looked optional during steady-state operations — isolated recovery environments, separate identity infrastructure, tested recovery sequences — become the only things that determine whether the organization survives.
Downtime cost is the immediate operational impact. Healthcare organizations average $2.57 million in recovery costs per incident (Sophos 2024). Government entities average $2.83 million. The median recovery cost across all industries is $1.53 million — excluding the ransom. Full operational restoration takes a median of 100 days regardless of payment (Sophos 2024). One hundred days of degraded operations at any enterprise scale produces costs that dwarf the architecture investment required to survive in hours instead.
Recovery cost shock arrives specifically when the backup architecture was built without modeling failure-state egress. Organizations with cloud object storage backup tiers discover during an active incident that restoring hundreds of terabytes at incident speed generates egress charges that were never in the budget — and that cost approval processes under active ransomware pressure can extend the recovery timeline by days. The backup rehydration post covers the deduplication economics that compound this — storage that looks efficient at rest becomes a recovery performance bottleneck at scale.
Regulatory and contractual exposure compounds downtime cost. Missed RTO/RPO SLAs trigger contract penalties. Data breach notification requirements impose their own timelines and costs. Regulatory frameworks with mandatory recovery time requirements — PCI-DSS, HIPAA, DORA — impose fines for failures to meet documented recovery objectives. An architecture that cannot meet its documented RTO under adversarial conditions is a compliance liability as much as an operational one.
Re-attack exposure closes the loop. 80% of organizations that pay a ransom are attacked again within 12 months (Fortinet). Paying does not resolve the architectural gaps that enabled the initial compromise. It funds the next attack while leaving the vulnerabilities intact.
The architecture investment required to build three identity planes, an isolated recovery environment, and tested restore sequences is measurable and bounded. The cost of not building it — downtime, recovery operations, regulatory exposure, re-attack — is unbounded and arrives when the organization is least equipped to absorb it.
Decision Framework
| Threat Scenario | Architecture Requirement | Risk If Not Built |
|---|---|---|
| Credential compromise | Separate Backup Identity plane — no shared credentials with production | Complete Protection Plane loss — attacker owns backup admin |
| Catalog deletion | Catalog backup independent of primary backup system; MFA on deletion operations | Recovery path destroyed with no forensic trace |
| Retention manipulation | Retention policy changes require out-of-band authentication; API deletion controls | Automated cleanup purges recovery points — attacker never touches data |
| Management plane takeover | Backup management plane isolated from production hypervisor management | All Tier 1 snapshots destroyed simultaneously across all managed workloads |
| Replication poisoning | Independent backup tier separate from replication; air-gapped copy with retention predating compromise window | DR failover recovers to compromised state |
| Full control plane compromise | Air-gapped recovery tier; Recovery Identity plane; clean room environment | No viable recovery path — rebuild from nothing or pay |
| Recovery re-infection | Clean room environment; no network path from recovery to production until application-layer validation | Successful restore reconnects to active threat |
| Egress cost shock | Recovery egress modeled at incident scale before incident occurs | Recovery timeline extended by cost approvals during active incident |
| Compliance / audit | Tested recovery with documented RTO/RPO evidence | Regulatory penalties for missed recovery commitments |
Recovery Confidence
Recovery confidence is not the existence of backups. It is not the last successful backup job timestamp. It is not the green dashboard, the retention policy configuration, or the Object Lock status on the storage tier.
Recovery confidence is a measurable state produced by four verifiable conditions. If any one is absent, confidence is assumed, not proven.
Tested restore — a recovery from backup has been executed against a real workload in the last 90 days. Not a metadata validation. Not a synthetic full verification. An actual restore of production data to a functional, application-validated state.
Isolated recovery environment — the restore was executed in an environment with no network path to production and no identity dependency on the production identity plane. A restore that uses production DNS, production AD, or production network paths is not a test of ransomware survivability.
Application-layer validation — the restored workload was validated at the application level. Query response, API round-trip, transaction throughput. Not VM boot. Not OS login. Application function.
Documented recovery sequence — the order of operations, dependencies, authentication sources, and validation checkpoints are written down and have been executed by someone other than the person who wrote them. A recovery sequence that only one engineer knows is not a recovery plan. It is a single point of failure wearing the costume of a plan.
Most organizations achieve the first condition occasionally. Few achieve all four consistently. The gap between “we have backups” and “we have recovery confidence” is precisely the gap ransomware operators exploit.
Architect’s Verdict
Most organizations are not losing to ransomware because their backup jobs failed. They are losing because the architecture they built assumes a threat model that ransomware operators abandoned years ago.
The old threat model: hardware fails, data is lost, you restore from backup. The current threat model: attackers spend days inside your environment specifically destroying the recovery path before encryption runs, then present you with the choice between paying and rebuilding from nothing.
Ransomware resilience architecture is the discipline that closes the gap between those two threat models. It is built from three planes — Compromise, Protection, Recovery — and the Recovery Plane is the only one that guarantees survival after full control plane compromise. It requires three identity planes that do not share credentials or trust relationships. It requires immutability enforced at every control layer, not just the storage layer. It requires a recovery path that was built, isolated, and tested before the incident that demands it.
Recovery confidence is not assumed. It is produced by tested restores, isolated environments, application-layer validation, and documented sequences. The only way to know whether your architecture produces it is to test the recovery — not the backup.
The 4% of organizations that pay ransom and recover all their data are not lucky. They were built differently before the attack began.
If you are building fluency across the full discipline — backup mechanics, immutability enforcement, disaster recovery sequencing, and business continuity — the Data Protection & Resiliency Learning Path maps the structured progression through all five execution domains.
Cybersecurity and ransomware resilience is one execution domain within the full data protection architecture. The pages below cover the adjacent disciplines — each connects to the others. Ransomware survival without backup architecture is a plan with no copies. Without disaster recovery, it is a plan with no failover. Without business continuity, it is a plan that stops at infrastructure.
You’ve Read the Architecture.
Now Validate Whether Yours Actually Survives.
Identity plane isolation, immutability enforcement model, control plane reachability, air gap validity, recovery sequence — most ransomware resilience architectures look correct in documentation and fail under adversarial conditions. The triage session validates whether your specific environment can survive the failure conditions this page describes before a ransomware event does it for you.
Data Protection Architecture Audit
Vendor-agnostic review of your ransomware resilience posture — identity plane isolation, immutability enforcement model, backup control plane reachability, air gap architecture validity, and recovery path integrity under adversarial conditions.
- > Identity plane separation — production, backup, recovery
- > Immutability enforcement at all five control layers
- > Backup control plane reachability and API access audit
- > Recovery confidence validation against all four criteria
Architecture Playbooks. Every Week.
Field-tested blueprints from real ransomware resilience environments — control plane compromise incidents, identity collapse case studies, immutability bypass patterns, and the recovery architecture that actually survives adversarial conditions.
- > Ransomware Attack Sequence & Recovery Denial Patterns
- > Identity Plane Architecture & Credential Isolation
- > Immutability Enforcement & Control Plane Hardening
- > Real Recovery Failure Case Studies
Zero spam. Unsubscribe anytime.
Frequently Asked Questions
Q: What is ransomware resilience architecture?
A: Ransomware resilience architecture is the design discipline that ensures an organization can recover from a ransomware incident even when the attacker has compromised admin credentials, destroyed backup catalogs, and manipulated retention policies before encryption runs. It requires three separated identity planes, immutability enforced at every control layer, an isolated recovery environment, and tested recovery sequences. It is distinct from backup architecture — backup stores copies, ransomware resilience architecture ensures those copies survive adversarial conditions.
Q: Why do ransomware attacks target backup systems?
A: Because backups are the recovery path. Ransomware operators are not trying to destroy data — they are trying to make recovery impossible, which gives them leverage for ransom payment. 96% of ransomware attacks target backup repositories specifically (Veeam 2024), and 76% of those attempts succeed. By destroying the recovery path before encrypting production data, attackers ensure that the organization’s only options are paying the ransom or rebuilding from nothing.
Q: Is immutable storage enough to survive ransomware?
A: No. Immutable storage protects the storage layer. Ransomware operators attack the identity and management plane layers above the storage — deleting catalogs, manipulating retention policies, and disabling backup schedules without touching the protected storage objects. Object Lock is one of five layers required for real immutability architecture. The other four are retention policy protection, catalog independence, management plane isolation, and identity separation.
Q: What is the difference between DR and ransomware recovery?
A: DR solves an availability problem — it ensures workloads can be restored when infrastructure fails. Ransomware is an integrity problem — the infrastructure is technically functional, but the data and recovery systems have been deliberately corrupted. DR replication faithfully replicates state, including compromised state. An organization that fails over to DR after a ransomware incident often recovers to the compromised environment the attacker prepared. Ransomware recovery requires an independent backup tier with retention that predates the compromise window, not a replica of the current production state.
Q: What are the three identity planes in ransomware resilience architecture?
A: Production Identity governs production workloads and the humans and services that operate them — fully compromised in any serious ransomware incident. Backup Identity governs backup admin accounts, service accounts, and API tokens — must not share credentials or trust relationships with Production Identity. Recovery Identity is the minimal, independent identity source for the recovery environment — a separate AD forest, standalone IdP, or local accounts with no connection to the compromised production environment. If all three planes share the same identity infrastructure, there is effectively one identity plane, and credential compromise is complete environment compromise.
Q: How do you test ransomware resilience architecture?
A: Through recovery drills that test all four recovery confidence criteria: a tested restore from backup data to a functional, application-validated state; executed in an isolated environment with no network path to production and no identity dependency on the production identity plane; validated at the application layer rather than the VM or OS layer; and executed against a documented recovery sequence by someone other than the person who wrote it. A drill that passes all four criteria produces recovery confidence. A drill that skips any one of them produces recovery assumption.
Q: What does ‘recovery denial’ mean in the context of ransomware?
A: Recovery denial is the documented shift in ransomware operator tactics identified in the Mandiant M-Trends 2026 report. Rather than primarily targeting data, sophisticated ransomware operators now systematically target backup infrastructure, identity services, and virtualization management planes — specifically to deny the organization the ability to recover without paying. By compromising or destroying recovery capabilities before encryption runs, attackers increase the likelihood of payment even when backups technically exist.