Ransomware in 2026: why your backup target is the new attack surface
The 2020s ransomware playbook shifted when crews started encrypting backup targets. Your recovery story dies the moment your backup destination is compromised. Here's the architectural fix.
The economic shift
Through 2018, the dominant ransomware playbook was simple: compromise the production system, encrypt local files, demand payment. Mature organisations defeated this by maintaining offline backups. The cost-of-recovery calculus tilted away from paying.
Through 2019-2022, operators adapted. They started attacking the backup infrastructure first. By 2024, the most sophisticated crews — Black Basta, BlackCat/ALPHV, LockBit's successors — were routinely encrypting backup targets before the production estate, so that when production recovery was attempted, the backups were already unusable.
By 2026, the standard advanced ransomware playbook has three phases: (1) compromise and persist, (2) destroy or encrypt backup capability, (3) double-extort with exfiltration and production encryption.
Why air-gap doesn't scale
The textbook recommendation for surviving phase 2 is air-gapped backups: storage that physically cannot be reached from the production network. For a single-site operation with predictable backup windows, this works. For most enterprises — with continuous data, geographically distributed operations, and rapid recovery objectives — air-gap is operationally untenable.
The compromise: "immutable storage" with provider-enforced retention windows. AWS S3 Object Lock, Azure Immutable Blob Storage, Backblaze B2 Object Lock. These prevent deletion or overwrite for a specified period — a meaningful improvement, but with a critical limitation: the immutability is enforced by the provider whose plane is also in the attacker's potential attack surface.
Why multi-cloud RAID changes the analysis
SkyeDATA — SkyeConnex's backup pipeline — targets the multi-cloud RAID layer. Each backup chunk is RS(5,2)">Reed-Solomon RS(5,2) encoded into 7 shards and distributed across 7 distinct providers in customer-chosen jurisdictions. The properties this delivers:
1. No single backup target to attack
An attacker who compromises one — or two — backup provider accounts cannot encrypt or delete the backup. Five providers must be simultaneously compromised for the backup to be irrecoverable.
2. No single plane to compel
Even if an attacker obtained a court order against one storage provider to force deletion of the backup, the order would have to be issued and executed simultaneously against five providers in five jurisdictions. In practice, this is operationally impossible.
3. Exfiltration becomes unprofitable
Double-extortion ("we'll publish your data unless you pay") requires the attacker to obtain readable copies of the data. Even if the attacker pulled shards from all 7 providers (which already requires compromising 7 accounts in 7 jurisdictions), they would hold ciphertext for which the wrap key was derived only on the original customer's device. The economics of exfiltration collapse.
4. Signed provenance proves clean restore points
Per-file integrity certificates dual-signed with HMAC-SHA-256 and ML-DSA-87 let you cryptographically prove which backup version was the last clean one before compromise. Restore decisions become auditable; "did this version exist before the attack?" answers itself.
What recovery looks like
Recovery is the read path in reverse. Fetch the shard manifest. Parallel-pull shards from any 5 of the 7 providers (so up to 2 providers can be unreachable or compromised). Reed-Solomon decode on the recovery host. AES-GCM decrypt frame-by-frame using the customer's wrap key. Stream plaintext into restoration.
No provider needs to be uncompromised. No backup target needs to be uncompromised. The recovery succeeds as long as any 5 shards remain readable, which means surviving an attack on 2 of the 7 backup destinations.
Retargeting existing backup tools
SkyeBucket — the S3-compatible drop-in gateway at s3.skyeconnex.com — works with Veeam, AWS Backup, Bacula, and other backup tools that target S3. The retargeting is one endpoint change in the backup tool's configuration. No new agents, no new infrastructure, no new operational pattern. The architectural sovereignty is inherited.
The board-level argument
Most board-level ransomware presentations include a slide titled "we maintain backups." The next question — "how do you know the backups won't be encrypted too?" — is rarely answered architecturally. The honest answer with most cloud backup postures is "we have monitoring; we'd notice."
The architectural answer with multi-cloud RAID: "the backup target is mathematically not compromisable from any single point. The attack would have to land at 5 providers in 5 jurisdictions simultaneously. The probability is negligible."
See the ransomware protection solution → Or book a briefing for a live walkthrough of restoration from a 2-provider-compromised state. 45 minutes.
Published March 25, 2026 · Written by SkyeConnex Inc. · More from the SkyeConnex blog
Hand-picked for what you just read
Why multi-cloud RAID beats multi-cloud sync
Reed-Solomon erasure coding for storage: a practical primer
Reed-Solomon codes are decades old. They're suddenly central to sovereign cloud architecture. Here's what they do, the math you need, and th…
Read → Threat · 7 min readInsider threat in cloud storage: the trust topology problem
Most insider-threat discussions focus on customer-side admin compromise. The provider-side question — what your cloud's own admins can see —…
Read → Cryptography · 7 min readQuantum 'harvest now, decrypt later': the timeline that actually matters
'We'll worry about quantum when it happens' is the wrong frame. Adversaries are harvesting encrypted traffic today, betting on decryption to…
Read →