Why Your Endpoint Recovery Plan Fails During Incidents

In this interview with Help Net Security, IGEL CTO Matthias Haas explains why backups alone do not equal recovery. He argues that endpoint recovery is often overlooked, leaving organizations dangerously exposed when thousands of devices fail simultaneously.

Haas outlines what a well-planned recovery actually looks like, where the bottlenecks emerge, and why restoring trusted user access matters more than simply counting blocked threats. He also offers practical advice on how security leaders can convince a CFO to fund recovery capability before an incident proves the investment was necessary.

What is the most expensive recovery assumption you have seen an enterprise make and later regret?

The most costly assumption is that backups alone guarantee recovery.

Backups are critical. They enable the restoration of data, applications, and systems. Without them, recovery may not even be possible. However, they do not automatically restore user access, clinical workflows, branch operations, call centers, or the endpoint environments people depend on to do their jobs.

Two questions matter equally: “Can we get our data and applications back?” and “Can users regain trusted access to them quickly and safely?”

Many organizations discover during an incident that they planned for infrastructure recovery but not endpoint recovery. That is where the real expense appears: reimaging devices, replacing hardware, validating trust, coordinating users, and deciding who comes back online first.

A smarter recovery architecture accounts for both sides: restore the systems, and restore trusted access to those systems.

You argue recovery architecture is one of the most underused levers a CISO has. Most security budgets still prioritize prevention and detection. What convinced you the leverage sits on the recovery side instead?

Prevention and detection are vital, but they do not determine how long the business stays down after a disruption hits.

Recovery is where cybersecurity becomes operational. It is where endpoint state, identity, policy, applications, and business continuity converge. If every endpoint must be rebuilt before people can work, the organization has designed recovery around friction.

The real leverage lies in restoring trusted access before the full rebuild is complete. That shifts the conversation from time to detect or time to remediate to time to safely resume critical work.

By reducing endpoint risk through an immutable operating system and a trusted endpoint foundation, you give recovery architecture a much stronger starting point.

Walk me through what a well-architected endpoint recovery looks like when ten thousand laptops are bricked at once. Where does the bottleneck usually appear, and is it technical or human?

The first mistake is treating it as 10,000 individual repair tickets.

At that scale, recovery must treat the endpoint fleet as a managed recovery surface. A well-architected model gives users a trusted alternative path into critical SaaS, VDI, DaaS, browser-based, or cloud desktop resources without depending on the failed local environment.

This works when organizations can boot devices into a trusted alternate operating system through planned recovery options such as dual boot or USB boot. This preserves access while the primary environment is investigated and remediated.

The bottleneck is usually both technical and human. Technical, because many organizations have no trusted recovery path staged in advance. Human, because service desk, security, infrastructure, legal, communications, and business teams all enter triage at once.

At scale, recovery fails when it depends on heroics. The goal is to replace heroics with architecture.

If you could replace one number on the CISO dashboard, which security metric is overrated and which recovery metric deserves a seat next to it?

I would not remove threat-blocking metrics, but I would stop treating “number of blocked threats” as a proxy for resilience.

It is useful but incomplete. It tells you controls are active. It does not tell you whether the business can keep operating when controls fail, systems are disrupted, or endpoints can no longer be trusted.

The recovery metric I would add is time to trusted user access.

Not just time to restore a server. Not just time to close an incident. How long does it take for defined user groups to return to a trusted workspace with the right applications and controls?

That metric answers the business continuity question executives care about: when can critical work safely resume?

Downtime cost is easy to wave at and hard to pin down. How do you get a CFO to fund recovery capability before the incident that proves it was worth it?

Stop selling fear and start modeling dependency.

A CFO needs to understand which workflows depend on endpoint access, how many users are affected, what the per-hour interruption cost looks like, which teams must return first, and how long manual recovery would realistically take.

That turns recovery from an insurance conversation into an operating resilience conversation.

The business case is not, “An incident might happen.” It is, “These workflows cannot tolerate endpoint unavailability, and today recovery depends on manual work at the worst possible moment.”

Recovery capability should be framed in that context: reducing time to trusted access, reducing dependency on replacement hardware, preserving forensic options, and keeping critical users productive while remediation continues. That is not fear-based spending. It is measurable resilience.