A different kind of problem

Most discussions about cyber recovery still begin with backups, restore processes, and recovery time objectives. These are all important; however, they do not fully reflect how recovery works in many real-world cyber incidents.

In practice, recovery often becomes difficult not because backups are unavailable, but because trust in identity can no longer be relied on.

When systems are unavailable, recovery is typically a technical challenge. But when identity is compromised, recovery becomes a question of trust. If platforms such as Microsoft Entra ID, Active Directory, privileged roles, MFA methods, or recovery accounts are affected, the situation changes significantly.

The focus is no longer simply on whether we can restore systems, but on how we can re-establish trusted administrative control before we even attempt recovery.

Why identity matters so much

Whether we like it or not, identity now sits at the very centre of most environments. It controls access to all our infrastructure, governs administrative privileges, and underpins both cloud platforms and SaaS services. What we often fail to grasp, however, is that it is also the mechanism through which all recovery actions are performed. If that layer is compromised, many of the tools we rely upon for recovery may also be affected. This can include:

• Backup systems
• Management platforms
• Automation tooling
• Code repositories
• Remote access paths
• …

At this point, recovery is no longer just about availability. It becomes a question of whether the environment can be trusted.

Where recovery assumptions start to break down

Many organisations have taken sensible steps to improve their recovery position, such as implementing backups, documenting processes and responsibilities, and conducting disaster recovery exercises. These are all valid and necessary controls, and they form an important part of any recovery capability. However, they are typically designed around a particular operating assumption: that the people, accounts, and systems used to perform recovery actions remain trusted and available. In practice, this means assuming that:

• Administrative accounts can still be used safely
• Identity platforms are functioning and trustworthy
• Access to backup systems and management tooling is intact
• Recovery teams can operate using their normal credentials and control paths

In a cyber incident, particularly one involving credential theft, privilege escalation, or identity compromise, this assumption may not hold. If an attacker has accessed or manipulated the identity layer, it can become unclear which accounts, sessions, or systems remain trustworthy. As a result, the same mechanisms used to recover systems may also be part of the compromise. At that point, recovery is no longer just about restoring data or systems. It requires first re-establishing a trusted administrative footing from which recovery can be carried out safely.

What safe recovery requires in practice

Recovering safely after identity compromise involves more than restoring systems. Once trust in the identity layer is uncertain, recovery is no longer simply a technical activity. It becomes a controlled process of re-establishing trust, validating what can be relied upon, and carefully rebuilding the environment without reintroducing risk.

This requires a structured approach that considers several interdependent factors:

How can trusted administrative control be re-established

Before recovery can begin in a meaningful way, there must be a clearly defined, controlled method for regaining administrative access. This may involve establishing clean access paths, validating break-glass procedures, or rebuilding identity services in a known-good state. Without this, any recovery action may rely on accounts or permissions that could still be compromised.

Which systems, data, and configurations can be relied upon

Not all systems or backups can be assumed to be trustworthy. There needs to be a way to assess whether data, configurations, and images are safe to use, particularly if persistence mechanisms or unauthorised changes may have been introduced prior to detection.

How services are rebuilt from known-good foundations

Where trust is uncertain, recovery often needs to prioritise rebuilding core services from validated baselines rather than restoring them directly from potentially compromised environments. This includes infrastructure, identity components, and supporting services that underpin business operations.

The order in which systems are safely restored

Recovery sequencing becomes critical. Foundational services such as identity, networking, and management layers typically need to be stabilised before dependent systems are brought back online. Restoring services in the wrong order can lead to instability, security gaps, or the reintroduction of compromised elements.

How compromised access paths are identified and removed

Recovery is not complete until the routes used by an attacker have been understood and addressed. This includes privileged access paths, remote management routes, service accounts, and automation processes. If these are not properly identified and remediated, there is a risk that restored systems could be re-compromised.

Taken together, these considerations make cyber recovery a more deliberate and controlled process than a standard restore.

The reality organisations encounter

When identity is part of the blast radius, recovery becomes less predictable. Dependencies are harder to manage, decision-making becomes more cautious, and timelines can extend. In many cases, the challenge is not the absence of backups but the lack of a clearly defined and trusted path to use them safely.

If your core identity services were compromised, how would you re-establish trusted administrative control in practice? Not as a documented process, but as something that could be executed under pressure.

If this is difficult to answer with confidence, it is often a sign that recovery risk may be higher than expected.

Final thought

This gap between expected recovery capability and real-world recovery conditions is where many organisations encounter difficulty. It is also why cyber recovery should be considered separately from traditional disaster recovery. The technical ability to restore systems is only one part of the problem. The ability to do so from a position of trust is what ultimately determines whether recovery is successful.

And in many cases, that depends on whether trusted control of the environment can be re-established.

A practical next step

To help explore this more clearly, we have put together a short Cyber Recovery Readiness Check.

It focuses on whether recovery would still work if identity, administrative paths, and trust in the environment were disrupted. The aim is not to provide a full assessment, but to help you highlight areas where recovery assumptions may need closer attention.