Ransomware is giving up on encryption — and that invalidates your backup strategy

Payment rates fell to 28% in 2025, so operators dropped encryption and moved to stealing data and threatening to publish it. Restoring from backup no longer resolves the incident, because the problem is not availability. It is disclosure.

Bu yazının Türkçesi: Türkçe sürüm.

I used to feel good about backups: they were being taken, and a restore had actually been rehearsed once. "If ransomware hits, I restore and I don't pay" — the standard answer, taught for a decade.

Reading Kaspersky's state of ransomware in 2026 I realised that answer had quietly stopped being true. Not because my backups got worse, but because the attacker changed the question.

The number that drove the shift

The most explanatory figure in the report is a single ratio: ransom payment rates fell to 28% in 2025.

From the attacker's side that means the business model broke. Encryption is expensive work: get access, move laterally, find and ruin the backups, encrypt, manage keys, then negotiate. If seven victims in ten refuse to pay after all that, the economics stop working.

The response was clever and cheap: skip the encryption, take the data, threaten to publish it. The report frames this as the defining trend going into 2026 — a move away from operational disruption toward reputational and regulatory pressure.

The scale is not small either. In manufacturing alone, losses exceeded $18 billion in the first three quarters of 2025. What makes that interesting is that the share of organisations facing ransomware fell across every region compared to 2024. Fewer attacks, more damage: more selective, more expensive.

One caveat about that figure

The 28% figure comes from one vendor's telemetry, and ransom payments are inherently under-reported. Read it as a direction, not a decimal: payment rates are falling and attackers are adapting. The direction is consistent across multiple sources; the exact ratio is not.

The causes are mixed too — law enforcement operations, sanctions risk attached to paying, and genuinely better recovery practice. That last one is the good news: a decade of backup advice worked. The bad news is that it worked, so the attacker moved.

Why this makes backups insufficient

A backup answers exactly one question: what happens if the data becomes unavailable?

Extortion without encryption never asks that. It asks: what happens if someone else has a copy?

The second branch is the uncomfortable one. In an encrypting attack, paying buys something verifiable: the key works or it does not. Under a leak threat, what you buy is a promise. You cannot confirm deletion. Payment does not resolve the incident; it postpones the first publication.

Other 2026 headlines worth noting

From the same report:

The post-quantum line struck me as ironic. On the enterprise side we discuss ML-KEM migration as a multi-year roadmap item. A ransomware family already shipped it.

In Europe and Turkey, this is a legal clock

The move from encryption to exfiltration also changes the legal class of the incident, and that is concrete.

A system that is encrypted but not exfiltrated is, crudely, an availability event: restore and carry on. The moment personal data leaves, it becomes a data breach. Under Turkey's KVKK, the Board's decision 2019/10 of 24 January 2019 interprets the law's "without delay" as 72 hours from becoming aware, with notification owed to the Board and to affected individuals. GDPR readers will recognise the same 72-hour shape.

The practical consequence is that the attacker now holds a second lever. Refuse to pay and the notification duty still fires. Pay, and it fires anyway, because you cannot verify deletion. The "handle it quietly" option does not legally exist.

For a small studio the lesson there is not technical but design-level: every personal data field a feature collects is wired to a 72-hour clock somewhere down the line.

Where a one-person studio fits

Honestly: a studio like mine is not on Qilin's target list. I am not writing this out of "it could happen to us" anxiety. I am writing it because of the question the trend changed.

I used to ask: "If I lose everything, can I get it back?" Yes. The question I ask now is: "How bad is it if what I hold goes public?" And that has nothing to do with backups. It has to do with what I keep.

Three things changed as a result:

1. Keep less. The safest data is data never collected. "What does this feature actually need" is now a question I ask at design time, not after.
2. Write down where the copies live. Saying a backup "exists" is not enough; the backup is itself a leak surface. An unencrypted backup is an easier target than the live system.
3. Treat publishing identity as its own class. For anyone who ships software, the real catastrophe is not a data leak but losing the publishing identity. That loss is not recoverable — users receive a malicious build under your name.

Let me also say what backups still solve, so this is not read as "don't take backups": hardware failure, deletion mistakes, botched migrations, and yes, the encrypting attacks that still exist. For all of those, a backup is the only answer.

What none of the three changes above is a backup. Backups remain necessary — they are simply a recovery strategy, not a security strategy. Treating those as the same thing was a mistake I repeated for years.

← All posts