In the event of a cyber incident, we know the drill. After the systems go down, the infrastructure team works through the plan, communicating, recovering, and after a lot of work, the all-clear is given. Recovery complete. Except, is it?
Because there’s a question that doesn’t always get asked in the post-incident debrief, and it tends to be the one that matters most to the business: how quickly could your users actually get back to work?
Not when systems were technically available. Not when the recovery was declared. But when people could open their applications, pick up where they left off, and get on with their day. That’s the moment recovery is real, and in many organisations, there’s a significant and largely unaddressed gap between those two things.
The resilience gap nobody talks about
It’s worth saying that most organisations aren’t in bad shape when it comes to infrastructure recovery. Recovery objectives are defined, backup strategies are tested, and restoration processes have matured considerably over recent years. Automation and cloud platforms have made a real difference here, and the discipline around RTO and RPO has given teams measurable, auditable targets to work towards.
The challenge is that RTO and RPO measure system and data recovery. They don’t measure whether your people can work.
Recovery rarely happens as a single event, even if it gets reported that way. Infrastructure comes back first, then applications and services, and user access tends to come last, often treated as a natural consequence of recovery rather than something that needs to be explicitly designed for, that assumption is where the gap opens up.
Why the endpoint is now the front door
We tend to think of the endpoint as just a device, but in the way most organisations operate today, with hybrid working, SaaS-delivered applications, and identity-driven access, the endpoint has effectively become the front door to everything.
Unlike the infrastructure sitting behind it, the endpoint is messy and stateful. Applications get installed, configurations drift, and over time each device quietly diverges from the baseline. During normal operation that variation can be manageable. During recovery, it becomes a problem.
At the point of incident, device state is now uncertain, the level of drift is unknown, and returning to a trusted condition takes time and hands-on intervention. At scale, that’s not a process anymore, it’s an operation. Systems may be available, but users are still waiting, and the business is still effectively down.
This is something that’s become harder to ignore as working patterns have changed. Gone are the days where most users were in the same building as the infrastructure they depended on. Now they might not even be in the same country. The expectation is that access just works, and when the endpoint fails, that expectation falls apart quickly.
What’s starting to change
What we’re seeing shift isn’t just the tooling, it’s the way the problem is being framed.
Rather than continuing to manage increasingly complex endpoint environments, there’s a growing focus on reducing dependency on endpoint state as part of the recovery design. The logic is fairly simple: environments with less drift are easier to trust, environments where compromise doesn’t persist are easier to recover, and systems that can return to a known state quickly are inherently more predictable.
The more significant change, though, is procedural. Traditional recovery follows a linear sequence: restore systems, repair endpoints, restore user access. Increasingly, organisations are challenging that order. The push is towards restoring user access earlier, allowing productivity to resume while remediation continues in parallel.
From a business perspective, recovery isn’t complete when every issue is resolved. It’s complete when normal operations resume.
That reframe positions this as a workspace challenge as much as an infrastructure or security one. Modern workspace strategies already centre on flexibility and identity-driven access, but resilience just hasn’t always been integrated into that thinking. If the goal is for users to be able to work from anywhere, recovery needs to support exactly that.
Two questions worth asking now
You don’t need a major transformation programme to understand where you stand. Two questions will surface the gap fairly quickly:
- How quickly do your systems recover?
- How quickly do your users become productive again?
The difference between those two answers is your exposure. In environments still dependent on traditional, stateful endpoints, that difference can be considerable.
Addressing it starts with understanding where endpoint dependency still exists, what happens when that dependency breaks, and how long it takes users to get back to productive work. From there, the path forward becomes clearer.
Most organisations are well-practised at optimising for system recovery, and that remains important. But perhaps the more meaningful measure of resilience is how quickly the organisation itself returns to normal, because if users can’t work, recovery isn’t complete, regardless of what the metrics say.
Common questions on endpoint resilience
Are RTO and RPO still the right measures?
They remain essential for system and data recovery, but they don’t tell you how quickly users become productive. That’s the part that tends to catch organisations off guard.
Why do endpoints slow recovery down?
Because they’re inherently stateful and accumulate variation over time. That makes them harder to trust during an incident and slower to return to a known condition, particularly across a large or distributed user estate.
What’s the shift in approach?
There’s increasing focus on reducing dependency on persistent endpoint state, so that recovery is more predictable, less manual, and less reliant on the specific condition of any individual device.
Is this relevant to us?
It’s most relevant where there’s still heavy reliance on traditional, managed endpoints, though the underlying principle applies broadly, particularly in hybrid working environments where users expect seamless access regardless of where they are.
If you’re reviewing your resilience posture and want to understand where the endpoint gap sits in your environment, it’s worth having that conversation before an incident makes it unavoidable. Feel free to reach out using the contact page above, or by emailing hello@proact.co.uk.
Written by…
Nathan Byrne
Chief Technical Evangelist
Nathan Byrne is Chief Technical Evangelist at Proact IT UK, a specialist IT managed services provider in enterprise storage, hybrid cloud and data infrastructure since 1994. Nathan works across customers, partners and technical teams to demonstrate how emerging technologies can solve real business challenges, translating complex concepts into clear, outcome-focused conversations. With extensive hands-on experience across a broad range of technologies, he helps organisations navigate change, accelerate adoption and maximise the value of their technology investments.