EONCORE

Desperate Times Require Desperate Measures

10 security measures to put time on your side

A chess clock in blue line art, one clock running, one flag about to fall

Cybersecurity is becoming a race we are not currently winning. Before the opinion, here are the facts.

The facts

+70%weekly cyber attacks per organisation, 2023 to 2025
4,217ransomware attacks logged in H1 2026
+89%operations by attackers using AI, year on year

Attacks are increasing.

According to Check Point, organisations faced an average of 1,158 cyber attacks per week in 2023, 1,673 in 2024 and 1,968 in 2025.

Attack volumeWeekly attacks per organisation, average per year
1,1582023
1,6732024
1,9682025

In August 2026 alone, the weekly average was 2,422: 22% above August 2025.

Source: Check Point Research, yearly reports 2023 to 2025 and August 2026 update

Ransomware remains persistent and fast-moving.

Comparitech logged 4,217 ransomware attacks in the first half of 2026, up from 2,456 in the first half of 2024. Only 484 were confirmed by victims; the rest are claims by ransomware groups. That distinction matters, but neither category is comforting.

RansomwareRansomware attacks logged worldwide, first half of each year
2,456H1 2024
3,706H1 2025
4,217H1 2026

Only 484 of the H1 2026 attacks were confirmed by victims. The rest are claims by ransomware groups.

Source: Comparitech, Ransomware Roundup H1 2026

The most serious incidents are increasing.

The UK government’s NCSC handled 204 nationally significant incidents in the year to August 2025, up from 89 the year before. The highest category has grown three years in a row.

Government dataNationally significant incidents handled by the UK’s NCSC

89→204

129% more than the year before. Nearly half of the 429 incidents the NCSC handled were nationally significant.

Source: NCSC Annual Review 2025

Attackers are getting faster.

CrowdStrike reports an 89% year-on-year increase in activity by AI-assisted attackers. Its average eCrime breakout time, the time from initial access to lateral movement, fell to 29 minutes in 2025.

AI and speedAdversary activity in 2025
+89%operations by attackers using AI, year on year
29 minaverage eCrime breakout time: from the first system an attacker breaks into to the rest of your network

Source: CrowdStrike, 2026 Global Threat Report

This is not peace

Are we at war? No. Are we at peace? Not exactly. We are living in a persistent state of attack.

Security teams now work against two clocks. The first runs in minutes, because that is how fast attackers move. Against that clock, another working group, consensus paper or multi-year roadmap changes nothing. What counts is whether you can spot a real risk, decide and deploy a control before the threat has moved on.

The other clock runs in years. Some weaknesses take that long to fix and get more expensive with every year of delay. Teams must respond to immediate exposure at attacker speed, while reducing those structural weaknesses at the same time. Cryptography is one of them.

Cryptography cannot wait

Post-quantum migration is necessary, but it requires organisations to identify, replace and reconfigure cryptography embedded in systems that were not designed to change quickly. Meanwhile, encrypted traffic can be copied today and decrypted later. A roadmap migrates nothing.

The operational emergency for most teams is still speed.

Risk tolerance has to change

Desperate times require desperate measures. In cybersecurity, the desperate measure is refusing to accept delay as the safer option, while keeping every risk you take under control.

In Europe, waiting has become the default. As we wrote in Spooky Talking at a Distance, we have spent years minimising the risk of making the wrong change. We now need to give equal weight to the risk of making no change at all.

That calls for a series of defensible decisions that reduce exposure now, without waiting for one grand transformation.

Do not wait

1Decide this week, deliver this quarter.

Measure how long it takes to identify an exposure, make a decision and deploy a control. A risk that takes nine months to mitigate is not being managed at the speed of the threat. Fifteen minutes spent on a benchmark is more useful than another roadmap cycle that leaves the same exposure in place.

2Do not wait for certification before making a defensible improvement.

Organisations tend to weigh the risk of acting and ignore the risk of waiting. Certifications, assurance reports and procurement controls do matter. Some are mandatory. But treating a future certification as the entry ticket for every conversation, pilot or small deployment is delay disguised as diligence.

Ask a different question: does the risk of this measure, with appropriate controls, outweigh the risk of leaving this exposure open? Keep the evidence proportionate. Do not demand what a ten-year, enterprise-wide dependency requires before allowing a tightly scoped measure that materially improves security today. Start small, set a time limit, and scale up when it works.

3Pilot in production, safely.

A proof of concept in a test environment can show that a technology works. It cannot show whether it fits the traffic and systems it is meant to protect. Use limited data, limited access, explicit success criteria, continuous oversight and a clear exit path. Then test the improvement on live traffic. Real resilience is forged in production.

Get the basics right

4Measure what actually crosses the line.

Do not rely solely on a configuration export or a CMDB. Observe the traffic and services that are genuinely exposed. Servers often still accept ciphers which everyone believes were switched off. The gap between what is documented and what is really running is where avoidable risk survives.

5Turn off what you do not need.

Legacy ciphers, protocols and exposed services that are still “on the menu” are an invitation to attackers. Remove them now where that does not break a critical dependency. Do not turn every obvious improvement into a major programme.

6Prioritise instead of treating everything equally.

Identify the traffic, systems and dependencies that cannot wait. Protect those first; schedule the rest. CISA recommends identifying public-facing assets, removing unnecessary exposure, prioritising patching and applying MFA to systems that must remain exposed.

Organise differently

7Give an engineer a mandate.

Leadership should set the risk boundary, funding and escalation rules. Then give a named, senior engineer the authority to deploy pre-approved, low-risk security changes within that boundary without taking every change through the full change-advisory process. The mandate should be narrow, observable and time-bound. But it must be real. A security programme cannot move fast if every technically sound improvement needs another executive decision.

8Practise the first hour before you need it.

Assume a disruptive incident will happen and run the executive tabletop exercise now. Know who can isolate systems, make a public statement, call insurers, notify regulators and keep the organisation running at a minimum viable level. With a breakout time of 29 minutes, those decisions cannot start from scratch. The NCSC’s guidance on recovering from a highly disruptive cyber attack begins with exactly those first hours: containment, damage assessment, governance and communication.

9Choose the partner that can move with you.

Large providers can bring expertise, resilience and reach. They can also bring standard programmes, long decision chains and change processes that cannot adapt to your environment. Specialists and start-ups are not automatically the answer either. They still need to prove they can deliver. But the right specialist can often do something a large provider struggles to do: work alongside your team, understand the real environment quickly and turn a decision into a deployed control.

So ask every provider, established or emerging, what they can help deploy in thirty, sixty and ninety days; what access they need; how their work can be tested; and how you can exit. The largest supplier may not be the safest choice. Judge every partner, including us, by that answer.

Use technology that already exists

10Deploy post-quantum cryptography in hybrid mode.

Do not wait for a single, perfect cutover. Deploy post-quantum cryptography alongside the cryptography you use today. If the new algorithm turns out weaker than expected, you keep the protection you have now. If quantum computers come to threaten today’s public-key cryptography, the new layer adds protection. That lowers long-term risk without an all-or-nothing migration.

Hybrid is already mainstream: more than half of the human web traffic Cloudflare handles uses post-quantum key agreement. One way to start is a hybrid layer in front of existing systems, without changes to application code. We built one that works today.

Start this week

Desperate times require desperate measures. In cybersecurity, that begins with a decision you can make this week.

The first step is visibility: knowing which cryptography and exposed services you run. Few organisations can answer that confidently today. From there, you can see which systems, traffic and dependencies cannot wait, and put crypto-agile controls around them while the broader post-quantum migration continues.

Waiting is also a decision . . .

Sources