Written by Jaiz Anuar

The System Designed To Recover You Can Also Become An Attack Path

Recovery systems need broad, persistent access for legitimate reasons. That trust makes them valuable—and means recovery architecture must survive compromise of the provider, platform or identity itself.

Backup and recovery systems are usually treated as part of the organisation's safety net.

They protect data. They preserve business continuity. They provide a path back when systems fail, ransomware strikes or infrastructure becomes unavailable.

Because of that role, they are naturally trusted.

Sometimes extensively.

That is exactly why they can also become attractive attack paths.

The recent ConnectWise Cloud Backup incident is a useful reminder. ConnectWise disclosed unauthorised access to application identities associated with its Cloud Backup service. Microsoft later reported that the threat actor used compromised multi-tenant application identities and their existing trusted permissions to reach downstream customer environments, perform cloud discovery and access resources including Azure Key Vaults.

The backup data itself was reported as encrypted, isolated and preserved, with no indication of compromise. The more important architectural issue is what the trusted application identity could reach.

That changes the question.

What happens when the system designed to help you recover is itself compromised?

Recovery Systems Are Highly Trusted Systems

Backup platforms often need broad access.

They may need to read mailboxes, files, databases or application data. They may require service principals, OAuth permissions, certificates or persistent integration with cloud platforms.

Those permissions exist for legitimate reasons.

But from an attacker's perspective, they are also valuable.

A compromised backup platform may not need to exploit a vulnerability in every downstream system individually. If the platform already has trusted access, the attacker may attempt to inherit that trust.

This is the same architectural principle discussed in Every Trust Relationship Is An Attack Path.

The backup platform is not simply storing data.

It is participating in a trust relationship.

That trust needs the same scrutiny as any other privileged identity.

The Backup Identity May Matter More Than The Backup Server

Traditional discussions about backup security often focus on the repository.

Is the backup encrypted?

Is it immutable?

Can ransomware delete it?

Is there an offline copy?

Those questions remain important.

But cloud backup introduces another layer.

The identity used by the backup platform may itself have significant authority.

In the ConnectWise case, Microsoft described activity involving compromised trusted application access, cloud resource enumeration, credential changes, role assignments and access to downstream environments.

That means the architecture must consider not only the integrity of the backup data, but also the permissions surrounding the backup service.

What can the application identity read?

What can it modify?

Can it create credentials?

Can it assign roles?

Can it reach other cloud services?

How quickly can that identity be revoked?

These are identity architecture questions.

And they are particularly important because backup systems often operate continuously and without interactive human authentication.

Third-Party Recovery Creates Third-Party Trust

The risk becomes more complicated when recovery is delivered by an external provider.

An organisation may have strong internal security controls but still depend on a third party that maintains persistent access into its cloud environment.

That relationship may be necessary.

It is still a trust relationship.

As discussed in Your Trusted Business Partner Is Compromised. Are You Next?, third-party connectivity should never be assumed safe simply because the business relationship is legitimate.

The same principle applies to backup providers, managed service providers and recovery platforms.

A trusted provider may be secure today.

Architecture must still assume that the provider could be compromised tomorrow.

The question should therefore become:

If the recovery provider is compromised, how much of our environment can the attacker inherit through that trust?

Recovery Access Should Have A Small Blast Radius

Recovery platforms often need significant access, but significant does not have to mean unlimited.

Permissions should be narrowly scoped.

Backup identities should be separated from administrative identities.

Recovery services should not automatically receive authority to manage unrelated infrastructure.

Production privileges should not be reused casually across backup, recovery and administration functions.

This is where the principle in The Strongest Architecture Is The One That Limits Blast Radius becomes especially relevant.

If a backup identity is compromised, the architecture should limit what the attacker inherits.

The goal is not simply to protect the backup system.

It is to prevent compromise of that system from becoming compromise of the wider enterprise.

Recovery Infrastructure Needs Its Own Trust Boundary

Organisations often treat backup and recovery as support services behind production.

I think that model needs to change.

Recovery infrastructure should be treated as its own high-value trust domain.

Its administrative identities should be separated.

Its credentials should be independently protected.

Its access should be monitored.

Its connections should be revocable.

And where possible, its recovery data should remain isolated from the identities and control planes used to operate normal production systems.

This becomes particularly important during a serious cyber incident.

If the attacker controls production identities, the recovery process should not depend entirely on those same identities.

Otherwise, the organisation may restore the technology without restoring trust.

That is why future-state architecture needs to think beyond traditional disaster recovery.

Recovery should be designed to rebuild a known-good environment, not merely restart an available one.

Isolation Must Be Possible Before Recovery Begins

There is another important lesson from the incident.

ConnectWise disabled affected application identities, revoked certificates and suspended services while investigation and restoration continued. The company later began restoration using a new security-hardened Microsoft 365 application, with tenants required to re-authorise the new application.

That is an important architectural pattern.

The first objective after compromise is not always restoration.

Sometimes it is isolation.

Trust must be removed before it can be safely re-established.

This principle applies well beyond backup systems.

If an identity, integration or vendor connection becomes untrusted, the organisation should be able to disconnect it without redesigning the environment during the incident.

That capability needs to exist before the compromise occurs.

Recovery Must Not Become A Permanent Backdoor

Backup and recovery systems are sometimes granted broad permissions because availability is considered more important than security complexity.

That can be dangerous.

A service account that can access every workload may make backup operations easier.

A shared application identity may simplify administration.

Persistent privileged access may reduce operational friction.

But convenience creates concentration risk.

This is exactly the type of architectural weakness discussed in Security Controls Cannot Fully Repair Poor Architecture.

Monitoring the backup account does not eliminate excessive privilege.

Encrypting the backup repository does not reduce what the application identity can reach.

Adding alerts does not replace proper isolation.

The stronger solution is to reduce unnecessary trust before additional controls are added around it.

The Recovery Architecture Question Needs To Change

Security reviews often ask whether backups exist.

Are they encrypted?

Are they immutable?

Have restore tests been performed?

Those are necessary questions.

But a defendable architecture should also ask:

What identities operate the recovery platform? What privileges do those identities hold? Which systems trust the recovery provider? Can those connections be revoked quickly? Can recovery continue if the provider itself is compromised? Can the organisation rebuild using credentials that are independent from production?

These questions move recovery from an operational capability into an architectural one.

And that is where it belongs.

Final Thoughts

Backup systems exist because organisations accept that production systems can fail.

Cybersecurity architecture should extend the same assumption to the backup platform itself.

The recovery provider can be compromised.

The service principal can be abused.

The trusted application can become hostile.

The administrative account can be stolen.

The architecture must still survive.

A strong recovery design therefore protects more than backup data.

It protects the trust surrounding the recovery process.

It limits the authority of recovery identities.

It isolates recovery infrastructure.

It allows compromised connections to be revoked.

And it provides a path to rebuild the business into an environment that can be trusted again.

Because the system designed to recover you may be one of the most privileged systems you have.

And anything highly trusted can also become an attack path.

Question assumptions. Share knowledge. Build trust.